Section 2.3.  Diagnosing Project Planning Problems

2.3. Diagnosing Project Planning Problems If a project is not planned well, it will veer off course fairly quickly. If the project manager does not take the lead in defining the scope immediately, the project will quickly become chaotic. Even if the scope seems to be defined well, the project manager must make sure that all stakeholders really understand and agree to it in order to avoid problems later on in the project. The team must buy into the scope as well, or else they will make decisions that are not in line with the project goals. 2.3.1. Lack of Leadership It's not uncommon for people to intuitively feel that all they need for a project to be successful is a group of highly talented and motivated people. But even the best people will have trouble starting a project if nobody takes the lead. One common problem that comes from a lack of leadership is tunnel vision. Each team member knows how to do her specific tasks; however, there's no way to plan for every detail of that task. She will almost certainly encounter decision points. For example, she may see a better way to solve a particular problem that will cost time but lead to a better solution. For some projects, it may be appropriate to pursue this; for others, the delivery schedule is more important than the superior solution. Without good leadership, the team member might be afraid to make this decision. This usually results in the team member sending emails to peers, managers, stakeholders, and anyone else she can find, requesting confirmation of absolutely every little decision that gets made. People quickly get inundated with notes about project details that they lack the context to even understand. On the other hand, she may also simply make decisions based on her gut feelings. As the project progresses, not all of her decisions are in line with the needs of the stakeholders. For example, she may choose to pursue the superior technical solution at the expense of the deadline, despite the fact that the stakeholders' needs would have been just as easily satisfied had she chosen the faster solution. As these decisions pile up throughout the course of the project, the scope itself starts to drift away from the organization's needs. If there is a serious enough lack of leadership, the project may not even get this far. If the scope is never fully defined, then the project may have several false starts. Designers and programmers start building prototypes to demonstrate to stakeholders, only to find that they have to go back and rebuild them because they misunderstood the project needs. Work on the code may begin, only to have programmers moved off of the project for higher priority tasks. People are given conflicting priorities and do not know which one to work on first. The project takes a long time to emerge from the chaos. Even if a product is eventually delivered, it seemed to take much more effort than was necessary, and the team is relieved to be rid of it. 2.3.2. The Mid-Course Correction A change in the project priorities partway through the project is one of the most frustrating ways that a software project can break down. After the software design and architecture is finalized, the code is under development, the testers have begun their preparation, and the rest of the organization is gearing up to use and support the software, a stakeholder "discovers" that an important feature is not being developed. This, in turn, wreaks havoc on the project schedules, causing the team to miss important deadlines as they frantically try to go back and hammer the new feature in. This discovery often comes about very late in the project, when a preliminary build of the software is delivered to the stakeholder. Often a team member had already brought the problem to the stakeholder's attention early on in the project. But it was not detected at the time because the stakeholder may not have fully recognized the nature of problem, or he might not have been comfortable bringing the problem up because it would have involved criticizing a design that represented a lot of effort. Either way, the team is now demoralized because it knows it would have been much easier to build the right software in the first place instead of having to change halfway through the project. Good project planning helps avoid this problem. A vision and scope document describes the features to be developed using straightforward language, and each of the features clearly fulfills a need that the project stakeholders recognize. Stakeholders are not technical people; they might not be fully comfortable reading technical documents, but they are usually very good about talking about their needs and can generally recognize when those needs are taken into account. A project plan developed with the team's buy-in and based on the vision and scope document keeps the project on track and allows everyone to spot problems early on and fix them. Many design or programming problems can be traced back to an engineer who does not fully understand the needs that are being fulfilled. This is usually not the engineer's faultperhaps the need itself was never brought up. Having stakeholders review and correct the vision and scope document before the software is designed helps the team recognize those missing needs early on in the project. 2.3.3. The Detached Engineering Team In many organizations, there is an artificial wall between the people who need the software and the people who build it. The engineering team often sees itself as a separate unit. The priorities of the people in the organization who need the software don't really figure into the way the engineers plan and carry out their work. This seems justified because it will take the team a certain amount of time to do their work, and no amount of bargaining with the business side will change that. In an organization structured like this, the senior managers and the stakeholders often end up frustrated with the development team. No matter how much pressure they are under, the engineers seem to be going at a slow pace. The engineers, on the other hand, feel like they are already putting in overtime to meet the needs of the other people in the organization, who never seem to be satisfied. The vision and scope document helps fix this problem by helping the engineers understand the project priorities. It identifies deadlines that are external to the project and that must be treated as constraints. The team can make sure that those deadlines are addressed directly when they are planning their tasks. They can warn senior management early in the project if the deadlines are in danger of not being met, and the stakeholders can be told when their needs are not being met. The stakeholders, in return, will feel like the engineers are taking their needs seriously. All of this can be brought about by a frank discussion of those needs while the vision and scope is developed. The project plan also fixes this because it represents an agreement between the engineering team, the stakeholders, the users, and the organization's senior management. Because it is based on the engineers' estimates, they know that they are given enough time. The stakeholders, in turn, are given a window into the planning and estimation process, which establishes a level of trust between them and the engineers.