Do you recognize that your current project is late, but you haven’t taken steps necessary to rescue it, except for saying “we’ll work harder to bring it back on schedule?” If you admit that you should do more to handle your project lateness, then the next question is what steps you should take? Actually, the most important step is one which should be put in place at the start of the project, long before development has started.
What first started me thinking about this is when I was hired into a startup integrated circuit company as the VP of Engineering and Software. The company believed that their project to develop a new IC would propel the company ahead of their two larger competitors in this new product arena. Management said the project was late, and that I needed to figure how to get it back on track. I corralled the team and said let’s do a ‘deep-dive’ and find the root causes. The team pushed back hard, saying that if they did what I asked, it would greatly slow down the momentum, and besides they felt they were close to finishing it. It became an emotional issue of trust, with statements such as “the project involved significant innovation, and that they weren’t really as late as management said.” In addition, the development team was at odds with the IC process team as to who was slowing the project down. Does this sound familiar?
The key I discovered as a result of wrestling with this problem, is to have a Metric that becomes a trigger to initiate a deep-dive. This is much less emotional, because the team signs up to the metric at the beginning of the project. So listing this as step one in rescuing a late project, here are the key steps that I follow:
1. METRIC ON RECOGNIZING A LATE PROJECT AND TRIGGERING A DEEP-DIVE:
a. The project is 10-20% behind schedule (you pick the number which works for your project).
b. And you have missed a major schedule milestone, such as completion of a prototype.
2. DETERMINE THE NATURE AND IMPACT OF THE PROBLEMS:
a. Has the business case, scope, or competitive landscape changed?
b. Is there a technical, schedule, or cost problem?
c. Are there too many high risks to the project?
d. Are there resource, management, communication, or third-party issues?
e. Is there a poor product development methodology?
3. INVESTIGATE POSSIBLE SOLUTIONS:
a. Examine the business case, and correspondingly the scope. This should include analyzing your market and competition. What changes are possible? b. Investigate the problems (technical and otherwise) and come up with possible alternatives to choose from.
c. Analyze risks using tools such as probability-impact matrices and complexity-maturity tables. How can risks be avoided or mitigated?
d. Do resources need to be added, trained, or changed, including the project manager?
e. How should the product development methodology be improved?
4. DECIDE ON CHANGES, COMMUNICATE, AND GET COMMITMENT:
a. Decide on an updated business case and scope.
b. Make solution-driven changes that can include limiting the scope, keeping the original scope but utilizing incremental releases, adding and training resources, improving communications, avoiding risks, outsourcing some work, and lengthening the schedule, among others.
c. Get commitment for the new plan from the team and management via clear and open communications of all involved. Then move forward quickly, before momentum is lost.
5. START MAKING METHODOLOGY AND PRODUCTIVITY CHANGES FOR THE NEXT PROJECT: a. Do a lessons-learned at the end of each project, or when rescuing a project, and add what is learned to a check list which is then reviewed often during future projects.
b. Update, or put into place a solid methodology with a flow process, phases, tools, techniques, checklists, and templates.
c. Train the project leader, team, and management on this methodology.
Now, let’s get back to my late project above. The team “convinced” me not to do a deep-dive, but I did assign myself as the project leader and we made some of the changes mentioned above throughout the remainder of the project. However, because of the innovative technology, and not conducting a thorough deep-dive, the project came in later than it should have. Fortunately, we still beat the competition to the market with this new product, and had a successful IPO as a result. That time luck was on my side, but I vowed then that I would follow the process above of having an agreed-upon rescue Metric at the start of the project. That way I wouldn’t have to count on luck being a necessary component of my success.
©2007 Jeff Schlageter ©2007 Global Brain®, Inc.
