Project Reporting by Role
Or: Who Does What When It Comes To Project KPI Reporting
So many KPIs, so little time! There are reporting requirements at every step of the project and at all points in the hierarchy. Not sure who on the team should be involved in what kind of progress tracking? Here are some pointers for who should report what. Adapt these to fit your team, but it’s a good starting point.
They should analyse the work they have done themselves, so they’re reporting on progress made and work still to do. And time sheets, if you use them.
There’s an overlap here with skills required, so you’ll need to get them involved with upcoming planning to ensure that they are capable of doing the tasks – otherwise it will take them muhc longer and with much worse outcomes in terms of quality.
Project-level analysis relating to project planning and budgeting. If this is you, you’ll complete the project dashboard and summarise the project performance metrics.
If this is you, you’ll be doing programme level reporting, using inputs from the project managers. As your programme is probably broken down into stages, you can report actual progress (on all the projects) against the forecasted progress for the stage. Do this for time and budget as a minimum.
There may also be other programme level key performance metrics that you choose to track such as resource allocation across the project with a view to managing skill levels.
The kind of thing you’re reporting on is even more rolled up than that of Programme Manager. You’re looking at analysis by the type of work carried out, progress across phases and stages of programme against forecast and juggling the budgets across the portfolio so you’ll want to know top level budget performance to feed into portfolio metrics.
Look at metrics related to time to complete work so you’re also keeping an eye of capability and performance as well as time/cost/quality of the work done.
As a project sponsor, you’ll want to digest the project-level reporting from the project manager. But as a senior exec responsible for diverse portfolios, your data needs are more aligned to the governance and strategic functions you perform.
Look for metrics that analyse time for the different types of work that you have in the business. Splitting activities by runners, repeaters and strangers is a good starting point, and then you can apply the governance metrics to those.
‘Runners, repeaters and strangers’ is a Lean technique to help you know where to concentrate your efforts.
As an exec, look at the time/cost analysis relating to these tasks to see if the business is spending its resources wisely.
So your project is being audited? Lucky you! There’s quite a lot to think about if this is happening to your project, whether the audit is a formal thing or whether you’ve been selected as the project that’s being scrutinised by the PMO this month as part of an informal ongoing review process.
But auditing isn’t that big of a deal if you know what to expect. Every audit process is going to be slightly different but here are some common things that you can prepare for.
Provide The Information
The first step is that you’ll have to provide a whole pile of information to the people doing the audit. Whether that’s your best mate from the PMO or a scary-looking external auditor, they’ll give you a list of the kind of things they want to see. This will include:
The auditor (or audit team) will then take some time to go through all of this. It’s likely to be around two weeks as there’s a lot to digest, and they’ll want to understand it so they might come back to you with follow up questions.
They’re preparing to dig deep into the material and establishing what else they might need to know.
Once the audit team has reviewed your paperwork, they’ll start digging more deeply into the project. At your first meeting (for which there should be an agenda so you can prepare adequately in advance), expect to be taken through a list of points. Consider this the orientation meeting.
It can help if you provide an overview of the project and the objectives as part of the scene setting so be prepared to do that on the spot if asked.
Use the time to really understand what is expected of you and what the process is going forward. For example, what are the reporting expectations during the audit period? If they are asking you for updates, how long will you have to put those together and send them over? In what format?
And if you are expected to make changes to the way you are doing things (which might not be at the request of the auditors but by your manager or the PMO perhaps) then how long will you have for doing that?
Try to establish what the outcome of the audit process will be – they should be able to tell you, and should be able to explain what input you will have to the format and content of the final report. There should be a process by which you can comment on a draft and put your points across before anything is published to senior management.
Find out what your management team or project sponsor intends to use the audit output for, so you can better prepare for any action that is coming your way at the end of the audit.
Following the first meeting you should expect lots of emails! The auditors may want to speak to people in your team or subject matter experts, so make the right people available. If you are submitting follow up or additional documentation you may need to upload this to a secure online repository (if they are external) or provide it over email. There are lots of documents whizzing around in a formal audit situation so try to keep track of what you’ve sent to whom and when.
You might find that after a flurry of activity it all goes quiet for a while. This is the time when the report is being written up. Try to find out when the draft will be coming to you for review so you can block out some time to look at it and add your comments. Be honest in your commentary back but be prepared to challenge anything that you don’t think is accurately representative of your project or the processes being used to manage it.
All that sounds quite daunting but taking part in a project audit shouldn’t be scary – it’s just time consuming and a drain on your team’s resources while you are also trying to get work done. Make sure that your stakeholders and project sponsor know what is going on so that they can give you a bit of grace when it comes to short deadlines and the like during the audit period.
Audits like this won’t take more than about 8 weeks start to end as a maximum, from finalising commercial terms and the engagement letter that kicks off the audit process with an external group to the submission of the final report. However, that time can drag when you are trying to hit project milestones and keep all the plates spinning as well!
Remember that audits are supposed to be highly useful, informative exercises, whether that’s a formal external review or an informal assessment by your PMO peers. The outputs are going to help you manage the project more effectively and get better results for the business, so don’t take the recommendations personally and work together with your team to put the advice into action. Not everyone is lucky enough to go through an audit and what you learn can be invaluable to helping you manage future projects more effectively.
When you’re putting together a new project proposal, there are a number of things to consider. Edoardo Binda Zane has a whole book about proposal writing: Writing Proposals: A Handbook of What Makes Your Project Right for Funding. He says that there are three main elements:
Project proposals of this kind are quite different from in-company project business cases. These relate to projects where you are basically pitching another organisation to give you funding for your project. This happens in research, academia and sometimes other areas like business incubators for start ups.
Let’s say you want to put a funding proposal together for a business incubator. You know you are eligible and you’re gathering the paperwork to prove it. You can put your budget together in the format they want. But the technical proposal…. It’s hard to know exactly what goes in that, even if you know your own solution perfectly and have already costed it. This is about communicating the value and approach of your project so it gets chosen over someone else’s.
It helps if the funding-granting body has given you a template to complete. That certainly takes the guesswork out of it. If that doesn’t happen, you’ll be reliant on your own internal templates and they might not be geared up for this kind of application.
Binda Zane has some pointers for what to include. The headings below are what he suggests goes into your technical proposal along with an explanation of how I would interpret those if it was my project.
Pop something in here to set the scene. Personally I would write the introduction last so I could make it contextually relevant to the rest of the document. If you don’t normally leave it to the end to write the intro, try it next time – it’s so much easier!
Current context and proposal structure
This should cover the context of the project and any background information that’s useful for the decision makers to have. It could also describe the research you’ve done (not in detail) or other sources from which you’ve drawn information to prepare this proposal.
It’s also a kind of executive summary that outlines what they can expect to read in the proposal and gives them the headlines in an easy to digest format.
You’d cover off the project goals and objectives. This would be just like a standard business case.
Binda Zane suggests that you talk about the tools and techniques to be used. This can give the decision makers confidence that you do have some clue about how to manage a project. If you can say that you’re using industry standard best practices and following guidance from PMI (or whatever methodology/standard/processes are applicable to your business) then do.
I’d make sure that governance gets a significant mention here. If you were asking for my money I’d want to know that you had controls in place to spend it sensibly.
Of course, you shouldn’t say that you can follow standards if you actually can’t. That would be a breach of the PMI Code of Ethics and Professional Conduct. Other professional bodies have similar ethics standards.
You’d also want to include a section that outlines your detailed approach, the work packages and the descriptions of each task, at least to a sensible level that tells them what you are all about. If you think this section might go on a bit, move some of the task descriptions or detail to the end and put it in an appendix.
Organisation and Staffing
This section covers what they need to know about the people who will be involved with the project and how the work would be organised.
Binda Zane suggests management of quality control is covered in this section but I think there’s some flexibility to move it elsewhere if that makes better sense to you. I think I’d include this in my methodology section but there could be good reason for keeping it here.
Up until now you’ve only talked about what you will do, and how you will do it, but there hasn’t been any talk of how long that will take. Mention the timescales, major phasing and anything else relevant: key milestones, reporting dates and so on.
You also want to talk about the project team in this section. Describe the make up of the team, the organisation structure for the project and the roles and responsibilities of the key players.
Binda Zane recommends two appendices. You can dump information in here that would take up too much space in the main proposal but is still useful for the audience to have. His suggestion is that you include the CVs/resumés of the project team and also a selection of project references. By that I would surmise that you could include references from past clients about similar projects, awards your team has won for their project work and anything else that makes you look like a solid and stable organisation.
That should give you a solid project proposal – for the technical element, at least. What else would you include in a technical proposal? I’m interested to hear your thoughts about what might be missed out of the list here!
How do you track the performance of your project? Here are 5 ways that you can do it.
1. Fixed Formula
This is pretty easy. Assign a fixed percentage when the work starts. Then make it up to 100% by allocating the rest when the task finishes.
The Pareto principle is a good one to use if you don’t know how to split your task percentages. Assign 20% complete to the job when it starts, and the remaining 80% when your team member reports the work complete (because at that point it’s 100% complete).
It’s simple to work out but it’s not terribly accurate. It’s only good for small pieces of work and short tasks where it would be too difficult or not worth it to work out percent complete across a couple of days. It can also be used where the task is no longer than a week long. If you are updating your project plan once a week, and the task is no longer than a week long, the task is either started or finished so the 20/80 split (or 50/50 or whatever you think is appropriate) works out pretty well.
2. Weighted Milestones
When you’ve got plenty of milestones along the way, you can work out project performance by tracking how many you’ve hit.
In other words, you can pre-assign progress (percent complete) to certain milestones or parts of tasks. When you hit Milestone 1 you can say the project is 15% complete, at Milestone 2 it goes up to 20%, at Milestone 3 you’re 65% complete and so on. Until your final milestone at project completion where your project (or task) gets updated to be 100% complete.
This is also a way to split payments to vendors – many contracts have a schedule of payments linked to the achievement of key milestones. Your budget could be weighted in the same way as how you track performance.
3. Percentage Complete
We’ve talked about % complete already, but this version of it is just based on the project manager’s
This isn’t hugely accurate either – although it depends on the project manager. It takes experience to be able to pick a percentage out of the air and have it reflect reality. Generally, project management tools can help with this by playing back to you the % complete of your project schedule, so at least in that case you should have something underpinning the number you give.
4. Percentage Complete with Gates
This is similar to weighted milestones but instead of waiting to hit the ‘gate’ point, you can report any percentage complete up to the approved limit for that milestone.
For example, when you hit Milestone 1 you can say the project is 15% complete, as we saw above. With weighted milestones, until that point the project would be 0% complete. With gates, you can set a % complete every day if you like, working up to 15% at the point of hitting the gate (the target milestone date or achievement).
It’s like a blend of using your professional judgement but being constrained to not say you are too far ahead because you can only ever hit a certain percent complete through the nature of where you are on the project.
It sounds complicated to explain but this is my favourite approach for measuring project performance.
5. Level of Effort
Finally, you can track effort against the elapsed time. Alternatively, you can track against some other task or work package on the plan. For example, ‘Complete Testing Documentation’ might be linked to ‘Complete Testing’ and the two activities progress in parallel.
You’d track performance for ‘Complete Testing’ and then, as you know that testing documents are being updated as you go, apply the same % complete to ‘Complete Testing Documentation.’
Which one(s) of these do you use? And which do you avoid? Do you use these as standalone techniques or do they link to your Earned Value Management activities? Let us know in the comments below!
The Arras People Project Management Benchmark Report contains a useful snapshot summary of responses by job title this year. It means we can take a look at what an ‘average’ project manager looks like, if there is such a thing. Bear in mind that the survey is mainly targeted at UK project managers although there were a fair few responses from those working outside the UK.
Let’s meet our average PM.
Does any of this sound like you? Nearly 45% of the respondents to the Arras survey identified as project managers so this is data from a very representative sample.
Let’s have a look at some of the outlier responses and create a different sort of project manager.
This really doesn’t sound likely as a profile, does it? It’s a collection of the least common responses from people in the survey, but it doesn’t hang well together as a pen portrait of an atypical project manager. I could extrapolate from this that the ‘average’ project manager I constructed above from the most common responses to the survey is also not a particularly accurate profile.
Statistics are useful – in this case they help set salaries and responsibilities for people in professional project management positions. But they need to be considered in context.
Get a copy of the survey and see the details for yourself here.