In most projects, a project plan including a work breakdown structure (WBS), resources, dependencies, and durations is a very early deliverable for the project manager. From the charter, if available, the project manager defines a project plan with a major objective to get to the go-live date for the project. There is great pressure very early on to get to both the go-live date and the cost. In order to properly get to this plan and schedule, what are the activities required and the appropriate order to ensure the most solid project plan? The paragraphs below define recommendations for those steps and the order. There may be some variance depending on the organization, contract structure if applicable, and the implementation methodology.
Program Management Plan
One of the key deliverables in the initial week or so of a new project is the Program Management Plan (PMP) discussed in more detail in the this post. This deliverable defines multiple key underlying processes that do not manifest themselves in tasks on a project plan but provide a process foundation upon which the project plan is built. Key processes and management plans defined include:
- Communications Plan
- Risk Management Plan
- Configuration Control Plan
- Education Strategy and Plan
- Test Management Plan
- Quality Assurance Plan
Once these underlying processes are defined, detailed tasks and assumptions within the project plan unfold. For example, if the Quality Assurance Plan calls for a detailed design review or a code review the project plan will naturally include these tasks. The configuration control plan may include the process constraint of building all new environment directly from source control vice another environment which enables the project manager to ensure all solution components are both known and under source control. The Education Plan may contain formal training sessions for end users that spawn training material development and training conduct tasks.
Risk Assessment
A formal risk assessment at the project outset can be included as part of the Risk Management Plan in the PMP. This assessment affords the project manager and any project sponsors to take a comprehensive, thorough, and global view of the project to ascertain assumptions, processes, staffing, etc that may cause the project to go astray. In many cases, companies and outside vendors like Deltek have formal risk assessment tools that provide the project manager a process for assessing risks and queues the project manager into areas not previously known to investigate.
These assessments will review the project and determine the appropriate implementation methodology, staffing profile, schedule, dependencies, etc and afford the PM the best opportunity to build a project plan with an appropriate balance between risk and the triple constraints of quality, schedule, and budget. Given the potentially sensitive nature of the risk assessment contents, the list of risks is typically published to the entire project team while the supporting prose is kept to the project sponsors.
WBS structure first
The overall structure of the project is typically the first step within a project planning tool such as MicroSoft Project, Open Project, or Primavera. Depending upon the implementation or development methodology, this could consist of the waterfall phases of requirements, design, build, test, and deploy or a more iterative/agile approach where scope is defined up front, the formal testing and deployment activities at the end, and the sprint structure is defined. This also affords the PM the opportunity to look strategically at how the project will systematically move forward, the objectives of each phase, and potentially entrance/exit criteria for each major milestone. Additionally, the PM can incorporate those PMP processes that include tasks such as quality assurance reviews or training.
This overall structure is also a good point in which to brief and reach agreement from the sponsors on the WBS. Note at this point, we have not defined a schedule but are focusing on the management controls and project flow.
Scope definition
Assuming the project contains contracts or agreement pertaining to scope, the definition of this scope is the next logical step as it will inform the details of both the following detailed tasks and durations and dependencies sections. The approach definition in the implementation methodology and WBS will define both how the scope will be defined and documented. The testing and quality assurance plans and the associated tasks then define how the scope is confirmed satisfied by the solution.
Detailed tasks
Once the scope is appropriately defined, the people who will perform the work are engaged to define the detailed tasks required to complete the scope. Consideration should be taken at this point to the order in which the functionality is built. This consideration can have a profound impact on the testing approach and effectiveness so is a good point for the PM to provide input.
These tasks are defined within the project planning tool so the project plan becomes more than just a high level WBS and begins to take shape.
Durations and dependencies
The final step is to define the task durations and dependencies between the tasks. There is a strong tendency at this point to begin to look at the schedule and adjust these two parameters to get into a pre-defined schedule. I recommend PMs resist this urge in order to define an initially unconstrained schedule.
Schedule falls out.
Once all the above activities are completed, the PM has a well developed yet unconstrained schedule. Unconstrained schedules are useful in they provide an initial view of the schedule. In most cases, this view is modified to conform to business constraints or tasks and activities are reviewed to look for efficiencies that will pull the schedule back to the left and within achievable business parameters. The market also have tools designed to review these schedules and provide insight into high risk errors and detect subtle errors that may drive out a schedule.
The approach at this point is to ensure strong reasons are available to change project or scheduling assumptions. There is a tendency to take risks not normally permissible when an unconstrained schedule is defined and far outside of needed constraints. PMs and project sponsors should reassess the project if finding themselves taking extraordinary risks to achieve the triple constraints. What may make more sense is to return to the beginning of the project initiation or planning processes to understand and re-evaluate the basic assumptions of the project.
The post above provides a one approach for defining a project plan and associated schedule. There are many nuances associated with the planning process that may define a process different from that noted above. PMs can use the above process to fine tune their process if it is unique to their organization or use the above as a starting point.
Comments