Tag: project stakeholders

How To Write Better Project Status Reports

As a first-time Project Manager good communication is an essential skill that you need to learn quickly. All Project Managers need to be good communicators and to update their stakeholders with a regular status update in the form of a weekly project report.

Project Managers do not enjoy doing them, and they are often done quite badly, but they are an essential method of communication on projects and, if done properly, they can help the project run more smoothly.

What’s the problem with project reports?

There are a number of problems with project reports, I think.

From the Project Manager’s view point – they hate doing weekly project reports for these reasons:

  • They are time consuming to write
  • They find them difficult to write as they are trying to find something different or new to say about their project each week
  • The mere fact that they hate doing them makes them more of a chore
  • Finally – they also have a nagging suspicion that no-one actually reads them – so why put all that effort in?

From the audience viewpoint i.e. the people reading the report, I see a number of problems with weekly reports that I read every week as part of my role as a Programme Manager:

  • Report is too wordy, waffles too much, is too long and complicated to read
  • Report has too much technical jargon which is hard to penetrate or understand
  • It is hard to get to the really valuable information
  • Highlights information that is irrelevant to the audience
  • Doesn’t highlight important information or underplays its significance

So how do we improve weekly reports?

What’s the purpose of the project report?

Let’s start by looking at why we are doing the weekly project report. What purpose does it serve and what are we trying to achieve?

Communicating regularly to your project stakeholders and also keeping your project delivery team in the loop in terms of what is going on in the wider project, and what is being communicated to stakeholders is a good thing.

The weekly report is the opportunity to keep a wide group of people involved in the project up to date with what is going on in the project.

The audience for weekly report falls, broadly speaking, into three categories

  1. The business stakeholders – including management, customers and users
  2. The project governance team such as Project Management Office (PMO) or managers of the Project Manager – they are concerned with ensuring that the project is under control
  3. The Project delivery team – the team(s) working on the project day to day including suppliers. They will know quite a lot about the project progress but may not be across all the different areas of the project

I have also known Project Managers to send their weekly report to their project delivery team first for review before it is sent out to wider list of stakeholders – this is a great idea, I think.

What qualifies as good communication?

When writing the weekly project report, it is essential that you focus on what the audience want to get updated on. The content is covered in a later section but here are some guidelines:

  • Keep the information clear and to the point
  • Ensure the information is up to date and correct
  • Keep jargon to a minimum
  • Keep it brief, but not so brief that it is hard to understand – use sentences and good grammar
  • Ensure the information is relevant to the audience
  • Ensure important information is highlighted
  • Avoid repetition

How often should we do a project report?

Ideally you should be writing a project report every week. The more often the Project Manager writes it, the easier it should be to update. It is a lot to easier to remember what you did in the last week, whereas sometimes 2 weeks in a project seems like a long time to remember exactly what has been achieved. However, this is dependent on the project itself and also where you are in the project lifecycle.

Not every project is going flat out for the whole time. In some phases of the project there might not actually be much going on for a few weeks, so there might not be much to report. In this situation I would negotiate with your key stakeholders and request that you push the project report frequency out to every 2 weeks. You can always go back to weekly again when the project pace picks back up again.

In some organisations they do project reports once a month. I would question the value of that. The overhead for the Project Manager is high as this would take quite a long time to go back through the months’ worth of work to write the report. It would also be likely quite out of date.

My preference is for weekly project reporting to ensure the regular flow of information to the project stakeholders and also so that we can act quickly on any concerns, risks or issues.

How long should it take to write a project report?

I would argue that a Project Manager should be able to write a project update in 15-30 minutes. If it is taking longer than that they are spending too much time on this. There are occasions when you might need a bit longer to do an update and it will depend on the size of the project and on how busy and fast paced the project is, but I would still aim for the 15-30 minutes.

Report format and delivery method

My preference for weekly reports is a text document in MS Word, GoogleDocs or similar. This should be maximum 1-2 pages.

Sometimes a presentation type format such as MS PowerPoint or GoogleSlides is used – this is quite common particularly in projects which are part of a larger programme. The same content should be included as per next section.

Sometimes a simple email will suffice as long as it summarises the information as outlined in the next section.

My preference for distribution of the weekly report is via email – either with the file itself or a link to where the file can be found.

Don’t forget to date the files and email subject headings so that reports can be easily searched at a later date.

What should be communicated in the project report?

I have outlined a typical format for the project report below. The format may vary between organisations, but the content should be similar to that outlined below.

Weekly Report 
Project <Name>                      <Date>
What’s been achieved this week:
<approx. 3-5 bullet points>
 
What’s planned for next week:
<approx. 3-5 bullet points>
   
Main Issues:
Issue 1 – brief summary and action plan
Etc.
Key Milestones
Milestone 1, status (red, amber, green, done), and forecast date
Etc.  

Key Risks:
Risk 1 – brief summary and action plan Etc.    


When to distribute the weekly report

Reports are often issued by Project Managers at the end of the week, but this can also be dictated by what project meetings are scheduled for the week. So, the Project Report contents can be discussed in these meetings. So generally speaking, late Thursday, Friday or early Monday are the most common days I would say.

What not to communicate in a weekly project report

Clearly the weekly project report is used to communicate information about the project to a wide audience and highlight challenges, risks and issues. However, I would not use the project report to highlight new information to the audience as the first point of communication.

If you need to highlight project challenges, issues, risks, budget changes or changes to timelines I would use your regular project meetings, monthly Project Boards or one to one meetings with stakeholders to communicate this information before you put it on the weekly report.

People don’t tend to like surprises or feeling like they are the last to know about issues and challenges on the project. I have seen many mini stakeholder rebellions and extra project management calming work created because of one small sentence in a project report. The Project Manager’s role is to keep everything under control and running smoothly not create extra communications challenges – whether well intentioned or not.

Happy report writing

So you should have a set of useful tools and pointers which you can now use to produce your weekly reports more efficiently and effectively. Good luck.

Chris Wilson

How To Start Your Project Faster

Getting your project started correctly is the foundation to the future success of the project. If you don’t start the project off properly you will find it challenging to get it back on track later on.

Avoid the temptation to just get going with the project

There is a temptation to just get going on the project without some of the key project fundamentals in place. Avoid this approach at all costs – you will pay for it later.

You may initially come flying out of the blocks, everything will go great for the first few weeks, even a few months, and then gradually you will get into a quagmire and everything will slow down to a crawl. At the start everyone was really excited to be working on something new – but things aren’t going quite so well now.  People are uncertain about what the project is about, where it is heading and who is doing what.

Get the project fundamentals in place

This is actually quite common with projects and even happens with some experienced Project Managers. Most often I have seen this happen when the project has not been setup properly from the start. Specifically – I mean that some of the project fundamentals are not in place. These are typically some, or all, of the following:

  • Unclear business owner (sponsor) for the project
  • Unclear reasons for doing the project
  • Unclear project objectives ie what the project is aiming to deliver
  • Unclear definition of what success looks like for the project
  • Unclear roles and responsibilities on the project ie who is responsible for what
  • Unclear understanding of who the project is for, how they are impacted and what influence they have in the decision making processes in the project

These are the fundamental aspects that need to be understood before you can even start to get deeper into the project planning to understand what the detailed requirements are, what will be delivered and then start to estimate timescales and costs on the project.

Document the key project elements in the Project Plan

Another key point to make is that this must be written down. It is remarkable the number of times that I have seen troubled projects in mid flight without these fundamentals in place, with only some vague or very out of date agreements in place. If it isn’t written down people then either forget some of the specifics about what the project is about, or purposefully change what the project is about along the way.

Changing the scope, direction and deliverables on a project is fine as long as everyone involved understands what the impact of the changes are and agrees to the changed approach. Often these changes are subtle and can appear to be small in nature but when added up they can have a major impact. If nothing is written down there is no reference point for making these decisions.

If you build the project on shaky foundations you are not setting the project up for success and as a minimum the project will not proceed as fast and smoothly as you want and at the other end of the scale can lead to disagreement and plenty of stress for everyone.

So how do we set up the project for success?

Create a comprehensive Project Plan

A Project Plan is more than just a timeline – lets clarify our terminology here – I will call the plan the “Project Plan” document. I have worked in many organisations and the name of this document can vary from place to place. It is also often called a “Project Initiation Document” or PID (a PRINCE methodology term) or sometimes it can be called a “Terms of reference” (ToR), if it is to be used as an external customer facing document it may be called a “Proposal” or even a “Statement of Work” (SoW). However essentially all of these documents have similar content. The purpose of the Project Plan is to outline the key elements of the project.

Project Plan sections

The Project Plan is the written down specification, or shared view of the project and it is used as the reference document on the project so that everyone involved agrees what the project is about and what it will deliver. It can be quite a lengthy document and should have the following sections:

  • Project Overview
  • Vision
  • Business case and benefits
  • Objectives
  • Sponsor and key stakeholders
  • Requirements summary
  • Deliverables and outcomes
  • Main activities
  • Organisation and delivery team
  • Project delivery approach
  • Timelines and schedules
  • Governance
  • Finances
  • Key Risks

Creating the Project Plan is time consuming but worth the effort

Creating (writing down) the Project Plan can be a time consuming and laborious task – this is one of the reasons why it is often done so poorly. It should be written before the project starts but is often written at the very start of the project.

The work, of course, is not just in documenting the plan but in gathering all the information together from everyone involved, then writing it down and then walking it through with everyone again to make sure what you have written down is in fact what they said. Then you have the process of negotiation between all the different stakeholders. Eventually, all being well you get agreement and get the Project Plan signed-off and you can officially start the project.

The process of documenting the plan helps clarify the project itself

There is often huge pressure to “get going with the project” rather than “messing around” writing things down at the start. However the mere process of writing the Project Plan down and getting the agreements in place enables everyone to get great clarity on the project. So it is all about the process of creating the Project Plan and the by-product is the document itself. This pays huge dividends later on in the project. If you don’t do it at the start, then you will end up doing it later on under even more stressful conditions when the project is going off track.

I liken not doing a Project Plan at the start to taking off in a plane with no clear idea on where you are going, how you are going to get there and if you have a enough fuel in the tanks – it might work out but there is a good chance that it won’t.

5 key questions to start your Project Plan

Before you can into the actual planning of the project in terms of deliverables, approach, timescales and cost you need to know 5 key things about the project:

  • Who wants the project?
  • What is the project about?
  • Why are we doing the project?
  • Who is impacted by the project?
  • What does success look like for the project

In order to answer these questions you need to identify the Project Sponsor and Key Stakeholders. They will then help you understand the project Business case and benefits and project Objectives.

These are the first few sections of the Project Plan and it makes good sense to “start at the start”. If you don’t have the first few sections confirmed you are going to have a lot of trouble getting the later sections of the Project Plan agreed and written down.

Understanding the Project Sponsor role

The Project Sponsor is the person who wants the project and is typically the person paying for, or funding, the project. It is preferable to have one sponsor as you have only one person to deal with. Projects with multiple sponsors require more project management time as there is the potential to have conflicting requirements and the potential for people to pull the project in different directions.

The Sponsor may also be one of the main stakeholders in the project (see next section) and they can be seen as the main customer and the key decision maker in the project. It is really important to be clear on who the Sponsor (not always as straightforward as it should be) is and the role they will play on the project. They will set the direction for the project and will help you outline the key objectives, requirements and deliverables for the project. They may have a senior role and therefore be busy and sometimes delegate their responsibilities to someone else in the project. Whatever the position this is a key role for the success of the project.

Identifying the Stakeholders

A Project Stakeholder is anyone impacted by the project. In any project there are likely to be multiple stakeholders. The project manager needs to

  • Identify all the stakeholders or groups of stakeholders
  • Identify which are the key stakeholders (normally the ones most impacted by the project)

The key stakeholders will help you define the project requirements and will help you define how the project will need to be approached. They will also provide you with some of the constraints that the project has to work within.

The Project Manager will work closely with the Key Stakeholders or the people that represent the main stakeholder groups.

Understanding the Business Case and benefits

The Sponsor should be able to articulate the business drivers, benefits and case for doing the project. Often there will be a detailed Business Case that is agreed before the project has authorisation to start (this is often dependent on the organisation or type of project).

The business case should be summarised in the Project Plan. This can then be used as a reference point throughout the project to ensure that what is being delivered matches with what the sponsor requires. If there is a request for change in requirements, deliverables etc. then this should be referenced against the Business Case and clarified with the Sponsor.

There could be many different business drivers for a project. Some of the typical ones are as follows:

  • Improve efficiencies and reduce operational running costs
  • Deliver a new product or service
  • Meet a set of legal requirements, standards or regulations

Where possible the business case should state the specific values such as time, cost saved, revenue expected etc.

Project objectives and defining success

I have found that writing down a really clear set of measurable objectives for a project can be really beneficial. It is then really clear to everyone what success will look like when the project is completed. If done well they should be cross-reference throughout the project to ensure what is being delivered is compliant with the objectives.

The objectives need to be agreed with Sponsor and validated with the Key Stakeholders. They should be stated unambiguously ie there is no room for different interpretations of the objective and typically you should aim for a minimum of 5-7 depending on the size of the project. They are closely linked to the Business case and benefits can be used as a reference framework for creating detailed requirements and definition of scope for deliverables and outcomes.

Next steps – planning the project delivery

With these project planning fundamentals in place then hopefully you can see that you have everything in place to start the main planning activity on your project. As stated if you aren’t clear on who wants the project (Sponsor) and who is impacted by the project (Stakeholders) then it is very difficult to have any meaningful discussions about project requirements and from there drive out what the project deliverables and outcomes will be. From there you can build out the rest of the Project Plan and start to plan timelines and costs.

Good luck with your Project Plan!

Chris Wilson