The Project Manager and team leaders need to be able to control the work of the team members. They will need access to detailed information on such things as:
The senior leadership team, people such as the Steering Committee, Project Director, Project Sponsors etc, need to understand how the project is progressing. They need:
To address these needs, the project must establish effective methods for:
A key issue always is - how much control and reporting do we need?
The Project Manager can be in a "no-win" scenario. A Project Manager is expected to be completely in touch with all aspects of progress, performance, expectations, issues, etc. At the same time, the senior leadership will not wish to see the Project Manager or team members seemingly wasting time doing administrative tasks. Equally, the team members will often consider that such administrative tasks distract them from their work.
To make a success of the project control process, the Project Manager needs to achieve two objectives:
The complexity of the project is often a major factor in this decision. A small team based in a single location can sometimes be managed with no specific process or procedures simply by the Project Manager taking a continuous interest in what the participants are doing and what they have achieved. Unless there is a requirement for audit information, for example where a third party is billing for time or deliverables, the project could be managed without documenting the individual participants' work and progress.
Best practice, however, is normally to require some form of documentation and submission from the individuals. It will encourage them to think about what they are supposed to be achieving, and whether they are expected to be doing better. It also provides the basic information required to monitor progress, to demonstrate to the senior leadership or any interested third parties that the job is being properly managed, and to justify any financial costs, payments or joint venture reporting.
In terms of reporting, again it makes sense to provide some level of formalised feedback to the senior leadership and other interested parties. The level of detail should match the needs to provide optimum benefit.
"Do I have to submit a timesheet?" This is one of the most common questions from the participants - particularly those not from an IT background. It seems strange that so many people find it such an imposition to spend a few minutes thinking about what they have achieved.
Getting input from the core team should not present a major problem provided that they understand its value and that project control procedures check the information has been gathered in a timely fashion. More of a challenge can be to promote a similar discipline with part-time participants and those outside the direct control of the Project Manager. Again, the trick is to ensure these people understand the importance and value of the information; but, would you tell the Sales Director to submit a timesheet because he spent some time attending workshops and reviewing documentation? You may well find that with certain resources it is more practical to get the Project Office staff to find out what input has been made and to make the entries without requesting the participant to access the system and complete the timesheet submission forms.
One thing is for certain - either people complete timesheets or they do not. There is no point in having partial information with gaps in the data. The Project Manager and/or Project Office staff should make sure the agreed policy and procedures are maintained.
As part of the Project Definition, there should be agreement on the needs for control and reporting along with the overall approach to be adopted. Careful consideration should be given to the appropriate balance between the various influencing factors, eg cost, effort, time, risk, benefit. If possible, a sample reporting pack and control procedures should be presented and agreed with the project's Steering Committee, sponsors and other interested parties.
Before the team is assembled, the approach will need to be developed into well-defined procedures and set up on the project support system if appropriate. This might involve a considerable amount of preparation if specific project web sites and systems tools need to be installed, configured and the data loaded.
The key to success with the project control process is for all participants to understand precisely what is required of them and why it is important and valuable to comply. Needless to say, the control mechanism needs to be ready from the start of the work. If you de-prioritise it while you have more urgent matters to attend to at the start of the project, you will find it becomes increasingly difficult to catch up with the data and to persuade the participants to co-operate.
As the team assembles for each phase, it is useful to hold a team briefing or training session. This would explain the overall project - its rationale, its approach, the timeline, procedures, team structures, responsibilities, techniques, review processes etc. One element of this would be the control and reporting process. For those participants not assembling at the start of the phase, similar information should be documented for self-study and reference.
The project control and reporting process should run throughout the project. The main routine aspects are:
Timesheets are the normal way of collecting source data about progress from the individual participants. In most projects nowadays, you will be able to use automated tools for the collection and analysis of such data. Various tools exist which can take the detailed project plan and tracking data to create electronic forms through an Intranet web page or client/server systems. This removes much of the pain from the physical process. It also means that standing data, previous totals and expected work items can be pre-completed on the form.
The information you need to collect will depend partly on your approach to planning the project, and partly on the investment you have decided to make in the collection and analysis of progress information. Here is a classic timesheet which could be implemented as a paper-based system, through the EMailing of spreadsheet forms or in a fully automated Project Tracking tool.
Let's run through the data we are trying to capture:
Purpose / commentary
|Name / Team||Who is supplying the data / for which part of the project|
|Date||Period the data cover. Consider whether weekly is the optimum period for reporting. Very rapid eProjects might benefit from real-time reporting on a daily basis. Long projects with relatively few tasks might not benefit from the administrative burden of such frequent reporting.|
|Reference & description||Which work item is being reported on. This would normally match the detail in the project plan. If the plan was expressed as phases, activities and tasks, so too will the timesheet item. If it was expressed as deliverables, these will show the work against those deliverables.|
|Hours per day||How much time on the specified item was spent on a particular day. Consider whether you need this information broken down by day - what are you trying to achieve? If this is the main way to control the working hours of individuals it might be valuable. If you only need to know the overall time expended on the work item it might be a waste of effort.|
|Weekly total||Here it is expressed in hours in one column then converted into days. Hours tends to be the most convenient way of measuring effort per day (try to avoid minutes). Over a longer period people prefer to think in terms of days (or even years) of effort. One common debate with this logic is whether 12 hours worked on one day counts as a day or a day and a half!|
|Brought forward||Previous effort expended on this work item. This information would normally be automated unless a fully manual system were being used. It is useful to make it visible on the form so that the team member fully understands how well they are performing against the planned effort.|
|Effort to date||Adding together this period with the previous brought forward figure gives us the total effort for this work item|
|Estimated work remaining||The estimate of how much more effort is required to complete the work item. Here we are seeking added value from the participants by getting their prediction on the remaining effort. (Beware of team members who think this number should always be the "politically correct" number rather than a genuine estimate. Be suspicious if this number added to the effort to date comes exactly to the budgeted figure - unless it is early in the task and the team member has no better guideline. Equally, be suspicious of estimates to complete that remain static with a small percentage remaining.)|
|Estimated total work||Adding the effort expended to the estimate to complete, we have a revised estimate for the overall effort from this participant for this work item.|
|Budget||We can state the budget from the baseline plan. This is useful both to calculate the variance and as a visual reminder of the participant's target.|
|Variance||Showing the extent to which the estimated total work is less or more than the planned amount.|
|Status||It is not always obvious from the data whether a work item is completed. This entry allows the participant to indicate that they consider the work to be complete.|
|Estimated completion date||This entry collects the participant's view on when the work item will be completed. Effort figures do not give us an accurate view on the elapsed time. To do so would require very detailed control and analysis of the participants' availability, priorities and the way they divide their time between work items.|
|Planned completion date||This makes visible the planned date from the baseline plan.|
|Variance||Comparing the estimated completion date with the originally planned date allows us to identify the degree of variance. Variances are particularly important in the routine control of the project as they may well affect other work items through their various inter-dependencies. A slippage might hold up other work. Finishing early might mean resources could be rescheduled or re-deployed.|
|Deliverables reference and title||This timesheet allows us to collect information about key deliverables as well as information about the effort and timing of work items. If the work items had been expressed to focus on the deliverables, this information would be redundant and there would be no purpose in including these fields.|
|Status||Indicates whether the deliverable is delivered. You might use this for more specific status such as draft, frozen, final, signed-off, published etc.|
|Estimated completion date||The participant's view on the expected completion date for the deliverable|
|Planned completion date||The originally scheduled date for the deliverable|
|Variance||The variance. As with work items, the variance in delivery dates is a particularly important issue to review and manage.|
|Issues||This timesheet also collects information about issues. The logic is that if each participant is viewing the timesheet on a regular basis, adding input fields such as this encourages them to consider whether they have information or thoughts to contribute. They may well have not bothered to do so through the regular issues management system. Other key information might be requested and collected in this way. Timesheet forms or screens can also be used to output messages to the participants - it is an excellent example of push technology as the target audience all view the timesheet and have to respond to it.|
In all but the smallest projects, you will need to set up reliable, regular methods to collect information from the various participants. Often it is the job of the Project Office to manage this process and to make sure that all required submissions have been received and processed.
The process will normally involve electronic methods of communication such as:
Various tools to support projects are commercially available, but will not be reviewed in the ePMbook as it is a constantly changing marketplace. The level of investment in supporting tools should match the size of the requirement and reflect the potential benefit. Complex projects inevitably need good infrastructure to support reporting and control needs. This is particularly the case where participants do not work together in a single team and single location.
It is important to consider who needs to submit information for the effective management of the project. Important participants often lie outside the direct control of the Project Manager, yet their input could be highly valuable. Probably the single biggest issue with such people is - "do I have to submit a timesheet?"
Whether or not you will be using automated project support tools, there should be a well-defined process and formats in which the information is captured. Where possible, the forms should be in the form of turnaround documents where standing data and previous information are visible to the participant and do not to be re-entered, for example, name, assigned work items, previous totals to date etc. The support and tracking tools should be able to create such formats automatically.
There will be a vast amount of data available about the progress of the project. The challenge is to turn this into useful information.
Different participants will have differing needs for information. The Steering Committee is unlikely to want to see detailed data unless it relates to a specific area for concern. They will prefer to see overviews, "bottom-line" projections and key milestone dates. Conversely, the team leaders and Project Manager will probably need to review the status information in great detail to look for any specific issues that require attention.
Here are some of the types of information that may help the leadership team understand the status of the project:
|Most project planning and tracking tools will be able to prepare a variety of progress reports automatically - provided you have fed in all the data they need to plot progress. You will normally need to prepare various summary reports for reporting to the senior leadership.|
|You may find you need to construct some of these manually to provide the key facts in a simple manner. For example, you might present some of the aspects with a simple "traffic light" graphic - ie a traffic light set to green for OK, amber for danger, and red for a "show-stopping" problem.|
|Other graphics might be in the form of dials or simple graphs. Where the Project Definition has established balanced benefit model targets which is being tracked and managed, the current projected benefit against the various measurable targets may presented.|
Various simple devices such as this can present the key facts to the project's sponsor and executive leadership. You might present them in the form of an overall project control "dashboard".
One of the easiest ways to show progress graphically is to use a summary Gantt chart . Most project management tools will have reporting formats to do this. In this example, we can see whether tasks are started or finished by the colour coding, and we can see their percentage complete by the progress bars within the main bars.
This format can provide a good summary of progress. When more detailed information is presented in this way, it can become difficult to relate the many indicators of progress in different areas of the plan or programme. Other reporting techniques may help to present progress and key issues.
One popular way of displaying progress is by reporting the degree to which planned milestones or deliverables have been achieved. The are many ways in which you might use this for a management report.
In this example we are tracking the project's achievements against the planned milestones simply as a numeric count.
We can get an impression from this chart that the project is a little behind schedule. It is not easy to see exactly how far behind, how much effort is required to catch up, or what the implications are - but clearly there is a need for management attention.
You might also analyse the dates for each milestone to present a table of variances and projections for key milestones, plus an overall average variance.
Similar reports could be produced for the delivery of deliverables, completion of tasks, accomplishment of outcomes etc.
There are many ways of presenting project progress information. In itself, it gives a picture of the current status. Equally important will be the implications and recommendations. In this simplified picture we are running behind schedule. Ask yourself what you would assume will happen over the remainder of the project - would you expect to end up at point A, B or C?
If the Project Manager is not managing the situation, the planning projection will probably be point B. From the current stage of progress, future work will retain the same estimates as before, and, therefore, be projected at the same rate of progress as in the original plan.
If the Project Manager has reacted to the lateness of the project, work may have been re-scheduled to make up for lost time with the intention of meeting the original target - point A. But, was that a realistic expectation or just dumb way of avoiding trouble in the short term?
The cynical observer, however, would probably note that performance has been consistently slower than planned; either the team performs badly or the estimates were wrong. There is every reason to believe this unsatisfactory rate of progress would continue unless specific action were taken - hence, the realistic projection might be point C.
The point here is that you, the Project Manager, need to consider carefully what the detailed project progress information is telling you. You will need to look at the consequences of the current status, for example, the impact on dependencies, resourcing and dates. You then need to consider what forms of management action (if any) are appropriate. When you report progress to the project's senior leadership you would also present your projections and key concerns along with whatever options and recommendations you consider appropriate.
|We were regularly reviewing a large-scale
European public sector project that seemed to be running
slowly. The progress reports continued to show delivery
on time and on budget.
The Project Manager became increasingly reluctant to let us see the project tracking data. One night we waited for him to leave so we could take a detailed look at his data. He had not been able to increase the budget, nor the resourcing. He had not been allowed to slip the timescale nor reduce the scope. He had adjusted the plan in the only other way remaining - by the time we looked at it the team members were scheduled to work 16 hours a day, 7 days a week for the next 12 months.
Continuous effective communication is essential in all projects. The Project Manager should consider this a routine part of the job. In terms of communication with the project's leadership there will be a formalised mechanism in addition to the many informal channels that the Project Manager can exploit.
In the project's organisation structure, we identified several typical roles including:
In each of these cases, regular communications and meetings should have been agreed during the Project Definition.
The two most common forms of communication are regular reports and review meetings. The most formalised meetings tend to be with the project's Steering Committee, which is charged with the oversight of the project. In most cases, the Project Director and Project Sponsors will attend or be represented at the Steering Committee - so they too will participate in these formal review meetings.
The reporting pack and meeting agenda can have the same structure. What you are trying to convey is:
Make sure you convey this at the appropriate level of detail - too much means your communication will not be heeded, too little means they will not have an adequate understanding of the issues. It is your job as Project Manager to understand and consider the full detail of the project. The Steering Committee will rely on your ability to present the key information to them.
Here are some of the things you need to communicate in the reports and discuss in the meetings...
|Activity in the preceding period||Summary of key work items started, in progress and completed:|
to date against the plan:
|Recommended actions||Recommendations as
All formal meetings should follow best-practice, for example:
Meetings should be scheduled to provide the best balance between the costs of senior staff time and the need to drive the project efficiently with a view to optimum business benefit. Timing and frequency will depend on the type of project, how rapidly it progresses, what stage it is at, how much oversight and sponsorship it requires, etc. It is common to find a Steering Committee meeting once a month. That might be a good average, but there will be times when more interaction is required, and periods when there is relatively little to be discussed. Meetings could be scheduled to reflect the varying needs of the project and to tie in with its projected timing. With the rapid iterative approach of many eProjects, the leadership will need to be involved frequently and be ready to make rapid decisions.
There will normally be a need to report the final position to the senior leadership and other interested parties. As well as the routine reports, various overall summaries and final reports may add value. It might also be appropriate to prepare more general information for wider distribution, for example, as part of the communications and change programme. Remember to tell everyone that you have finished!
Progress information from completed work is a valuable source for estimating future projects of a similar nature. Make sure the final figures have been collated and made available for future reference.