7 Essential Tools for Project Managers

 In Program Management, Project Management

I have come across a number of project management methodologies and tools over the last 20 years. Some of them have been useful, some of them have not.

For me at least the following list of tools are the seven most essential tools for the successful day to day management of any project. Master these tools and you will be on the road to repeated delivery success!

1. Statement of Work (SoW) / Project Initiation Document (PID)

These documents are produced as part of the contractual process in the case of the SoW or as part of the project initiation phase in the case of the PID. They should clearly define the project scope, the deliverables, the time scales, the milestones, the roles & responsibilities, the costs, the delivery approach, the assumptions, the risks, the external dependencies and any known issues. These documents provide a delivery baseline, set delivery expectations and as such are essential project documents.

A word of caution. Do not let these documents sit in a drawer gathering dust! Your project team need to read these documents so that they are aware of the full context of the project. You should help your project team to understand what they are responsible for delivering and more importantly not responsible for! This will help your project team to help you deliver the project within time, cost and budget constraints as well as helping you to combat any potential scope creep!

2. The Project Schedule

Having a qualified, robust and deliverable project schedule is a must for any project. Make sure it is sufficiently detailed, fully resource levelled and that it has been qualified with the project team and the project board. See my previous post on how to go about the estimation and planning required to build out a successful project plan. Once the project plan has been approved and base-lined it is important that you review and update it at least once a week.

Track progress against all activities and deliverables. Do this with you project team leaders and ‘walk the floor’ of your project to get a feel from all members of your team about the project progress and issues from their perspective.

Use the overall rolled-up progress shown in your project schedule as a key indicator for your project board. Include this progress and any more detailed project phase progress in your weekly highlight reports.

Finally, compare your actual progress to your expectations of where the project should be at any given time. This is often less scientific and more about gut feelings. However, you need to gauge whether your project is on track or whether it is entering the territory of project delay. There are other indicators to help you with this assessment but this is definitely one of the key indicators so make sure that you continue to ask yourself the question: Is the Project Deliverable?

3. Project Financials

A screenshot (partial) of an Estimate To Complete Spreadsheet

As project managers we absolutely must always be aware of the current financial state of our project! There are a few things that we need to know each and every week:

  • The current actual cost
  • The estimate to complete
  • Variance to budget

If you are delivering on behalf of a vendor you are also going to need a view of the following:

  • The Revenue (Current and forecast)
  • The margin

A basic spreadsheet is all you need to be able to track this information. I always use my Price and Margin Analysis spreadsheet (see the Bonus Outcomes at the end of my previous post) as my starting point for this. I add a new sheet for my Actuals and Estimate To Complete (ETC). Then every Monday morning I review all effort and material costs booked to my project code. I diligently enter the actual effort & calculated costs into my new sheet and then I review my forecast through to the completion of the project.

At month end I review my invoices and qualify each invoice against my spreadsheet. This spreadsheet gives me new actual effort, price, cost and margin. I compare these values against my budget to understand if there are any variances. This is another key indicator for understanding the answer to the key question: Is the Project Deliverable?

4. The Weekly Highlight Report

As a project manager the Highlight Report is your primary mechanism for communicating to your project stakeholders, your project team and if you are a vendor project manager then to your executive team back at base too.

Remember that many stakeholders will have a vested interest in what is written and communicated via your highlight report. My only advice in this regard is to keep it factual, avoid emotive commentary and socialise any issues that may be considered sensitive BEFORE you publish your document.

Your Highlight Report should contain the following items as a minimum:

  • Progress to date (typically for the last week)
  • Current Issues – Don’t list them all, just list the key ones
  • Planned Activities for the coming week
  • Current risks – Again, just the key ones
  • Status of deliverables
  • Status of milestone dates
  • Financial summary

For all open risks and issues I personally prefer to keep a bit of a history of how they are progressing. I provide short updates with the date for each item until they have been formally resolved.

Finally, whilst the primary purpose of the Highlight Report is to provide a running commentary on the status of the project for your key stakeholders it also acts as a great audit trail for the project. You should use it to track trends in the project, monitor progress and for taking the temperature of the project in terms of current issues or risks. This is another key indicator for understanding the answer to the key question: Is the Project Deliverable?

5. The Risk, Assumption, Issue and Dependency (RAID) Log

The tool that you specifically use to implement your RAID log is not as important as the process that you place around it. Personally I have used a number of tools over the years and they are all reasonably good at recording at least the basics of risks and issues. However, most tools and Project Management Offices (PMO’s) seem to forget about tracking assumptions and dependencies! So, for this reason I always like to have my own RAID log built in a basic Excel spreadsheet. There is no need to over complicate your RAID log, a simple unique numbering system, a title, a description, an owner, a created date and a resolution date. For Risks and Issues you will also need an indication of the priority, severity, impact, probability and mitigation. Use a separate sheet for your Risks, Assumptions, Issues and Dependencies.

Be proactive in understanding your project risks and make sure that you qualify them correctly before recording them. Always understand the impact of the issue or risk and always think of how you can mitigate the risk or the options for resolving the issue.

Make sure that there is one owner for each item listed in your RAID log and chase them down for a status update on a regular basis. Remember that these items can contribute to project slippage or in an extreme case the failure of your project. Treat them with the respect that they deserve and work hard to resolve all issues as effectively as you can. Always promote those risks, issues and dependencies that will have a high impact on your project to your key stakeholders and don’t be afraid to solicit their help through proper escalation.

Finally, some issues are likely to have an impact on your project despite all of your efforts and it’s important to understand this impact and review the impact against your project time scales and budget. If there are significant impacts, with no options to resolve them within the agreed contingency at your disposal, then you will need to raise a project delay notice or change request!

6. The Change Request (CR)

When you identify an issue or a key change to project scope you will need to raise a Change Request. As part of the change management process it is important to ensure that you keep your project board, project team and other key stakeholders fully informed.

The Change request should state the background to the proposed change, the nature of the change and the impact of the change in terms of the project delivery dates and the cost.

It should also give an indication of the impact to the project in the event that the change is not approved.

Assessing the impact of the change will involve replanning and estimating your project. You will need to enlist the help of your project team and key stakeholders in doing this, following the same steps as previously posted for estimation and planning. The end result will be an exception plan that will be supported by a new project schedule and a new estimate to complete.

Once you have drafted your CR then I advise that you socialise this with your key stakeholders. Get them to review it as an informal draft and then listen to their feedback and incorporate any recommended changes into the final version of the CR.

Most CR’s will require some careful stakeholder engagement as it will need to be reviewed by the project board, the steering committee and in some cases the board of directors before it is approved. Remember that any changes will need to be qualified against the original business case too.

As per my previous advice, always keep your CR factual and avoid any emotive language. Keeping to the facts will help you to deliver your key messaging and will smooth the path for a more successful outcome.

Finally, the impact of some issues and scope changes can be too much for a project and its underlying business case to bear. On these very rare occasions you must consider what advice you give to the project board. Sometimes the right advice under such circumstances will be an aggressive re-scoping of the project or in a worst case scenario the cancellation or termination of the project. Always remember what’s in the best interests of the business as a whole and never make such a recommendation lightly or alone.

7. Project Board Report

A sample infographic that displays a projects overall status – useful for a Project Board Report

Typically once a month you will need to report to your primary stakeholders and your project sponsor via the project board. How you do this and the messaging that you communicate is particularly important for you as a project manager and for the project. Always remember the saying ‘Perception is Reality’ as it’s important that you manage the perception of the project with your key stakeholders.

Mechanically, the Project Board Report is similar in structure to the weekly highlight report in that it needs to include the following:

  • Progress to date (typically for the last week)
  • Current Issues – Don’t list them all, just list the key ones
  • Planned Activities for the coming week
  • Current risks – Again, just list the key ones
  • Status of deliverables
  • Status of milestone dates
  • Financial summary

However, try to make this report more visual and ensure that you select the right items and level of detail in your communication. Unless otherwise asked to do so keep any key risks and issues to a maximum of 5 in each case. Also ensure that your financial summary is high level – keep a more detailed view of the project finances on hand should you be asked any questions.

I recommend that you use PowerPoint for your Project Board Report. Use some infographics if you can to convey the important project details in a summarised format. Always keep to the facts and ALWAYS socialise the report with your key stakeholders well in advance of the board meeting. No stakeholder likes surprises on the day of a Project Board, so work hard to understand the position that each stakeholder is going to take with regards to key issues and risks.

As the slides will be conveying summarised information do spend some time preparing your commentary to each slide. Think about the key messages that you want to convey. Remember that the board meeting is a two-way conversation. Give the board members plenty of opportunity to ask you questions and be clear in conveying to them what you need them to do. Most Board members will appreciate the engagement and will be more than happy to help you with any escalated issues.


As I always say, these are my own views and the tools mentioned above are what I personally believe to be the basics for any project manager. I’m happy to take feedback and I’m open to adding new tools to the list but if you master the tools listed above you will become a great project manager!


See more of me and my posts on LinkedIN


p.s. The examples used here to illustrate the discussion are totally fictitious and are not intended to bear any relation to real names or companies!!

Recommended Posts
Contact Malcolm

Malcolm is not around right now. But you can send him an email and he'll get back to you, asap.

Not readable? Change text. captcha txt

Start typing and press Enter to search

Product Based PlanningWalk The Floor