Best Practices for Successful Project Control, Written by Tom Flynn
Why is Project Control so difficult and time consuming?
This is a good question to start this article with! Over the years we have seen project control done easier (not easy) and have seen it done very difficult and without the results required and/or expected. In witnessing the difficult efforts we have noticed that many times the project manager is:
- Attempting to control items that are not properly decomposed and/or organized with monitoring, tracking and analysis in mind; the “herding cats” analogy works here.
- Attempting to control items that are not of major significance to project performance (majoring on the minors).
- Attempting to implement practices that are too sophisticated based on project size or complexity and practices, which even when applied properly won’t make a marked difference in directing and/or re-directing project performance issues (practice overkill).
The project managers that are successful avoid these three scenarios like the plague and have a very good sense of what project elements require monitoring, tracking, analysis, and control (corrective actions) and match this realization to basic practices that (1) are effective and (2) they actually have time to apply. Time to apply is especially important when the project manager is managing multiple projects.
This article will focus on three basic practices that have been highly successful, and outside of certain industries, may not be known that well.
Project Control consists of making full use of project management practices and tools in order to conform to baseline expectations by identifying critical scope areas, organizing work elements within these areas so they can be monitored, tracked, analyzed, and where necessary controlled by specific and targeted corrective actions.
Can effective Best Practices be implemented without a major time commitment?
The answer is yes with caveats, and we will discuss three practices that can be implemented without a major time commitment and or complex technology applications. Before we get to discuss these practices let me mention the caveats. The implementation of any successful “control practices” must be preceded by an investment in understanding what is critical to the project and getting those items ready to be monitored, tracked, etc.
“Ready to be monitored” means that milestones have clear deliverables, deliverables have clear tasks, and tasks have clear and measurable performance metrics. This doesn’t mean the project manager will be involved in task monitoring, especially for larger projects yet, it does mean that the subjectivity that usually impedes successful performance monitoring must be minimized prior to work progressing. The three basic best practices we will be discussing are Rolling Wave Planning, Milestone Management, and Burn Rate Analysis.
Can Rolling Wave Planning be considered an Agile practice?
Rolling Wave Planning (and execution) has been around as a best practice since the early 1960’s, although I’m sure that in the 1960’s it was not thought of as an Agile method yet, it does align perfectly with Agile objectives in that “you cannot plan in detail what you do not know in detail.” RWP offers a bridge from traditional planning to execution norms to more Agile focused project management practices.
When using Rolling Wave Planning, the total scope of work is reduced to two different forms of “packages”:
- Work Packages: work we are familiar with and can define, estimate, and schedule accurately, assign resources to, execute and track.
- Planning Packages: work we have identified that we are not familiar with and further planning is required to define detailed execution tasks and estimate/schedule accurately. Also, work that arises as a result of the RWP process also starts here in the planning package process.
The process for generating work packages from planning packages is actually not a difficult one. What is difficult is that both planning and work packages will be worked on during the planning and early execution phases of the project; and are often undertaken by the same resources.
- Identify the planning steps that will be required within the planning package, in the example below Planning Package PC.PP01.
- Estimate the duration of the planning package execution.
- For overall scheduling purposes, we will need a “best guess” estimate, or place holder estimate for the work package that will be revised at the completion of the planning package. Generally, this will be based upon major tasks we are aware of, yet do not have detailed task definition for at this time.
- Execute the planning package tasks
- With the clarity and scope cognizance developed in the planning package execution, define the detailed work package tasks, in the example as Work Package PC.WP01, and revise the work package estimate as required.
- In this example, planning tasks are complete, detailed tasks for the work package are defined and assigned and integrated into the performance baseline.
As previously mentioned, the same resources may be used for both planning and execution; therefore, we must have the discipline to ensure that planning packages are complete prior to moving to an executable work package. Experience shows us that the line of planning package completion can be blurred when resources are working on both planning and execution, and execution timelines become compressed.
How do we effectively measure and monitor milestones?
Milestone Management is a sound technique for small, medium, and even larger projects that do not exhibit a great deal of integration complexity (many different functional contributors).
Normally, milestones are thought of as bookmarks in time, a place to stop and take a “pulse check” on the project. A phase completion milestone is a good example of this. Yet, all too frequently these checks for completion become an exercise in subjectivity. In order to combat against personal perceptions skewing percentage of completion analysis, we can utilize a “milestone attribution” approach. This method is useful where the cost of and time to monitor a larger and more complex control system is prohibitive.
Attributing milestones is simply the process of identifying and assigning deliverables (drivers) to the milestone in question, and attaching critical success criteria (metrics) to the deliverables in order to ascertain accurate percentages of completion for each deliverable, and in aggregate, the milestone.
The deliverables for the milestone attributes can be literally any deliverable between two monitored milestones, and they should be critical to the completion of the milestone being monitored (hence-drivers). These deliverables can be weighted for their overall importance to the milestone’s completion, yet not mandatory. The milestone is then weighted for its overall importance to the project’s completion.
As project managers, we can therefore eliminate the time spent analyzing each and every task for its performance and focus in on the critical milestones. Task leaders would still be monitoring their tasks individually to ascertain progress at that level, and that information would be utilized to build the milestone attribute percentages of completion.
There are four process steps:
- After the WBS and definitive schedules have been determined, the project team must decide where milestones should be inserted in order to accurately and efficiently monitor and control the work to be undertaken.
- After the milestone insertion points are determined, the project team must decide which deliverables, from which tasks, are critical to the milestone’s completion.
- After the deliverables for the milestone are determined, and to lessen subjectivity, the project team must develop a set of clear critical success criteria (metrics) for the completion of these deliverables. Each deliverable should have its own clear and easy to measure metrics.
- After the metrics have been established for each deliverable, the project team may apply a weighted ranking (in percentage) for each deliverable (not mandatory)
The above steps are completed for each project milestone or phase. Upon completion of this process, all milestones must be percentage weighted for their overall importance in the completion of the project effort. Once these processes have been completed, we have set up the baseline for monitoring our project accurately.
Below is an example of a Milestone Attribute Sheet that should be utilized for this monitoring process.
It is not uncommon to track and trend work-package level work using Burn Rate and report to senior management in Earned Value format at the project level; this is a sound practice used by many senior project managers where there are very critical work packages in progress, and eliminates nasty surprises!
The basic components for utilizing Burn Rate are as follows:
- Person Hours Scheduled (PHS) – The person hours scheduled for the completion of work for any given task or group of tasks during a specific period.
- Person Hours Expended (PHE) – The actual or estimated person hours expended for the completion of work for any given task or group of tasks during a specific period.
- Percentage of Completion Scheduled (PCS) – The percentage of completion scheduled for any given task or group of tasks during a specific period.
- Percentage of Completion Generated (PCG) – The percentage of completion actually generated for any given task or group of tasks during a specific period.
In the Project Example below the project team has available…
- 380 Person Hours per month; let’s see what our average burn per week is in both Person Hours and Percent Complete
- 380 Person hours / 4 weeks = 95.0 hours per week
100% / 4 weeks = 25% per week
- A simple Burn Rate Ratio would be 95 / 25 = 3.80 hours per each 1% of completion (3.80 : 1)
- So, we would expect a certain amount of hours to be burned to establish 60% completion of the above task: 60 percentage points x 3.80 hours = approx. 228 hours, and we can easily tell at a quick glance if this was so or not
Calculating the Proposed Burn Rate for any task as follows:
Let’s review the basic formulae for Variance and Index (ratio). They are as follows:
- Burn Rate Variance (hours) = PHE-PHS (result of >1 indicates over our hourly budget)
- Burn Rate Variance (% comp) = PCG-PCS (result of <1 indicates less performance than expected)
- Burn Rate Index (hours) = PHE/PHS (result of >1 indicates over hourly budget)
- Burn Rate Index (% comp) = PCG/PCS (result of < 1indicates less performance than expected)
As can be seen in the example below and using the fairly basic project data, we see that the team is currently over budget with their person hours and is lagging in deliverable completion. For a longer duration task we might not panic yet, is a one month task, gaining back lost performance is very difficult.
Using the Prior Project Example…At end of week 2, cumulative totals are as follows:
- 210 Hours expended (190 scheduled)
- 45% complete generated (50% scheduled) therefore…
- BRV(H)= PHE-PHS or 210.0-190.0=20.0 PH (Over)
- BRV(%C)= PCG-PCS or 45%-50%= -5% (Over)
- BRI (H)= PHE/PHS or 201.0/190.0=1.11 (Over)
- BRI (%C)= PCG/PCS or 45%/50%=0.90 (Over)
Utilizing the basic information we have developed and understanding the current Burn Rate of any task, we can forecast whether or not the team will stay within the baseline expectations.
Also any form of trending practice assumes that performance will stay consistent in the “out-periods”. This has been proven to be not aligned with reality as performance usually slows at the end of deliverable development, especially towards the end of the project. So if the analysis shows they may “just make it”, in reality, they won’t!
Understanding the “resource profile” will help apply the results of the analysis practically. Recovery efforts that include increasing the performance rate (burn rate improvement) need to be backed up by a shift in strategy and a sound plan for implementation, otherwise it’s basically wishful thinking!
Although project control practices shouldn’t be considered easy to implement, there are basic best practices that, with proper and prior planning diligence can be implemented across a wide array of project types while matching investment in time and effort with positive project results.
- Westland, Jason. “The Project Management Life Cycle: A Complete Step-by-Step Methodology for Initiating, Planning, Executing & Closing a Project Successfully” Kogan Page, 1st Edition, 2007
- Zwikael, Ofer. “Project Management for the Creation of Organisational Value”; Springer, 1st Edition, 2011
- Turner, J. Rodney. “The Handbook of Project-Based Management: Leading Strategic Change in Organizations” McGraw-Hill; 3rd Edition, 2008
- Lewis, James P. “Project Planning, Scheduling and Control: The Ultimate Hands-On Guide to Bringing Projects in On Time and On Budget”. McGraw-Hill, 5th Edition, 2010.