Topic Project Methodologies & Process
No IT project ever follows a methodology to a tee. If they did, the success rate of projects would be far higher than the abominable success rates we constantly read and hear about or even worse, personally experience. Here is an example of an actual project with many typical challenges found in most projects and how they were addressed to achieve success beyond expectations. It can help provide ideas and tips on how to address real-life sticky situations, move forward without starting over and motivate a diverse group of people from both business and technical departments to turn around a project and deliver on time and under budget.
If you are looking for magical answers to your project challenges, this document is not for you. It is geared for those of you who have been in the trenches for a while, know much of what the root causes of your problems are and want ideas, tips and techniques to refine your approach to managing complex and challenging projects.
Project Scope
Rolled out a new operating system (OS) and redesigned a LAN for 3,200 desks across seven call centers for two business units, pointing to servers housed in three data centers.
Situation
Both the business units receiving the rollout and the IT department supplying it had institutional cultures working against a smooth rollout:
- The IT department had a history of forcing ill-suited technology on users, with engineers controlling entire projects and dismissing customer input, a reputation the new division manager wanted to change.
- Business Unit A was unaware of their impact on other divisions as they frequently rushed out technology solutions, sucking up resources across the organization to meet their aggressive deadlines. They had given the IT department a non-negotiable five month deadline to roll out the operating system to support a new application which the unit had already announced to the public.
- Business Unit B was larger, less innovative, and still recovering from a recent merger and the accompanying negative publicity and high employee turnover. They most wanted a stabilized desktop environment.
Across the entire organization, the merger had resulted in low morale and a seeming inability for business units to work together, whether with each other or with IT. The project got underway amidst an atmosphere of finger-pointing, chaos and animosity.
Challenges and Solutions
Principle 1: Clearly Defined and Agreed-upon Objectives
Challenge
True to its culture, the IT department had set the objectives for the rollout with no input from its customers. Given the tremendous amount of money already invested in the operating system, we knew a recommendation to re-evaluate the design would be met with all the enthusiasm of a patient facing a root canal.
Solution
We wanted the new OS to meet the needs of the people using and supporting the technology every day. The sponsoring executives had had their say, but we needed to know what the users needed. Working quickly, we developed and distributed a survey to call center staff at all levels, inviting them to describe the general and technological challenges they faced and the ways in which business had changed in the recent past and would change in the immediate future. The survey, though “quick and dirty”, was instrumental in two ways. The feedback was crucial in redirecting the engineering team from plowing through the call centers with something that was not tested, agreed to, or beneficial to the users. For the business units, the users began to feel like someone was actually taking their requirements seriously and started engaging the IT department proactively rather than simply waiting for the next ill-suited solution to emerge from on high.
Principle 2: Cross-organizational Teams
Challenge
With different cultures and goals, the business units were wasting resources by not working together with each other or with the IT department.
Solution
We brought the two business units and the technology group together onto the same team. Huge savings came from:
- Both business units preparing one unified set of requirements and one SLA
- All implementation team resources helping on every implementation regardless of call center, thereby never dividing resources between two different business units
- The business units learned from each other in terms of support infrastructure and general organization. To this day they call upon each other when new projects come up that might impact both units.
We also redefined the roles of the engineers, placing some of them on the implementation teams while maintaining their design responsibilities. They gained firsthand insight into the usability and supportability of their product directly from the users and support staff. This resulted in engineers who:
- Transferred their focus and ownership from the technology to the customer
- Made a commitment to serving the customer rather than defending their product
- Began to understand and incorporate the plight of support staff into future designs
Principle 3: User-focused Implementation
Challenge
The IT department had planned to roll out the new OS within three months of starting the project – without pilots, training or contingency plans – by “sweeping through” each call center, displacing individuals from their desktops in the middle of the day and completing the installation at each center in a rigidly defined timetable of nine hours. This plan had no contingencies and did not account for handling the calls that would normally be received by these individuals.
Solution
By clearly showing the impact of their plan on the call centers in terms of calls lost and dollars and cents, we convinced the manager to radically alter the implementation scheme to include pilots, input from the call centers and implementation teams (comprised of engineers, support staff, users and installers), trailing behind the implementations and building training and process into the project plan.
On the user side, we created ownership and engagement through core teams at each location who were responsible for providing feedback about the technology’s performance and integration into the existing infrastructure. We also held site meetings to engage the managers, supervisors and users in planning the rollout, taking into account specific circumstances such as schedules and other activity.
Principle 4: Support Infrastructure
Challenge
The IT department seemed unable to support the technology they delivered and they did not train the local support staff to do so. This resulted in incalculable frustration for IT support staff, local support teams, help desks and users. Problems were either unsolved, solved belatedly, or solved over and over again as there was little documentation and information sharing. Animosity and finger-pointing flared as frustrations mounted.
Solution
We built a strong support infrastructure to ensure ongoing, proactive support of the technology. This included solid relationships between the various divisions, clear and agreed upon procedures for documenting, resolving and escalating issues, and training support staff across the various units.
Knowledge transfer played a huge role in the stability of the operating system. Individuals from the implementation team stayed behind at each site for up to four weeks, training and building confidence in the local support team. This also created a better understanding of the customer on the part of the IT team and helped build relationships between individuals in different departments, with local support staff later able to call people they knew to help them solve problems more quickly.
Principle 5: Engagement
Challenge
The team was comprised of talented individuals with strong constitutions whose professional lives had taught them distinctly different ways of doing business. Especially given the fierce politics surrounding the project, success depended on keeping the team engaged and focused.
Solution
Team cohesiveness, and thus the project’s success, depended on giving the team a sense of accomplishment, belonging, appreciation and fun as well. We acknowledged the team on several levels, including:
- Fun: When possible, the implementation teams explored the local cities, often going in groups. We also negotiated suites at room rates, giving them a place to unwind after a long day or night of working.
- Acknowledgement: We maintained enthusiasm through efforts such as distributing via email digital pictures of the teams working, installation contests, and a large, colorful floor plan charting the success of each site.
- End-of-project celebration: A grand but economical celebration at the end of every major project is a must. We brought the entire team to San Francisco for a review meeting and, in front of many layers of management, acknowledged the contributions of the teams and specific individuals. We then threw a party tailored just for them – good food and excellent music. The benefits in team spirit and enthusiasm for the next project far outweighed the costs.
- Bonuses and promotions: The project managers distributed to both business units and the IT division a document identifying each person’s contribution, information which the managers used in their bonus and promotion decisions.
Results
Based on the incontestable criteria of time and money, the sponsoring and partnering executives saw the new OS rollout as a roaring success: the project was completed on time and 50% under budget, largely due to:
- Tight expense control: From the beginning, our project infrastructure allowed us to track, audit and reverse expenses as well as communicate procedures for defining, approving, and reimbursing valid expenses. We controlled travel costs by negotiating hotel rates in bulk and booking all travel centrally.
- Auditing: Monthly analysis of the general ledger revealed inappropriate or incorrect expenses. Reversing these saved the company up to several thousand dollars each month.
- Efficiency: Bringing the same dedicated teams to each location meant improved efficiency with each implementation, thus cutting down on time and travel and saving significant contractor costs.
Meeting and Exceeding Project Objectives
The project’s success was crucial for the three division managers involved, especially the two who were new to their positions after the merger. They needed to establish a new IT process for serving call center environments – environments which undergo constant technological change and are also especially sensitive to such changes.
Business Unit A received the operating system in time to support their new product introduced within a very aggressive schedule. They also realized that their aggressive deadlines, made without the buy-in of partnering units, had led to many of their problems with past IT projects. Today, Business Unit A engages the IT division and other business units earlier in the planning process, resulting in far smoother projects.
Business Unit B received the desktop stability they so desperately needed after the merger: crashes went from 1.5 times per day per user to once every two weeks, and only for desktops that were never rebooted. PC repair turnaround time went from three weeks on average to hours by giving local support staff the processes, training and tools to re-image desktops themselves rather than wait for outside technicians.
Business Unit B also received a vastly improved methodology for future IT projects which was accepted by the entire division. This minimizes the chaos teams go through in a project’s beginning phases, eliminates the need to reinvent a methodology for each project, and makes clear the key elements for a project’s success.
The IT division manager was under enormous pressure after the merger, given his division’s reputation for throwing untested, unwanted technology at users, a staff more interested in their creations than the usefulness of their creations for the users, and a customer base looking to dissolve his organization. By providing his two largest customers (representing 70% of his customer base) with technology that changed the way they did business, he was able to build immediate good will between his staff and their customers and gain a reputation for service rather than disservice.
The largest benefit to all three organizations came in learning how to call upon one another and work together to achieve significant results. This means tremendous savings of time and money for the company on all future projects.
Lasting infrastructure ensures the ongoing success and improvement of any technology and also paves a road for greater success with subsequent projects. Several of the support and business infrastructure components built for the rollout of this OS remain in existence today, including:
- Local call center teams are used with each new project to ensure user engagement and ownership. Implementations are done with, rather than to, the call centers.
- Users are included in developing, piloting and refining training materials for all projects.
- The particular business units and IT division involved in this project often call upon one another to begin working on new projects. Business units have a tremendous amount of say in the design and delivery of technology.
- Support teams are part of the design team. Supportability is incorporated in the design upfront, promising huge savings to the company of both time and money.
Haddon Group is a virtual IT project and program management firm based out of Oakland Ca. serving Fortune 1000 companies headquartered in the United States. Customizing their People-Based IT approach to each organization, Haddon Group leads cross-functional business and IT teams to design, develop and deliver technology that improves with time in environments that are sensitive to technology changes like call centers. Haddon Group can be found on the web at www.haddongroup.com.
