This is probably the single most difficult area for the PMO and the PM’s that are in the performing organization to address. How do you effectively setup, control and report on overall project schedule progress, without seeming like a Motorcycle Officer that has just pulled someone over on the freeway and already has the ticket book out. Before we talk about the things that should be done to provide Value Added Service in regards to scheduling, lets talk a little about what not to do. I’m absolutely certain, that we all have our horror stories, but this is more about attitude and teamwork, than it is about process and control in the performing organization.
If you setup rigid formats and rules associated with the development and eventual maintenance of a group of project schedules, and expect that everyone will perform to the same standard, you will have started out on the wrong foot. Having standards and guidelines are certainly important, but the PMO must work with each of the performing PM’s and teams to make sure that the finished product satisfies the needs of management, the PMO and be such that the project team can work with it and recognize that their plan is truly theirs. Having clear guidelines on the deliverables that are expected, along with the proper reviews and approvals necessary, are certainly warranted. In addition, how the general flow of the project will be detailed out is also appropriate. If there is not ’some commonality and purpose’ to your organizations schedules and plans, it will make it very difficult for both the PMO and Management to properly review and analyze progress across many different project types.
Some areas that you also need to have commonality in is the approach and methods that will be used to ‘progress’ your schedule. This is an area whereby many tools (such as MS Project and others) have the ability to automatically schedule and progress your schedule based upon manual updates that you have made and the amount of work left to be done. While this functionality does exist, it brings us to one of the key points that must be considered, when making decisions on how and when updates and complexity in your schedules will be used.
Advanced methodology and tool usage is directly proportional to the PM Maturity Level of your organization.
If you do not truthfully analyze and gauge the PM Maturity Level of your organization (both from the Performing Organization up to Exec. Management), the tools, processes and methodology that you use to report on scheduling activities; will make it very difficult to be effective in all areas and not just within the scheduling area. You can put together all different types of metrics and reporting from within your project schedule(s), but unless the purpose and the results that you are reporting on are truly understood at all of the project management levels – you will simply be adding to the burden that you may already have. On a previous assignment and area, we had available to us a very well designed and implemented toolset, built into MS Project, that provided all types of statistical data on project performance, as it relates to the schedule. Problem was, that almost no one except the authors of the tool, and those that had used it within other departmental and client PMO areas, understood the data or how to analyze it properly.
Yet, another metric that someone was able to get out of MS Project, showed just how effective doing the right analysis and data collection could benefit a very large project/program. The program spawned some 12 or so different departments, with the total number of separate projects being managed between 50 and 60, at any one given time. The metric was simple to extract, plot, and understand. Each week, the PMO would run a pre-defined filter that extracted the % Complete and due date on all milestones within the project plan for the reporting period. The PMO had made sure that all critical deliverables and checkpoints had an appropriate milestone defined. All milestones were then plotted in a simply line chart that had two lines. One represented the running total of all milestones to date that were due, and the second represented the running total of all milestones to date that had completed. In short, the ‘running total’ was plotted and updated weekly.
The results were very easy to see and understand for virtually everyone. If the two lines stayed very close of on top of each other, than the milestones completed result would be the same (or nearly the same) as the milestones ‘planned’. If the distance (or gap) between the two lines started showing a gap, then the resulting plot indicated that milestones completed lagged or did not meet the milestones planned. The farther the gap, the worse the performance. After a gap grew and remained constant for a number of weeks, when the two lines started coming back together, it indicated that the project/program was now gaining ground and improving. While this didn’t tell the entire story, it was very easy to tell how the overall program was doing. The same plot could be run on any individual project, group of projects, or departments group of projects. While this is not a complete picture of what is going on, it shows that the correct type of metric, and it’s resulting report – can provide you with tremendous insight.
Although we have talked about a few specifics and ways to look at scheduling while providing value, we also need to look at some realistic and needed guidance or governance that the PMO should deliver. Listed below, are some of the items that we generally expect from any PMO methodology and process. While it is not definitive, it does represent some of the thought processes and ‘rules’ that need to be put into place so that you have a common basis to both perform and report on. Let’s start with setting and maintaining a baseline.
Baseline Functionality
- All baseline functionality will be controlled and administered by the PMO. The following guidelines will be used:
-
- Initial baseline will be kept ‘historically’ within the MS Project files, as Baseline 1.
- No changes to Baseline 1 will be allowed.
-
- ‘Current Baseline’ activity will be used for day to day management and reporting (within MS Project – simply referred to as baseline).
- Any newly approved tasks, added to the project schedules (after base lining), will have their ‘current baseline’ set on a task by task basis.
- Any newly approved tasks, that drive downstream delivery dates out, will require a change control to be approved.
- New tasks that are added, to ‘further decompose’ an existing task (add clarity and needed detail) – will be allowed as long as there is no date change to the expected deliverable. Any decomposing of an existing task that results in a date change, will require a change control.
- The only time a ‘current baseline’ will be modified or reset, is after the completion and approval of a formal change control. Change controls of this nature, will need to identify both the specific changes being requested, and it’s impact.
Basic Scheduling Updates
Updating and completion of Tasks – 100% Complete – PM’s shall update the actual start and actual finish to reflect what has happened. If the PM simply marks the task 100% complete, without updating the Actual Start and Finish, then the ‘actual’ dates will reflect what was planned, as opposed to what happened. Something to watch for: Tasks that are marked 100% complete, with finish dates in the future. This is a poor representation of the work done, and also will drive the schedule out on dependent tasks incorrectly.
Updating %Complete on major deliverables – seat of the pants or per a defined process? Most of the time, a PM will mark a task for a major deliverable (such as Requirements) based upon where they ‘feel’ they are at. An alternate method is to use a scale such as the following:
- Started – 5% Complete
- First Draft – 25% Complete
- First Review and Rework – 50% Complete
- Presented for formal review – 75% Complete
- Presented for formal approval – 95% Complete
- Approved and put under change control – 100% Complete.
Following a process similar to this (you and your organization need to decide what the measurements and %’s should be), you will then have a far better handle on progress, by simply looking at those deliverables and seeing where teams are at.
Define and use predecessor tasks appropriately. If the PM or Project Team have setup and defined their structure to drive dates to a predefined result, then they are not being used properly. Predecessors should be used to properly define the dependencies between tasks. This is a common mistake that is made, and the results are a schedule that has been artificially manipulated. In addition, any project schedule that has NO PREDECESSORS or DEPENDENCIES defined, is a huge problem. That basically means that the person responsible for the plan has simply plugged all dates. Not a good idea, in any environment.
We generally allow the use of Generic Resources within a plan, only until such time that a named resource has been identified. Then, their name is put into the schedule in place of the ‘generic’ resource. While it is common for many PM’s to use a text field to list/name an owner, it is still important to know who is working on the task or deliverable.
Having a common look and feel across similar projects, especially within a program is also an area that needs some attention. When the Program Manager or Executive Management is looking at high level project plans, and the overall performance, if they are all laid out and put together with no thought toward commonality of structure, then it is going to be very difficult to assess performance and understand what is happening. Having been through a major migration where each of the different project teams were allowed to put together their plans based upon their preference, department or situation – with no regards to commonality or structure; it ultimately led us to a point whereby we spent 3-4 weeks and thousands of man-hours reworking those schedules into something that could be analyzed and reported on effectively.
Next week, we’ll talk about ’staffing your PMO’ to provide Value Added Service.
{ 1 trackback }
{ 2 comments… read them below or add one }
John,
Having taken responsibility for scheduling large and complex programme’s that utilise MS Project as their preferred planning tool, I feel you have detailed in a concise mannor not only all of the scheduling issues that are faced by a central PMO function, but you have also detailed practical solutions to each.
I really appreciated all of the scheduling points mentioned above, from defining when date change controls should be implemented, how task completion status maybe be standardised, dependancy flow, and especially how progress maybe effectively communicated graphically to wide audiences. These have all proven fundemental through my experience.
The major impacting point that does still, and will always continue to concern me, is whether the required deliverables are understood and described in sufficient detail early enough to enable estimates and dependancies to be of baselinable standard within the schedule.
I really appreciate the nice comment that you have left. Making sure that you setup and perform from a ‘practical standpoint’, is something that more people should take a closer look at.