In nearly all projects these days, project managers produce a project plan consisting of the work breakdown structure, resourcing, etc. Does the process begin and end with this plan? Many people would say the plan is the beginning and as events unfold this plan is updated with status, revised to address issues that arise, and ultimately completed. I would agree with this notion but suggest the project plan is not the first planning deliverable. It needs input not only for the work breakdown structure but also from other sources. These sources include those management processes that underly all of our projects.
In my projects, I produce a deliverable originally called a Project Infrastructure Document from my days at PeopleSoft to now a Program Management Plan. Each term is a good description as the infrastructure of say a house begins with the foundation. The same applies to projects or programs. So what are the foundation management processes and policies underpinning all projects? They include at a minimum:
• Communications Plan – defines the type, format and timing of all internal and external information dissemination about the program.
• Quality Assurance Plan – defines the use and timing of any quality assurance functions that can include, but may not be limited to, design and code reviews, milestone reviews, and metrics.
• Risk Management Plan – identifies any risks to technical or business goals, identifies the impact of the risk, likelihood of occurrence, and documents mitigation plans.
• Education Strategy and Plan – defines the manner and mechanisms by which individuals such as the technical staff and customer support staff will gain the necessary knowledge to effectively operate and sustain the developed solution.
• Testing Strategy – defines the types of testing required during the development, goals of each test phase, defines the drafting process for the test plans, and the process and tools required for testing.
• Configuration Management Plan - The configuration management plan defines those set of procedures to ensure that both the solution code and master data are maintained in a controlled fashion.
• Rollout Strategy/RoadMap– defines the relative timing and functionality deployed to production.
• Project Plan – baselined after completion of the first seven chapters, it pulls all aspects of the development into a consolidated execution plan. The project manager will update this plan periodically as solution requirements are finalized.
In addition to the chapters above, I have on occasion included project acceptance criteria, travel policies, and budget baselines when unique project conditions warrant a more formal documentation of these policies. By formalizing these processes and policies within an early deliverable, I am able to better assess and estimate the duration of activities which drive the schedule. For example, by understanding all the test phases, their objectives and who will execute the tests, the durations of each individual phase is better understood as well as the level of effort for my team. Imagine a circumstance when the PM is expecting a testing program that includes unit testing, system testing, and then a production decision but the customer is expecting a performance test phase and a user acceptance test phase in addition to the above. Including these additional test phases establishes a very different testing program and the associated schedule.
At a deeper level, consider differences in expectations around the objectives of each phase. I have experienced a customer that defined unit testing as the validation of the proper interaction of all solution components including interfaces, conversions, and use cases and with production like data. This definition is very different than most of us would expect and creates a different set of activities, staffing, and durations. Or consider a project where the testing phases require all severity level 1 and 2 bugs be closed before proceeding to the next test phase. These are very typical criteria with typical defintions of the levels but what happens if the definition of a severity level 2 includes functionality with workarounds, the dynamic changes.
The project plan itself is included in the document as with many contracts, the project manager may want to formalize the initial plan as the baseline upon which statements of work and budgets are committed. Project plans by nature are living documents while contracts and budgets are not, so having a more formal baseline or starting project plan can prove valuable when schedules begin to move to the right and either financial or legal professionals begin to ask for the circumstances behind this schedule movement.
Based on our experiences, we each bring assumptions to the processes defined in each of the chapters above. Some of these assumptions are identified in the paragraphs above as well as other conflicting assumptions which I have personally experienced. Highlighting those assumptions in written form brings them to the forefront and enables discussions at the outset of the project. Differences in these assumptions can be discussed and reconciled long before they have a negative impact to the project or cause anxiety between counterparts.
The program management plan has enabled me to remove or minimize risks of these circumstances occurring. The biggest challenge is taking the time early in the project to discuss and reconcile the details of these processes vice waiting until issues or misunderstandings occur.
Comments