6.8 Selling the Critical Path

< Day Day Up >

You are the project manager, so you need to drive this conversation with the goal that all scheduling conforms to critical path. Further, each team contributing to a critical path event must understand and acknowledge the exact terms and conditions of their milestone deliverables. You should approach this discussion with a negotiator's frame of mind. Up to this point, your conversations with each team lead have been about requirements, risk, and so on, but probably not too detailed about hard dates other than "production day." Now, you may well be saying that you expect some or all of their deliverables months sooner than they had anticipated. Push back should be expected regarding both the accelerated dates and quite possibly the completeness of the advanced deliverables as well.

Let us use the "applications ready for installation and testing" milestone as our model for exploration. You have just informed the applications team lead that his or her "must start by date" is the first day of Month Five. In the best of worlds, the response would be "no problem. All functional requirements will be ready for installation and testing on that date." The worsecase scenario, of course, would be saying, "huh?"

Assuming you find yourself somewhere in between, here is how to proceed. Once again, I leave the style to you but recommend the approach of asking, "Which requirements do you think you cannot deliver on Day One, Month Five?" When you have this conversation, you should be working at the level of detail described in the Integrated Services Digital Network (ISDN) project requirements in Chapter 2.

If he or she says 80 percent can be delivered, you should respond, "Great. Let us review the shortfall (the 'missing' 20 percent)." Use the detailed requirements document and note, line by line, which deliverables are in, and which will not be available on that day. Then you need to conduct two additional pieces of analysis:

Understand why each delayed requirement will be late. Many legitimate reasons exist for this. Typical examples include resource, management support, dependencies, and vendor performance. You might be able to mitigate some or all of these potential deficiencies, for instance, by rallying technical support or providing a technical writer to accelerate the documentation process. Other possible causes of delay may be more unseemly, such as internal strife, conflicting priorities, or poor management. These are often tougher obstacles to clear from your critical path, but they must be addressed just the same.
Assess with the team lead and relevant stakeholders the potential impact on critical path if you accept the delayed implementation of specified requirements. That can vary, depending on various factors. While delays are sometimes unavoidable, those with obvious negative impact must be revisited. In most cases, prioritizing deliverables is an adequate approach. For example, it is typical for an application to provide a finite set of user actions, which, in this case, are the tasks that the call center analyst performs to execute and track customer orders. Obviously, bringing this functionality to life is on the critical path. Other application services, however, could be delayed if necessary, particularly if resource is the key dependency. Reporting modules would be the first place to look. Reports can take a lot of time to design, test, and modify, but from a critical path perspective, some of them may not be as compelling as making sure the sales order entry process is ready to fly when it is supposed to.

< Day Day Up >