The Art of Project Planning

by

A project, defined by the Project Management Institute is “a temporary endeavor undertaken to create a unique product, service, or result.” There may be aspects of a project that are repetitive, such as a software upgrade that occurs periodically. However, the project itself, by definition and in practice, is unique. In some large organization software upgrades is often the work of a dedicated professional though every upgrade project deals with different systems, different end users, time frames, levels of exposure to mission critical systems, and a practically infinite combination of other factors.

A project’s purpose is normallythe creation of an entity or process that will continue, and only once formed can the project be released to others and run in a “business as usual” environment.

The combined experience of uncountable individuals over the course of several decades has given us many methodologies for successfully running projects, each one tailored for a general end result. For example;a project’s purpose to designa protein molecule-based computer system will be planned and managed entirely differently from one which is created to erect a building.

All projects have one thing in common: They Begin, and therefore, must be planned. To continue on from our Project Initiation article in our previous issue, the next step: The Art of Project Planning is briefly outline below and describes this stage of the Project Management cycle and the people and processes involved.

Developing the Project Management Plan

Integration Management

The process—better stated, the art—of project planning begins with the development of the Project Management Plan. This is one of the main deliverables of the project management team, and is composed of all relevant information concerning how the project will be planned, executed, monitored and controlled, and closed. The Project Management Plan is iterative, especially in the planning stages of the project, and is a very fluid document. Developing this document is the result of documenting the steps necessary to define, prepare, integrate, and coordinate its subsidiary plans. The key process above is integration, which is why development of the project management plan falls under the PMI heading of Project Integration Management.

Scope Management

No project can be planned if its end result and full effect on other people and processes are ill-defined. Therefore, logically, the next step in project planning is Scope Management. From a well-executed project initiation phase, the project manager should have a Project Charter, a Stakeholder Register, and a Requirements Document. With that information in hand, the project team can collect requirements to fulfill the project objectives. However, as the team drills down into specific requirements, they may discover effects on other processes and the need for additional stakeholders which will cause modifications to the initial Project Charter and Stakeholder Register.  The Project Planning Phase is designed to reveal shortcomings in the Project Initiation Phase. Discoveries at this stage should be expected and even welcomed.

After gathering the required data, the project team, including key stakeholders, is in a position to refine the initial Scope Statement from the Project Initiation Phase. The team should now have a detailed description of the project sufficient to create a Work Breakdown Structure, also known as the WBS. The WBS, as its name implies, documents large, high-level work packages and breaks them down to manageable units and defines those units so that their completion criteria are understood and can be agreed upon by all project team members and stakeholders. At this time the project team is ready to “baseline” the Scope Statement, meaning that it is complete, and agreed-upon by all stakeholders and used as a reference point for any future scope change requests. This is a requirement, as the next step in our planning process is defining the activities and resources required to complete all project objectives included within its scope.

Time Management

Using the Scope Statement and the WBS, the project team undergoes the arduous task of defining activities that will be required to complete the project’s deliverables. The team will take into account organizational assets and processes to complete the list of activities and its dependencies in order to sequence them properly. Once the activities are sequenced and the dependencies understood, the team can create a Network Diagram, a graphical representation of each activity with its corresponding input and output processes and activities.

The team then has toestimate activity resources and the duration, ie: delegating responsibility for each activity, and evaluating the timeto complete each and calculating if any other resources are required. As an example:  Task Y will take one software engineer two weeks, working four hours per day and will require root access to a specific UNIX test and development server, with the ability to reboot at any time. He cannot start his work until Task X is complete, and TaskZ cannot start until the software engineer completes Task Y.

Even a relatively small software development project can easily end up with a task list in the hundreds;evaluating each task’s dependencies and estimating its duration is not a trivial task. It is exactly here that a lot of project planning shortcuts are made, and it is exactly from here that many projects finish behind schedule and exceed their budgets.  In developing the detailed list of required project activities, the project team may discover unforeseen dependencies. By examining the details during the planning phase, the project team can uncover risks and issues that would otherwise go unnoticedin an earlier phase of the project.

The project manager ensures that the activity list is completebefore developing the schedule—setting time frames for each task and delegating them to a team.  Based on this information, cost estimates for personnel and material required to complete the project can be determined for the budget.

Cost Management

In many cases this estimate can vary from the original budget and the project team would have to revisit the original assumptions, including the “preliminary” budget, for a reality check. If, at this initial phase, it isdiscovered that the original estimate and new budget requirements are significantly different, revising the project scope or considering cost reductions are not big hurdles. At this stage, changes in the project are relatively inexpensive, and there are a number of solutions that can be employed if the expected project costs are higher than acceptable.  In short, the budget can be decreased in several ways – by reducing the scope, extending the project timeline, utilizing lower grade personnel, and otherspecifics to the project. One method of affecting budgetthat does fall within the Planning Phase is in Quality Management.

Quality Management

The Quality Plan is the process and output of identifying the specific quality requirements for the project and its end result, and alsodescribes how quality standards will be met. The quality ofa product or process that will be the result of a project is specific to that product or process, however, the quality of the project is normally measured in terms of schedule and cost.

Schedule and cost variance measurements are topics of not only uncountable articles, but entire books and will not be written in detail here. The Quality Plan document should include checklists of what characteristics of the projectand its end product will be measured against, and also clarify how quality will be defined and measured.  For a product to meet quality standards there must be well defined and understood expectations of measurable results since expectations cannot be fulfilled if they are not known.

Human Resource Management

With the estimate of resources and durations, the project team can prepare the Human Resource Plan which documents who will be involved in the project, but when, and also provides invaluable information in determining resource constraints. For instance, if a specific Engineer A is required on a full time basisfor an identified period, the project manager may find that Engineer A is also required for another project at the same time.  It may be discovered that additional contract resources will be required at a point in the project, or a new software package installed and the team has to undergo training, resulting in a loss of scheduled time.

Communication Management

The three most important aspects of successful project management are, in this order, Communication, Communication, and finally, Communication. There is not an experienced project manager this side of Alpha Centauri who will not have a horror story to tell concerning miscommunication. Designing and holding to a Communication Plan that all stakeholders have agreed to is, to understate the matter, absolutely, positively vital to the smooth operation and success of a project. A Communication Plan includes what information is provided, and to whom, when, and in what format. A common format for this document is a grid, with documents, including frequency and delivery formats in rows, and the stakeholders who will receive those communications across the top. Check marks in the grid indicate who receives the specified information. The Communication Plan also includes information on standing project meetings and who is expected to attend.

Risk Management

Despite meticulous planning and armed with vital knowledge from the Project Management Body of Knowledge book from the Project Management Institute (all 506 pages in PDF!), there are still unknown factors that can cause problems to a well-run project. That is why project planning is crucial and frequent brainstorming and risk analysis meetings are important.   Risk, in project terms, is any factor that might negatively, or even positively, affect the project. A Risk Management Plan lists and categorizes all risks that the project team or stakeholders can perceive.  Once a risk is identified, the project team will list it on a Risk Matrix document and categorize it according to its probability and effect on the project, should it occur. Armed with this information, the project team can then devise a mitigation strategy—how to react if the event occurs— and a risk reduction strategy if possible.

Project management best practice also identifies another type of “unknown” risk, which of course is not listed on the Risk Matrixbut should be included in the budget as a line item although the effect on the budget is not known, many organizations use a rule-of-thumb percentage of the planned budget as a holding place for costs associated totally unforeseen risks. With experience, a mature organization can predict that X percent of projects would need to use their “unknown unknowns” risk budget andin this manner, budget overruns, for this purpose at least, will be kept to a minimum.

Plan Procurements

The final part of the project planning process is Procurement Planning when the scope, personnel, work packages and task lists are completely understoodand equipment requirements are apparent. Thereafter, in the last phase, the project team evaluates the purchasing requirements from the standpoint of make or buy decisions, purchase or lease, time for order processing, vendor selection, and all other criteria for bringing new equipment and services into the equation.

Moving On

Indeed, it is rare that a project can complete the planning process and simply close the books. Experience shows that even with the best-planned projects there is still the need to revisit each planned item at some stage during the process. Multiple evaluations should notautomatically be considered as indicative of incomplete planning as today’s standard operating procedure, can easily be tomorrow’s relic, and this sudden change can cause havoc amongst all current processes and procedures. A good project manager and team will accept these events as normal, revisit the affected process, budget, timeline, or any other part of the project, and adjust, re-baseline then continue toward the objectives of the project.

After all, that’s what change is all about!

by