Project Planning

Project Planning

Why plan? Won't the plans just change anyway? Why waste a lot of time and effort writing down what we think we're going to do, just to have blind luck change it all before we're done? Why not "just do it" and handle whatever happens whenever it happens? These are good questions in a world changing at Internet speed. Whatever life cycle roadmap you choose, doubts abound, and your team may end up achieving something different than what it initially envisioned.

Referring to the mountains of planning documents prepared for the historic D-Day invasion of Europe on June 6, 1944, Gen. Dwight Eisenhower said, "Plans are nothing. But planning is everything". He recognized that very well-thought-out and detailed plans are also very delicate in the face of fate and doubt. But he also knew that the depth of understanding of the problem space that came from the work to prepare the plans would enable his team to react intelligently to new situations. They would be better prepared to seize new opportunities and avoid serious mistakes. Good luck is where preparation meets opportunity.

Project planning is the process that lays the framework for how the project will be run. It contains the definition of the project's objectives, selection of an appropriate life cycle, and establishment of the policies, procedures, and processes required to achieve the objectives. How much framework you need to write down depends, in part, on how mature your organizational environment is. If your team is a freshly hired group of people from many different backgrounds who haven't worked together, with you or your organization, more structure is required to guide them. If most of your team has been working together for a while, only a skeleton framework and simple checklist is needed. The team probably already has enough cultural heritage to flesh out the plans well enough using established reporting structures, definitions, and work products.

The old jokes about planning are "Ready, fire, aim" and "You go ahead and get started coding while I go upstairs and find out what they want". Also, many projects have followed the tongue-in-cheek life cycle shown in Box 1. Let's hope your projects don't follow this life cycle.

A Commonly Encountered Life Cycle in Low-Maturity Organizations

Regardless of the life cycle chosen for the project, there will be two different sets of processes followed:

Project Process Framework

Project Process Integration Map

The product processes are introduced in "Process Overview", "Selecting Software Development Life Cycles" and "Managing Domain Processes" and are discussed in detail in "Introduction to Software Engineering", "Reliability", "Software Metrics", "Analysis and Design Methods", "Validation and Verification" and "Use of Tools". The project processes were introduced in "Process Overview", and will be discussed in detail here as we look into how to carry out a particular instance of a project plan.


Every project requires a good reason to exist, and this step ensures that there is at least one. Using business analysis suitable for the organization, the project manager should perform an opportunity analysis and prepare a return on investment (ROI) statement for the project. This raison d'etre may be just a statement indicating that the project has high strategic value and must be accomplished for other projects to exist, or it may be a complete ROI prepared by financial experts showing net present value (NPV), internal rate of return (IRR), payback period (PBP), or other acceptable calculations. Whatever the reason is, it should be recorded and generally becomes part of the project charter.


When a good reason is identified for proceeding with the software project, the goal and scope of the project can be defined to differentiate it from ongoing operations. Called a project charter, this is generally a simple outline statement of what the project will achieve, including major deliverables, a rough high-level schedule, an initial estimate of resources required, and the expected return to the organization for the effort invested. The charter has two purposes:

1.  To formally document the existence of a software development project and to separate the work of the project from ongoing operations such as maintenance and support; and

2.  To obtain management approval for the work to be done and to get commitment for the resources to do it.

The charter may take the form of a legal contract and statement of work (SOW) for external work to be carried out by a third party outside the project manager's direct control. In this case, the details of the "how" may be left up to the contractor.


With the authority granted by charter approval, the software project manager can employ the many other software engineering and people skills required to define the product and manage a team to develop and deliver it. This is the heart of software project planning. The major work product of this step is the software project management plan (SPMP). The SPMP explains (in a proper level of detail for the maturity of the performing organization) how the life cycle steps will be performed. These may vary for every project even though the basic life cycle used is the same. This is the roadmap that the project team will follow to prepare the software deliverables and meet customer expectations. Generally for large or long-duration projects, iterative planning is used, with detail planning done only for the next immediate step of the life cycle as the project progresses.

Do It

When the SPMP is completed and approved (by the customer or by management), the team can execute the plan, following the life cycle steps chosen for this specific project instance. Even if a spiral model using rolling wave planning is chosen, the SPMP should be the roadmap to guide the team toward project completion. This step uses most of the information presented in this blog for the 34 competencies.

Did It

Commensurate with good process management, an evaluation step should be performed before closing out the software development project. This is the post-performance analysis (PPA) step, and it results in a PPA report documenting lessons learned and recommendations for project or product process improvements for the next similar project that the organization attempts.

These five steps are necessary for every project, large or small, short duration or long, regardless of the project's intended output. The variables of size, scope, cost, schedule, complexity, and risk determine how much rigor and documentation is needed in each step, and which development life cycle should be used. Even a small project such as assembling a child's bicycle for a birthday present is a project that requires thinking through these five steps. But it isn't likely that you would make an effort to document it for posterity.

The Project Management Institute (PMI ) cites five processes necessary for any project, or phases within a project: initiating, planning, executing, controlling, and closing.

Figure (b) illustrates that the initiating processes are where the why step is handled. It contains enough of the what step to explain the project at a high level. The rest of the what step and the entire how step are handled in the planning processes. The do it step is composed of the executing and controlling processes, and the did it step is covered by the closing processes.

For the product processes shown in "Defining the Goal and Scope of the Software" Figure (a), the project planning process starts in concept exploration by ensuring that you are pursuing a solution to the right problem for your customer, or much effort is wasted. This is where the why of a project is explored.

In "Eliciting Requirements", and "Developing the Software Requirements Specification", we will examine the development of detailed requirements.

Planning is an iterative process, generally done repeatedly during the course of a project as conditions change and new knowledge is gained. But the objectives set early should remain fairly static; otherwise, the project will wander aimlessly and should be cancelled and then redefined. Objectives are generally interrelated. If some objectives conflict, management must prioritize them or the project will not be successful.

The general approach fits into the framework described in Figure (c).

Relationship of Project and Product Life Cycles for a Software Project


life cycle, project charter, software deliverables, software project
The contents available on this website are copyrighted by TechPlus unless otherwise indicated. All rights are reserved by TechPlus, and content may not be reproduced, published, or transferred in any form or by any means, except with the prior written permission of TechPlus.
Copyright 2018 SPMInfoBlog.
Designed by TechPlus