Pilot's Lounge

From preliminary tools usage analysis, we found users are not using the tools correctly. Our observations, coupled with data from tools logs, demonstrated verious capabilities and functions of the tools that were used more over other features. We knew that users, left to use the tools without proper guidance, will develop their own workflows that may or may not be effective in getting their work done - at least as far as the tool design was concerned. Another negative side effect was that users were in a position to drive the direction of tools features when upgrades were required. There was a highly likelihood they would have delayed, or refused, the upgrade of tools knowing it would have affected their workflow - let's face it, once someone gets comfortable, it's hard to change the way they do their work.

The opportunity I saw was to help users optimize their workflow and help them adopt a standard practice in the process. This would also help my team of tool administrators when it came time to upgrade the tools. We will have a better indication of what features are upgradeable, and how to upgrade to avoid disrption of service. Given the data, we can also provide better, effective service to the customer.

We identifed all tooling parameters and prioritized parameters that yield the greatest value in the quickest time. Then, based on priority, we developedd the appropriate tool governance reporting to share with management so they may independently take action and improve tools use. Our objective to educate users and provide consultation that allows them to understand the benefits of their project as a result of proper tools use was realized.

In a short while, the internal team was bought in and appreciated the objective of the governance reporting effort. Since we address many support and mentoring activities, simpler ticket counts were reduced and the team focused on more complex, value-added issues. Customers' time was freed from ardous, inefficient workflows. A side effect of our focus on improving the customer experience, was an improvement in the customer's confidence in my team to provide value.

Throughout the last four years, expectations in work equity have been descrasing while fringe benefits continue to be handed out. In fact, employees expected promotions and pay increase despite their lack of effort to achieve acceptable performance. Management continued to spport the handout despite my attempts to highlight the work to performance disparity.

Given that management valued the alignement of goals and culture with the organization, I saw an opportunity to level-set my department and reinforce the alignment with management. Further, I saw an opportunity to provide a fair and equitable work environment for my team.

I discussed my thoughts and concerns with management in a way that indicated the management team "we" were creating such an environment. The ownership to steward staff expectations was on us to set through education, setting examples, and establishing specific individual goals. I also discussed the result of these actions and that the current business environment requires a different approach.

In a few short weeks, senior management returned with comments how we need to ensure we are creating a fair environment and that promotional considerations are reserved for those that not only demonstrate skills but where there is business need for a resource in such a capacity. In subsequent conversations, the management team stressed to team members in 1-on-1 sessions when queried for promotional opportunities. The end result was seen after a few quarters as a positive step for all departments and a best practice.

The vice president of the IT unit tied the unit initiative SERVICE mantra (an organizational acronym developed to stress the importance of customer service) to IT initiatives and challenged management to work towards greater customer focus. Guidance from management was intentionally lacking and it was front-line management's responsibility to develop a strategy for their respective areas.

After careful review and analysis, I saw an opportunity to improve my department's capabilities in providing better customer service and improve teamwork. However, I wanted to use this opportunity to improve individual capabilities to elevate team improvements.

First, I reviewed the SERVICE mantra with the team. During the review and with the team's participation, I developed mini-SWOT analysis of each SERVICE Mantra vectors. The SWOT analysis provided each team member the ability to rank the team and prepare for their individual rankings. I then took a survey of each team member in a way that identified the top three weakest areas per their rating. Next, I worked with each employee to define an individual development goal for the 2010 that was documented, detailed, and contained thresholds for meeting and exceeding the objectives. I measured the team's weaknesses using similar technique to loosely quantify ranking so we could continue the improvement process.

By December of that year (in three months), SWOT analyses resulted in a documented list of strengths and weaknesses for the team. We also listed all opportunities for the team to strengthen their weaknesses and their listed threats that could derail our efforts. The analyses were also medium to leverage for individual capabilities. In the rankings, each vector was assigned to one unique ranking from 1 (weakest) to 7 (strongest). All team member rankings which were then compared against the SWOT analyses. Team members quickly saw areas where we, as a team, needed to focus our energies. I developed individual rankings for each team member and personalized performance goals for two of their top three weakest areas.

In May of the following year, each team member worked on achieving their personal goals. Goals were demonstrated throughout the year. Without this approach, the goals would have been meaningless and the organization would not have evolved in providing better customer service and improving team performance.

My organization was requested to provide an Operating Level Agreement (OLA) with specific statements on 24x7 support. We did not have a published OLA for users to consume. Without a published OLA, we would have delayed the project and impacted other organizations and ultimately, the development of the Service Level Agreement (SLA).

I saw an opportunity to develop appropriate OLAs and demonstrate the value my organization brought to the customer. With this, I had the ability to motivate my team and ensure their performance was tied to customer's benefit.

I drafted an OLA based on existing documents, then merged multiple departments into one agreement. Although the document was important, the language used to ensure all areas of the unit adhered to general service delivery was important to the buy-in by those organizations. I also created customized sections for each organization in the unit to accommodate that organization's unique situation. For example, my organization provides tooling support, so a custom section was provided to define OLAs for tooling. Another organization may only provide resource support - both adhere to general agreements, but my organization also requires users follow stated tooling standards. I then presented the OLA to my peer management, my director, and my vice president for review, critique, and challenge. During the challenge, I received questions on specific agreement language, document setup and the organization's ability to meet provisions. I answered questions and challenges based on my experience with OLAs, my education and practice in ITIL, and my experience in supporting enterprise-wide tools support. On publishing the document, the management team discussed the merits of enterprise-wide communications vs. grass-roots. I proposed an enterprise-wide communications to bolster confidence in the unit and build on integrity to the customer service. After some discussion, the management agreed and the vice president communicated the availability of the document in the IT staff meeting.

The OLA was published and our users were notified of its availability. The requesting organization expressed their gratitude and had no further questions on the support.

My team used ITIL-based processes and tools as well as SDLC based process and tools. When changes start on the service support side that required software development, we managed two ticketing systems. While using two systems was not ideal, the conflict arising in using two systems was the issue.

I saw an opportunity to integrate o interface the two systems for enterprise change management. Since ITIL based systems and SDLC based systems both use change management, I saw the opportunity to create an efficient workflow for one comprehensive solution and one ticketing system for change management.

I initiated a project to interface HP Service Manager and IBM Rational ClearQuest. I defined a vision and developed models that demonstrated how each change management system provides functionality for the computing space. I rallied key managers from other ITIL areas such as incident, Problem and Release Management as well as key decision makers from the SDLC areas. To each, I explained the concept, my objectives the opportunities for the company when the two systems are correctly interfaced. I then obtained preliminary approvals to work with relevant development areas so ClearQuest can pass Change records to Service Manager. The effort required projects on both development teams which meant a focused approach. I stayed focused on the objective and worked with development managers to ensure the objective would be reached.

In the end, the interface was built an applicable records were tested and transferred between two systems. Users can initiate service management changes from SDLC system which provides continuity and audit capability. The project was completed with minimal number of resources and on-time. Each record transferred contains an originating signature so any change initiated from SDLC can be racked into production. This project exposed a large opportunity to reinvent enterprise workflow which started in 2010.

In 2006, the organization redefined all IS job descriptions. For open positions in my organization, there were no comparable positions in the company's inventory.

Applying or refitting existing positions to my open positions did not make best organizational sense so I developed job descriptions for the Tool Administrator, Tool Analyst, Tool Specialist, Tool Engineer, and Enterprise Tool Engineer positions. The opportunity to define and describe skills required for my open positions as well as for comparable tooling positions company-wide would benefit the organization through targeted recruitment and finding talent with minimal retraining effort.

I compiled existing job descriptions and identified common elements across the organization. I then identified custom requirements for each position and identified skills that were both required and preferred. Required skills were derived from existing needs and my knowledge of tooling. I also drew upon my Technical Product Management effort as well as knowledge of software vendor offering to identify skills we would need to administer, analyze, configure, deploy and mentor on those tools. I kept the descriptions generic so they can be applied to any vendor-supplied tool.

For the last four years, I have hired 14 staff members: 1 tool administrator, 2 tools analysts, 4 tools specialists, 5 tool engineers and 1 enterprise tool engineer. In each case, I was able to target specific needs and limit resume scanning which helped reduce the effort in locating applicable candidates. The descriptions have been tested by my staff as as management through detailed discussions of the merits and skills necessary to meet the positions. I also have two H1B candidates for whom these positions were tested by third party legal consultants through the Green Card application process. I also spent minimal time in support of tooling (as designed) and now am able to cross-train staff so there is adequate tooling coverage in the event of a resource outage. When we started, my team supported a few hundred users. Today, I am able to support 3,000 users for production and project work alike.

Costs to manage desktop infrastructure were estimated at 3 hours per desktop per incident, on average. This results in a large overhead cost to the infrastructure management team and prevents the organization from working on key/strategic projects such as standardization, policy, and security. Further, individual departments paid for, and owned products that were managed by people who were not involved in the initial review consequently leading to confusion and excessive churn. This resulted in greater downtime for users and multiple versions of the same product in the environment which then spiraled to additional support costs as well as inability of the company to realize volume savings.

The objective of this position was to standardize a process that infrastructure management can use to upgrade desktop PCs. The company is running any combination of 3000 desktop applications, the complexity of a unified desktop and the integration of products can be solved by careful testing and certification processes to ensure product upgrades are successful. An additional objective I championed was moving ownership of all desktops to a central location and budget which could be managed by the desktop area.

I started with a basic PC upgrade process and considered the complexity added die to product design, tool ownership, organizational impacts and support. I then developed a rough draft of the upgrade process that incorporated a waterfall SLC, but customized for products. In the final stage, the products were required to be certified before deployment. Certification is a stamp of management approval indicating proper unit, integration and user-acceptance testing has been conduced and the team is fully aware of organizational impacts. I then implemented the process on low-risk upgrades in a controlled environment. I used a matrix organization to resource the work across multiple departments including user groups. Results of each upgrade were used to improve the process and develop better performance criteria. I escalated issues to management across functional lines as necessary to gain attention on critical items as well as gain support.

Budget centralization involved policy changes to purchase and maintenance of software. I worked with desktop support, procurement, and the finance areas and championed a single budget center that would be used to purchase all products. Policies on purchase of licenses and maintenance were developed to ensure the company can upgrade without impacts to individual cost centers. Further, organizations were notified that upgrade activities would give them opportunities to participate in the certification [process so their stage remained.

The process was developed, publish and communicated to key members of Technology and infrastructure Management. When I began to institutionalize the process, I was running well over 23 upgrades simultaneously, each with different matrix-ed teams of sized ranging from five to twenty-five. The largest team I ran was for Cognis containing 35 members from IT and business. Desktop support costs were reduced as issues were minimized. Products were tested and implemented so that only one version of each product existed in the environment. As a result, desktop was only learning resolution steps on one version at a time thereby reducing their overall effort.

When the budget was centralized, some areas refused to give up their control. I would work with each area to explain the situation and benefits of a central organization. Most team were on board. On occasion where some were absolutely reluctant, I escalated issues. In the end, Finance was on-board and developed a cost center which was used to manage all desktop software purchases. This resulted in easier administration, and the ability of the company to manage to the overall budget. The company also bean realizing volume savings(15% on average) through bulk purchases.

The company used IBM Rational tools and purchased flexible licenses which required a server daemon for all tools. However, process documents in HTML were difficult to track in terms of usage. Since the company purchased a number of copies, it was our obligation to track users without exceeding license counts. An open account to the web or a named access were both inefficient and a liability. When the vendor was asked how the company can remain compliant and ensure the product was not copied to another, the response was our company was liable for those actions.

I saw a unique opportunity to use an application developed by the third party to enable flexible licenses on any Widows-based executable. By wrapping an executable that calls the web site, I can effectively manager who accesses the web site, record usage information and ensure the company remains compliant.

I purchased a license and conducted a technical proof of concept to demonstrate the viability of wrapping mechanism. i then gained approval from management and from the vendor to move ahead with the deployment plan. Once in house, I worked with Infrastructure Management to setup the development/test, and production environments, and then develop an executable that initiated a web request. The entire executable was wrapped and the licenses deploy on the flexible license server. Users were then deployed the newly wrapped executable.

The company was compliant with license counts while the number of users accessing the product was increased over 10 times. This gave a greater access to the product while controlling the overall cost of the product.

Obviously benefit to our organization in terms of cost, access, compliance. the vendor benefited knowing their product licenses were well-controlled in our environment. Reports generated show the company remains compliant through available licenses. Cost benefit to the company is in excess of $140k year-over-year.

During the normal course of business, employees that require a technology often sought the technology requested approval to purchase from management. There were no consideration for enterprise architecture, business and technical requirements. Finance was rarely contacted for issues around the viability of the vendors so the company was purchasing and deploying technology and placing itself in liability rto greater support, and/or recovery costs.

As manager of Enterprise Wide Technical Architecture, I saw a need to control technology purchases through proper definitions of business needs, technical and architectural requirements as well as financial requirements to ensure a structured approach was taken and the company's systems architecture was maintained and the company was driving towards stated future state.

I inspected current practices and identified industry standard procurement practices. Because of large gaps between the industry best practices and the company's existing practices, I determined a new process was required and the company must start fresh. I then customized industry practices with the company's specific needs and ensuring stakeholders were involved. Procurement was given a large role as well as those developing business and architectural requirements. The company's enterprise architecture was documented as a constraint so any technology acquisition was measured against our company's stated direction. I then developed a structured requirements gathering for at and associated documents. I determined a weighting and rating method so all technologies undergo the same rigorous procedure.

I used the process on two minor products and then deployed the process on an $8M acquisition of a customer service system. Since the implementations of the first version, the process has evolved with the organization and is now in development for version 3. The organization now utilizes a consistent approach and is focusing on acquiring technologies that align with the core and emerging architecture. The benefits of this include improved tools use and decreased support costs.

The organization continues to experience late requirement adds, and a lack of focus on testing as a discipline. The effect of which materializes through late quality testing submissions, increased defect rate, and stagnated development methodologies.

Improve development methodology opportunities by introducing a testing focus and shift to life cycle testing culture to reduce defect counts.

I developed a team consisting of full-time and contractors to develop methodology content, training, and instructions. I worked with affected development and testing communities to identify their pain points as well as testing practices. The results of interviews and one-on-one session s were recorded and analyzed. Aggregated information was used to develop best practices and adjust content as appropriate. I also held status meetings with the executive steering committee (consisting of the CIO and his vice presidents) to deliver project status, issues and concerns. I also worked with the executive steering committee to demonstrate ideas and gain approvals to move forward. Independently, I developed defect measurement metrics based on research and development of key life cycle data.

The organization's approach to life cycle development moved testing further in front of the development efforts. Executive management was in better touch with true development and testing activities and often times queried organizations to improve their practices. Development of measurement metrics resulted in all organizations measure when defects occurred and when defects were observed which resulted in greater up-front analysis and recovery.