Recovering a Troubled Hi-Tech Project
by Jim Stewart,
Project Management Consultant and Trainer of JP Stewart Associates
In a previous article, I noted that I started regular travel a few years ago from Boston to New York, in order to work on a six-month contract. My role in the initiative was clear--to serve as one of several project managers overseeing the upgrade and deployment of up to 17,000 workstations from Windows NT to XP for a division of major investment bank. As is always the case with large internal projects in this type of environment, there were some challenges.
First, to recap, the project was already significantly overdue. When I arrived, the division I reported to had only rolled out several hundred workstations. However, the schedule indicated that they should have already deployed several thousand. The problem? There were several.
One issue was the inexperience of the project managers. For example, the person I was hired to replace had no real background in project management and in fact was a high school chemistry teacher. I’m not really sure how he got the job but when I got there, he was on his way out. Another problem was that his counterpart on the business side--a young woman--had very little experience in either project management or technology. So, between the two of them there was an instant recipe for failure. Other reasons for the delinquency included the “packaging” of applications simultaneous with rollouts, unrealistic management expectations and the lack of a consistently applied project management process.
My boss was a good program manager but was working against all of these forces when he brought me in. My primary contribution during my initial six-month stint was my effort to apply and promote a good project management process. Contrarily, some project managers were successful only by bending the rules. For example, some visited sites at night and did many of the installations themselves. I thought that this set a bad precedent and maintained that projects would never get out of the rathole they were in unless each team did its job correctly and consistently.
After several months, management decided to hire a deployment team. Prior to this, project managers had to gather requirements from the business analyst, get hardware ordered, be involved in deployment, and schedule all the work. The deployment team’s responsibility became to work with the various teams, outside vendors, and other stakeholders to knock down obstacles to a successful rollout. I experienced some success with this and felt it was finally a step in the right direction.
It turned out that this team was the beginning of a turnaround for the project. After much turmoil and stress, management started to listen to ideas that engineering had for successful deployment. Below, I detail some of the further steps that were taken to set this project back on the path of profitability:
1. Assess the situation. Instead of continuing down the same failed path, sit down and evaluate where you are versus where you expected to be. Ideally, you have controls in place from the beginning of the project. But if not, it’s never too late to make an assessment.
2. Decide to end the project or continue. Too many projects continue regardless of whether they benefit the organization. You should always be considering whether a project is valuable--i.e., is aligned with strategic objectives or has outlived its usefulness. If the latter, cut your losses and move on. These projects will drag you down.
3. Bring in experienced, trained project managers. Too many projects have people on board whom we might deem “accidental” project managers. These are people who happened to be available or whom have succeeded in some other endeavor. Evaluate their skill sets. Keep the good, trainable ones. Reassign the others.
4. Be prepared to make tough decisions. In this instance, one of the senior managers--outside the project team--was making promises on which he couldn’t deliver. He was ultimately demoted. Additionally, the project office was bypassed for the duration of the project. While it may seem counterintuitive to do that, in this instance that organization had become much more of a political legacy than a truly productive group.
5. Be sure to have enough and the right kind of resources. Recall I mentioned that a deployment team came on board to take over from project managers once they pulled all the pieces together. This allowed the project managers to focus on their job of planning and scheduling and not have to also worry about the day-to-day responsibility of deploying.
6. Reconsider everyone’s role. In this instance, there were business project managers teamed with engineering project managers. A decision was made that the business PM role was not needed and largely redundant. Engineering took over the role of gathering requirements directly from business managers, thereby streamlining the whole process. In some instances, the most talented business PM’s were brought over to the engineering side.
7. Re-plan the project with team input. Management had developed the schedule based on assumptions regarding when they expected Microsoft support would end as well as other business considerations. While those are valid inputs, the team should always be consulted. They know what’s wrong with the project and how long everything should take. Getting team input not only gives you a more realistic schedule and plan but also garners team buy-in.
These are some of the key factors that caused this project to ultimately be successful. Truthfully, it wasn’t completely successful in that the project was well over budget and over schedule. But the good news is that they finished the first part of the project. They can now go forward with the second part, deciding on a network server suite, confident that the lessons they learned will allow them to run better, smarter projects.
Jim Stewart has been an independent project consultant and instructor since early 2003
and has worked in project management for 15 years. He has managed
several multi-million dollar projects for companies such as Lotus
Development and Genuity and currently teaches at both Brandeis
University and Babson College. He can be reached at
jpstewar@rcn.com or view his website at
http://www.jpstewartassociates.com/
