I picked up a project from someone else not that long ago and I was three months into my management of it before I realised there wasn’t a project charter. There were lots of other documents that all had a degree of overlap with a charter, but not an actual charter. That meant there were some key things missing from the project’s paperwork and the most important thing missing was who was going to pay for it. Oops.
That was a bit of a headache to sort out.
Project management can create a lot of paperwork, and it’s not always the stuff you want or need. Let’s talk about the essentials. Here are nine documents that no self-respecting project should be without. I’ve organised them in order of project lifecycle phase.
Contents
1. Business Case
At the Concept or Idea phase of a project, someone comes up with a bright idea. That is written down into a formal project proposal or business case.
The project business case is the document that kicks off the whole project. It’s written to explain why the project should happen and it summarises the problem the project is going to solve.
It should be comprehensive and persuasive with enough detail to justify the investment required for the project.
Having said that, the business case could be as simple as an email to an exec asking for permission to go forward with an initiative. If you were building an Olympic stadium, that level of informality wouldn’t be enough.
Be reasonable and pragmatic – there’s no point in creating overkill documentation at this point. It will just make people weary of what admin is to come.
Once the business case is approved, you can move forward into the Project Initiation phase.
2. Project Charter
The most important document in the Project Initiation phase is the project charter.
You need this – it gives you the authority to act as project manager for the project. It’s your mandate to run the project and it’s the document that turns the project from an idea into an actual program of work, with allocated owners (and agreement on funding). Without it, your project doesn’t formally exist!
Project charters can be short or substantive. I prefer to use a fully-rounded version that in our terminology we call a Project Initiation Document. It includes everything you need to know about what you’re starting with.
Once you’ve got clarity on what the project is going to do, and the context in which it is going to operate, it’s time to move into the Planning phase.
3. Project Management Plan
The Planning phase gives you two documents. The first is the project management plan.
This is a huge document. In fact, it’s probably not one document (although I have bundled it together in the project management plan template you can find here). In the past I have always managed it as separate documents but together they form ‘The Plan’.
More recently, my projects have been operating under a formal PMO structure, and much of what goes in a project management plan is basically repeating the formal processes. There’s no point creating a plan document just to say, “We do it the way the PMO mandates, just like every other project in this company.” In that case, I have one over-arching project management plan document and it references corporate standards.
The plan covers everything you need to know and do to manage the project including things like managing project tolerances, variances, the change control approach, how you’ll assess quality and so on.
Report this ad
4. Project Schedule
The other document that is important in the Planning phase is the project schedule.
Frankly, most people say ‘project plan’ when they mean ‘project schedule’.
The project schedule sets out all the tasks, who is going to do them and when they are going to be done. It also tracks dependencies between tasks.
You can use software to organise the project timeline for you. There are hundreds of different project scheduling tools – most organisations have something. The trouble is, it might not be perfect for what you want to use it for.
I create project schedules in Microsoft Project, Teamwork and Excel, because I use them for different things. For communicating top-level milestones, I create a version of the schedule in Microsoft PowerPoint using the Office Timeline plugin.
However you choose to document your project schedule, the important thing is to keep it up to date.
5. Project RAID Log
We’re now moving into the fourth phase of the project, the Execution phase. At this point, you’ve got a number of important project documents. The first we’re going to look at for this phase is the RAID log.
RAID stands for:
- Risks
- Actions (and/or Assumptions)
- Issues
- Dependencies (and/or Decisions)
I use the term ‘RAID log’ to cover all the different logs relating to the project. That includes all the elements in the list above, plus changes. RAAIDDC is harder to say, though.
It pays to have a register of all these items. Your project RAID log is an important document that lets you can keep track of everything. It’s easier to create than you’d expect as you only really need a few important fields:
- Item ID, so you know what line you’re talking about when you discuss the content with your team
- Item name
- Item description
- Action required
- Owner – don’t forget this or no one will take responsibility for doing anything about it
- Last updated date.
You can pretty much use that format for all the different sheets and trackers within your RAID log.
A RAID log can be part of your project management software or you can do what I do and maintain a spreadsheet.
6. Project Status Reports
Project status reports are another critical document during the Execution phase. You are busy doing the work, so you need to tell people what work is going on. They also help you track what’s going on.
Project status reports cover a range of different scenarios. You have:
- Formal project board reports
- Weekly information team updates
- Formal reporting to the PMO
- Ad hoc reports whenever a stakeholder asks for something.
And so on. Project managers spend a lot of time reporting.
OK, these are a collection of documents rather than a single document. But they are really important because they’re the mechanism you use to get information to your stakeholders on a regular basis. They are the formal written record of progress. And if they are any good, your stakeholders should take action as a result of reading them.7. Project Budget Tracker
Finally for the Execution phase, you have a project budget tracker.
Your project budget is a different sort of document – it includes less text, and a lot more numbers. However, it helps to have a text-y document to go with the calculations that sets out information about contracts, procurement and the financial processes you’re expected to follow. You can wrap this into your project management plan.
The budget tracker needs to show you what you have forecasted to spend i.e. “the budget” and what you have actually spent. You can then get the spreadsheet to do the heavy lifting and work out the variance.
Variance is the difference between what you forecasted and what your actual spend was. If you are overspent, you can identify the line items where this has happened. If you are coming in under your forecast, you may have some flexibility to add more items into scope.
Or you may have to hand the money back – different Finance departments and project sponsors will have different priorities!
8. Lessons Learned Review
The final phase of your project is Closure. There are two project documents that are important at this point; the first is your lessons learned documentation.
Lessons learned documents might not actually be documents. You could store your lessons learned in a database like CornerThought or wiki, or some other searchable format.
I still produce formal end of project lessons learned documents though, and then copy the key lessons into any other system that requires them.
The lessons learned paperwork forms part of your project closure work. It only becomes a useful reference if you share it with the people on this team so they’ve got something that codifies the lessons they learned while working with you.
Equally, it should be shared with other project managers or they won’t benefit from what worked and what didn’t work.
9. Project Closure Document
Finally, during the Closure phase you should produce a formal project closure document.
This document summarises:
- What the project delivered
- How the project performed against time, cost, quality and scope measures i.e. were you late, over-budget or struggling to get a quality result?
- Any outstanding risks, issues and actions at the point of closure
- The location of project files
- Anything else the person receiving the handover needs to know.
Of all the documents, this is the most important one to get formally signed off and approved. Without the project sponsor agreeing to the project being closed, the project is not closed.
You’ll end up doing ad hoc work and support for months. (Don’t ask me how I know.)
Choose the Documents That Work For Your Project
The most important thing to remember is that this is a guide. Tailor the project documentation you need so that you can best manage your project. You need a detailed procurement plan? Make one. You don’t need a budget tracker as there is no external spend? Don’t create one and leave it blank; that’s a waste of your time.
Don’t get hung up on what you need to have – just use the above as a guide for what most projects of on-the-larger-side-of-small-but-not-gigantic have.
Less admin time spent creating documents that don’t add value means you can free up more time to lead your team. It’s more important that you do the work on the project. Onerous paperwork is no fun for anyone.
Stick with these nine documents you’ll be able to control your project without too much bureaucracy.
by
source
No comments:
Post a Comment