 | The situation just raised is now the most common in extreme projects. The increasing rate of technology innovation and the rate of turbulence in the project environment mean that it is increasingly rare for you to be able to predict in detail all the tasks required to complete a project. | Even if you could, the rate of change in your project would condemn you to a fate worse than death: the dreaded reschedule and reprinting of the hundreds of pages that make up your schedule, only to have to repeat the effort the following week! The solution is to start considering your project as a journey with a clear endpoint. However, the journey to that endpoint is made up not of tasks, but a series of scenarios (alternative routes). Each route has a different series of events that mark a major point in that route. An event could be any of the following: -
A deliverable , -
An agreement (e.g., stakeholders agree to support the project), -
A proof of concept, -
A working prototype, or -
The arrival of a key person. Each project and each scenario has different events and the people at your RAP session will have to help you identify the relevant events. Then, as we show in Figure 13.6, the conventional process of task lists and scheduling is only undertaken for the first event. Figure 13.6. Scenario planning  This eXtreme technique is more suited to the contemporary project environment. Indeed a number of our clients use this model for project funding as well. For example, a project might be budgeted in the worst case scenario for $10,000,000. However, the only committed budget is the $100,000 required to get to Event 1 of the project. If it is clear that, for example, Event 1 reveals that the project is no longer viable , the remainder of the $10,000,000 is available for other projects. We can now move on to a very interesting and controversial planning step: estimating your project. The P Files Episode 10: The Insignificant Task Probably the worst project we have ever seen was a project for a major government department. A newly appointed project director saw the project with fresh eyes. She knew immediately that the project was in trouble. It had been going for nine months and the team was working 60- hour -plus weeks to meet a deadline three months away. Some 5,000 business people were dependent on the project and, worse, had already given up people to pay for the project. The project was capturing sensitive information on more than one million people. The sponsor had promised the minister that the project would be live on the deadline. After a brief review, we agreed with the director's assessment that the project was in serious trouble. We convened a meeting with the project managers, critical stakeholders, and the sponsor (a deputy secretary). The deputy secretary had promised his minister that the project would be live on the deadline. As we gently tried to explain the situation, the sponsor went nuts. He started to plan the project, on the fly, to try and meet the deadline. "OK, OK," he said, "What do we need to do? Yes, we need to scan all the data. OK, let's get all the data entered by the end of next week." A hand went up from the data administrator: "Errr, boss, we don't have a database management system yet. We must have missed it in the plan." Three months to go and the team had forgotten to buy a mainframe database management system! That task took seven months and ended up in litigation. The sponsor and many of the project team members lost their jobs. We'll have more on this bizarre case later. The P Files Team Comment We tend to overlook the criticality of getting the right tasks right. It is one of the easier processes in planning, but it should never be done by one person and it should always be reviewed, reviewed, and reviewed again. Missing a task is a case of instant "out of control" for your project. | Case Study ”Task Listing You begin to focus on the tasks required. Using scenario planning, you, Kim, and Joan identify the major tasks required to develop the Web site that will run only in City 1 (Release 1, shown in the following diagram). You do not identify detailed tasks for Releases 2 or 3.  Initial Task List, Release 1 -
Analyze data requirements. -
Develop basic data design. -
Design database (client and accommodation). -
Analyze Web content. -
Design Web content. -
Prototype screen design (look and feel). -
Design basic Smuthe training requirements. -
Determine hardware requirements. -
Analyze site performance requirements. -
Build HTML. -
Build database. -
Test Web site. -
Train City 1 Smuthe consultants . -
Design new work processes for consultants. Kim and Joan agree to discuss and review the initial task list with their stakeholders. | |
