Restarting a Project
By Raymond Posch

This is a story about having to stop a project gone wrong, examine the team dynamics and project approach that was not working, and then restart the project with a major replan of team organization, work effort, and timeline. (This story also has some useful lessons learned that are applicable to process improvement projects generally with a successful methodology.)

The Context

When I was the PMO manager of a dot.com startup, I was asked to lead a project to "achieve CMM level 3 in the shortest time possible". This was for a subsidiary of Perot Systems that was developing advanced ecommerce systems. It was during those exciting times of the dot.com boom.

The business reason for wanting to get to CMM Level 3 was that our best  competitors were advertising CMM Level 3 certification. Our management team thought that having the credential would allow us to prove ourselves more easily and compete in a highly competitive marketplace.

At the time we were still learning what worked and what didn't in how we did our business – including how we managed engagements with our clients, how we managed multiple simultaneous projects for different clients, and the process of how we developed software and did system integration with all the resource allocation and management issues. We were clearly at Level 1 (ad hoc processes) of the Capability Maturity Model.

We were in the process of figuring out how to improve our processes, but our new "best practices" were still in flux. So the timing was not exactly good from the point of not having a solid foundation. However, maybe the timing was good in that we needed to accelerate the improvement of our software development process - to make it reliable, repeatable, faster paced with higher-quality results, and better geared to multiple long-term client engagements.

So this was about managing a process improvement project. And I can tell you from first-hand experience that process improvement projects can be the most challenging type of projects. The reason is that it can be difficult to envision exactly what the end result will look like, let alone what has to happen to get there!

Project Startup and Fizzle 

It happened that Perot Systems had a software development subsidiary in India that had been assessed at CMM Level 5. We decided to bring in some consultants from that subsidiary to help jumpstart the project.

In retrospect this was probably not that good of an idea, because American technology companies (especially startups) and Indian technology companies have huge differences in their cultures, approaches to software development, and views of process and process improvement.

We kicked off the project and had the consultants from India recommending what processes should be developed and in what order. As you probably know, processes are defined and delivered primarily in the form of documentation. The consultants from India were actually leading much of the documentation work and, as documents were produced, the documents were distributed to the team for review and comment.

<< Previous    [1]  2    Next >>