Imagine this: you’ve just been asked to write a project report.
How do you write it?
All project reports should include similar elements.
- Executive Summary
- Requirements & Resources
Let’s dig into the details:
- 5-Step Guide to Writing Project Reports Part 1
- Launching Your Project Part 2
- Monitoring Project Progress Part 3
- Post Project Evaluation Part 4
How to Write a Project Report? 5-Step Guide
Creating an Executive Summary
Every project plan should start with an executive summary:
Exactly what needs to be done, and why?
Explain the problem the project attempts to solve or mitigate. Most importantly, ask:
How does this project benefit the business?
Write the answers to these questions with your audience in mind. If the project report will be sent for executive approval, you may want to focus more attention to business impact and list the project’s specific metrics-driven objectives.
Executive summaries aren’t intended to be long. A few sentences or a brief paragraph is all you need, as your supporting details will be found within the body of your project plan.
Identifying Requirements and Resources
Next, it’s time to determine what will be needed for the project to be considered “complete”. This involves both identifying measures of success and actual resources. So if we jump back to our website example, requirements could include something like an initial wireframe showing where the pages will live on the site, 1,000 words of copy from the content team, and product information imported from the business development team.
When thinking of what’s required for success, your metric might be something like: “pages are live on the corporate site with 95% of bugs identified by the start of Q3“.
When requirements are specific, rather than general, it helps ensure contributors and stakeholders stay on the same page.
It’s important to be honest about the risks associated with a project. Recognizing potential pitfalls from the outset puts you in a better position to minimize the chance they’ll occur, or develop an effective back-up plan. Any executive or customer that will be reviewing and approving the project report will also expect that risk factors are identified, so skipping this section just isn’t worth it – they’ll ask anyways.
Plus, should you choose to overlook a risk factor that does come to pass, it will be on you for not addressing it from the beginning. Project risks are varied and numerous, but they usually include things like:
A. Limited resources (lack of manpower or technologies)
B. Going over budget
C. Approval delays
D. Customer dissatisfaction (project doesn’t meet all requirements)
Keep in mind that almost all projects have inherent risks; just because a project report identifies potential risk factors doesn’t mean it’s dead on arrival. As you detail out these risks in your project report, state potential solutions or ways to mitigate them where applicable. Some risks, like going over budget if you realize you need to contract out part of the work, may be unavoidable. But at least by stating these risks in your initial project plan, all are aware from the start that they’re a possibility.
So you know your end goal, what it will take to reach it, and what potential risk factors are involved: it’s time to hit the ground running, right? Shorter projects may manage just fine with these three core components, but for many projects, especially those that require the input of multiple people and extend over the course of a few weeks or months, establishing activity milestones throughout is essential.
Your milestones should be the important activities that push the proverbial ball down the field.
For example, one of your first milestones could be drafting the wireframe of the pages you’ll add to your website. Your next could be receiving page copy from your content team, and so on and so forth.
Notice that the milestones don’t need to capture the micro-events in between, such as a content writer completing their first rough draft. While at times these steps may be necessary to detail, in most cases they don’t need to appear within your project report.
Milestones are most effective when they’re synced with a timeline. Work backward from your target completion date to assign dates to each milestone. This lets each project contributor know when their part needs to be complete, and how long they’ll have to do it.
Milestones aren’t meant to be opportunities to micromanage, but without them it becomes more difficult to gauge whether a project is on track or falling behind. Additionally, these milestones give project managers a reason to check in with project contributors. Consider that 57% of projects fail due to breakdown in communications. Staying in communication throughout the project matters, and milestones create practical reasons to do so.
Who’s going to help you see to it that your project is successful? If you completed your scoping step before starting the project report, you should already have an idea as to who you’ll be working with.
However, reconfirm with each department lead that you have the correct individuals listed within your project report, and that they still have the bandwidth to contribute.
Anyone that’s listed as an owner of some step of your project report (and this includes those who will own approvals along the way) should see and review your report before the project gets underway.
Launching Your Project
Now that you’ve done the hard work of putting your project report together and receiving your much awaited stamp of approval, it’s time to get to work. How you launch a project is in many ways just as important as how you build the report around it.
Schedule a kickoff meeting
Set aside time to formally introduce the project to your team of contributors.
Review the project report verbally
In that meeting, cover off on each section of the report. Be sure to emphasize the end objective and resources required.
Use your project planning technology to assign milestones
If you have project management software like Asana, review and assign milestones to contributors during the meeting.
Schedule your check-in meetings
Decide when you’ll reconvene to discuss project status and place those meetings on the calendar. Doing so in your kickoff meeting ensures you won’t forget down the road. Or alternatively, set up recurrent status reports on status.net to make the process hassle-free.
Monitoring Project Progress
So you have your milestones and timelines in place – but what happens when there are road bumps and a step is delayed? How exactly do you know when the project is at risk? And when it is, what happens next?
These are questions likely every first-time project lead will face. While troubleshooting approaches can vary based on the scope and importance of the problem, in general, when a milestone is missed the first thing to do is speak with the person responsible for the milestone.
Ask directly what caused the delay, and assess whether the response provides you with the root cause. In other words, is it that there was another project that took priority for the contributor, or is it that the contributor’s manager is assigning too many projects, making it difficult for them to make progress on any?
It’s the difference between addressing a singular situation and an overarching strategy.
When you don’t identify root causes, you’re likely to see the same problem arise again.
It’s also helpful to recognize the reality of the iron triangle. No, we’re not talking Game of Thrones here. Rather, the iron triangle states that the three central pieces of any project plan – time, scope and expense – are interdependent. When one increases or decreases, the others are affected in either similar or opposing manners. If your expense decreases, scope has the potential to increase (because you can consider adding other elements to the project, because you’ve spent less than expected).
Thinking about the iron triangle can be helpful when deciding how to troubleshoot a project roadblock and answer that “what happens next?” question. For example, when you get that request to expand the scope of the project, you know that either time or expense will need to increase to make it happen.
Whatever course of action you take to resolve the problem – addressing issues with people management, requesting increased spend, or extending timelines – make sure the changes are communicated to the entire project team. This can typically be done through email, unless the change significantly changes the objective of the project.
Post Project Evaluation
Before moving onto your next project, take a moment to reflect on the success of the project just completed. What went well, and what could have been improved? The project’s successes and shortcomings may seem obvious, but their formal documentation is a project management best practice that offers benefits in the long term.
To complete a full evaluation, hold a post-mortem meeting shortly after the project concludes to give each contributor the chance to offer what they felt worked well, what didn’t and what they’d do differently in the future. Record this collective feedback in a document and save for reference when embarking on a similar project in the future.
Post-Mortem Pro Tips:
- Ask attendees to come prepared with responses.
- Schedule the post-mortem at the time of project kickoff, so contributors can be cognizant of successes and shortcomings throughout the project.
- Consider asking for responses in round robin fashion to ensure 100% participation.
According to a study from PricewaterhouseCoopers, only 2.5% of surveyed companies successfully completed 100% of their projects. To be among this small group of companies with high project success, embrace all project management best practices – including writing that initial project report. Writing a project reports establishes a framework that makes it possible for both project managers and project contributors to participate effectively.