Improving the Planning Process
This chapter is from the book
This chapter is from the book
This chapter is from the book
It is incredible that so few project plans are the product of a coherent planning strategy. How can a process so predicated upon the importance of a clear and detailed development plan be itself so poorly planned? The very planning process that strives to avoid the horrors of seat-of-the-pants programming is itself typically a seat-of-the-pants process.
This section discusses various topics relevant to creating a software blueprint, starting with the need to adopt a comprehensive plan for attaining that goal.
3.1 A Project Planning Plan
The first step toward an effective software development process is to create a project-planning plan that produces a complete blueprint as efficiently as possible. Those of you who have been doing software planning may feel that you have followed a standardized process. At the very least, you probably implement the industry standard envisioning and specification phases.
For many companies, this means that you throw vision and specification templates into a shared folder and create some spreadsheets to track changes and meeting notes. This may be business as usual, but it is woefully inadequate for the task of producing a quality specification.
At the very least, you must engineer and implement the kind of structured, integrated, process automation system that you would recommend for your clients when you discover the disparate tools and haphazard strategies they use to drive their businesses. You must use all the same sound business workflow and process automation strategies that you would advocate and sell to your clients to make their businesses competitive.
Since the typical process of producing software planning documents is so ad hoc, it is not surprising that they lack internal consistency, that their format varies widely, and that they contain a great deal of superfluous information. They don't provide the developers with the proper information required to deliver the product as expected. In short, the deliverables of the planning phase suffer from all the worst characteristics that we fear most in failed software.
If this is true, why doesn't this situation get recognized more often? One reason is that since the project plan is not an executable product in the same way that a program is, its flaws aren't as evident. Since there is probably no standard for comparison, and probably no evaluation process for project specifications, their complicity in failed projects goes largely unobserved.
We see the value of coding specifications. How often do we develop comparably detailed planning specifications? We see the value of code reviews. Do we ever talk about specification reviews? We wouldn't ship software without testing. How often do we quality test our project specifications? Even in the better shops that conduct design reviews, these tend to focus on missed business requirements, not on evaluating the effectiveness of the specification for development purposes.
When you start to appreciate that software planning should itself be a software project, you can begin to apply the same structured thinking to creating a planning plan. You begin to appreciate the need to map out a more detailed and methodical strategy for your software planning. You standardize on tools and process. You train personnel in project planning. You apply management principles and track progress and changes systematically. You envision deliverables that truly meet the needs of the internal customers in an efficient and cost-effective fashion. You start to drive the planning process toward that end with much greater clarity of purpose and method. You put testing, validation, and process improvement strategies in place to improve your planning process.
In short, your first job before you take on any software development project should be to develop (or at least adopt) a system for producing a software blueprint. That plan should be clear, precise, and customer-oriented.1 It should provide not only general approaches and philosophies, but a practical, efficient, automated infrastructure for implementing that planning plan. Finally it must be easy to understand and use. If it doesn't get used, then it needs to be improved until it is too elegant and effective not to use.
The bottom line of this section is that you should have a planning system as tight and efficient as any production system you would recommend for clients to automate their business processes.
The next project you take on should be an internal project. Commission a team to develop your project planning process and the automation infrastructure to implement it. This need not be totally ad hoc. This book can form the core of that process. Start with the solutions presented in this book, adapt them, and extend them to meet your needs.
Do you have to get it perfect the first time? No, but you should make sure that your planning plan includes a process for evaluating and improving itself. Err on the side of keeping it lean rather than trying to do too much. As happens with software planning, far too many efforts fail because the people involved overspecify. They try to do too much all at once and nothing gets done. Start with achieving the basic blueprint as your core and build from that. Lay down a solid foundation and decide later if it will truly benefit from additional complexity.