Reporting to your Sterring Committee

Steering Committee reporting
Steering Committee reporting

Reporting to your steering committee might be the one thing that you should always give your full attention. These are the people who expects you to handle their project and make sure that it is steered safely to target… And if they do not trust you, they might replace you. Therefor you should never try to hide risks, issues, budget problems or milestone changes. Get it out into the open so that they know you need their help.

Your report has three functions that you should always keep in mind;

  1. It should give the steering committee a complete overview of the state of your project.
  2. It should give the steering committee the ability to focus their efforts on project issues that needs their attention.
  3. And it should give the steering committee the ability to make calculated decisions in regards to the projects issues.

When to report?

If possible, you should send a report to the steering committee once a week – You can help yourself and make it a reoccurring event in your calendar.
You might have steering committee meetings once every two week, once every month or similar, all depending on your project, but you should always make sure that the steering committee receives the report at least 24 hours before the next meeting.

Sending the report at least once a week, means that you need to keep it short and effective. No one will read a 10 page report if it is send every week… Besides, you would end up doing nothing but writing reports. Instead, keep your report to a maximum of two pages and whenever possible communicate in KPI’s and bullet points.
Things that you need to include but can’t be kept at two pages should be put in as an appendix – E.g. a timetable, burn down charts, financial reports etc.

What should go in a steering committee report.

So, what should go in a report. Well, there are seven things you need to focus on as a minimum. These are:

  • Executive summary.
    Make sure the report always have a KPI summary at the top of page one, to give an overview of where there might be problems that needs the committee focus. E.g., budget changes, changes to milestones and so forth.
  • Progress.
    Here you should make an indication of resources spent to date, how many resources are needed before you are done and how this adds up to your original estimates. Let the steering committee whether or not you are on track.
  • Budget.
    Present a statues of your current budget situation and your expectations – calculate how much is spent to date and add it to the remaining budget for completing the project. Afterwards compare it to the budget previously approved by the steering committee – Do you lack funds then let them know.
  • Timeline.
    Only put in a description of the changes that has been done to the timeline since your last meeting – And keep the entire timetable as an appendix to the report. If no changes has been done since the last meeting, you should put in the report “no changes done” and leave the timetable out.
  • Resources.
    Does the project have the right resources? Do you need a person with a special set of skills? Do you have enough resources to complete on time? (e.g., you have 3 developers but need 7 to make the deadline). Also, let the steering committee know if you have resources that aren’t useful to your project, so that they can be put to other tasks and doesn’t drain your budget (e.g. you have five digitale designers but only need one of them part time).
  • Risks.
    Here should go the five biggest threats to your project, which you have not handled yet. There might be several more risks to your project, but you should only put in the five most pressing.
  • The project managers concerns
    This is where you as a project manager can rise concerns that you can’t really relate to the focus points above – E.g., the steering committee needs to meet once a week instead of every month or maybe lack of input from the accounting department on expenses is becoming a problem in your reporting etc. In other words , this is where you can tell the committee things that affect your project, but is not a direct risk to it.

Download a report template here >>>

Mind your estimates

Planning poker
Planning poker

Estimating your project is the key to figure out how many resources a project needs in order to complete successfully. But estimates are also the key to measure whether everything goes as planned.

The estimate will give the steering committee or a potential client the ability to judge whether a project is worth implementing or not. In addition, if estimates are given to specific user demands (aka userstories), then the product owner/client/customer can make a judgment of whether a specific demand will give enough value to justify the expenses.

Doing estimates, both rough in the start of a project and detailed estimates later on, will give the ability to prove that the project is doing progress, if your estimates are over or under your budgets, if your deadline and milestones can be meet and so forth. There are various ways of doing this and numerous tools that can help you do it.

How to estimate?
There are two ways that I find especially useful when estimating tasks. One is by using hours and days and the other is by using points and complexity.

If estimates are done in hours or days, then the team members probably will have to breakdown the task and give their estimate on the tasks by telling the SCRUM master or project manager how many hours they would need to complete a subtask. Then adding up all the estimates will give the estimate for the entire userstory and then the estimate for the entire project.

However, breaking down every userstory before being able to give an estimate for an entire project might in some cases be too big a task to make sense (you don’t wanna spent weeks estimating a project that the customer don’t want you to do. In that case you can estimate the userstories by given them points or by rating their complexity. Once that is done, you can breakdown and estimate 2 – 4 userstories in each category, find the average time estimated for a complexity and then sum them all up.

An example.
You have 500 userstories in your project. You go through each userstory and give them points on the following in scale

  • 0 Points (No work needed)
  • 5 points (Being the simplest)
  • 20 points
  • 50 points
  • 100 points
  • Over 100 points

Once that is done, you will need to pick 4 userstories from each scale, break them down and estimate them thoroughly. Afterwards you will need to find the average of the estimates given for each scale and then multiply that amount of hours by the number of userstories in that complexity category. Once that is done, you can add up all the hours from each scale and you will have a descent idea about the resources you will need in order to finish your project.

Always follow up
You should always follow up on your estimates to see if they hold – Usually they do not, so beware of this. When you can see a trend in your estimates, you should try to figure out how much they deviate, and make sure to adjust the estimates for the rest of the backlog.

Once you do recognize that your estimates are off, you should recalculate the entire budget for the project. E.g. If all the tasks you complete has a 30% higher use of hours spent than what they was estimated for, then you should adjust your estimates accordingly by adding 30% to the remaining backlog, and then make sure to report your new budget to your steering committee and/or product owner and customer.

Budget in an agile project.

Budget in agile projects
Budget in agile projects

When doing an agile project, you are doing a project with great many uncertainties. How do one create a budget for a task that has not been specified yet? Whether you say “Agile!” or not, your stakeholders will need some kind of indication on whether their expectations can be meet within budget, or whether they should look at which part of the project that can be excluded – Or maybe the project should be shot down?

Know your budget

First step is to figure out how much money and resources the project owner is ready to spend on the project. Next step is to do an extremely high-level estimation to see if it is possible to meet the budget and the expectation for the product. If you want to do a simple website and are ready to spent 5,000 $ then you are probably going to succeed. If you want to build a complete virtual 3D avatar chat program for the same amount, then you are probably facing a bit of a challenge.

In addition, you need to know what deviation is acceptable for you handle, without consulting you project owner or steering committee. E.g., you as a project manager can approve a deviation of up to +10% of the full budget.

Estimate, and then re-estimate, and then re-estimate…

Next you need to do estimates for the tasks at hand – If you are in the idea phase of the project, then you are probably planning to do a couple of workshops or other activities that will bring you closer to the next phase of your project.

A role of thumb is that the expenses of a it-development project will split as follows on a 6 phased project (Please note – THIS IS ONLY A RULE OF THUMB, IT ALL DEPENDS ON YOUR PROJECT, and I strongly advise you to check passed experiences in the field of Development that you are project managing in).

  • 10 % for the Idea phase.
  • 20 % for the analysis phase.
  • 40 % for the implementation phase.
  • 20 % for the test phase.
  • 10 % for the release phase.

These percentages will also help you to predict if your project is going to meet budget or not. Again if you have 5,000 $ for your project, and you estimate to spent 1,500 $ on your idea phase, then you probably will need some more funding for your project – Or scale down the scope.

For each phase, you should do a complete estimate of all the tasks before you start the phase (and the tasks). Therefore, before you start developing you need to breakdown and estimate all requirements for the new product.

Monitoring your budgets

Once your estimates are in place, and the project is on the way, you need to monitor your estimates versus your actual expenses. If you see that most task has been underestimated and you spent an average of + 20 % on all tasks, then you will need to do adjustments to your estimates and budget asap, and make sure to report this change to your steering committee, so that they can decide how to handle these new numbers.