The template I'm sharing in this post is on Google Docs but you can download it in any format suitable for you and change it according to your needs.
Keep on reading to get more details of what's included and the why's and why not's.
What's not includedAnything that you'll need to manage a project that is not applicable to any project (in size, complexity or whatever) is excluded from this template. So if you need something like Earned Value to manage a project you won't find it in this template - just because you don't use Earned Value in every single project.
Surprisingly, that are 2 things that I don't include in this template that I assumed I would need in every project - and in fact I don't. Business cases and requirements are missing from the template, which you may find chocking but the fact is I don't need them for every single project.
Business casesSome projects don't need a business case just because the project just has to be done, like the case of mandatory projects. You may find this counter-productive and I agree with you that even in the case of mandatory projects you should know what kind of return, if any, you'll get from the project. But in my experience and in my context I don't find the need for it in all projects, in some it's just too much work for too little of a return - but I do have other projects that I wouldn't start in anyway without a business case.
RequirementsI found that for some simple projects I don't really need requirements. Most projects do need them but for those simpler ones that I'm most used to and that are really short in time - well, it's just not worth it. Think of software deployment, for instance. If you're deploying this software for a Point Of Sale in a small shop with just one cashier, will you get any return from capturing and controlling requirements? You know what will be done anyway: you'll install the software, load the products and explain to the cashier how it works. If the projects is more complex than this, if, for instance, it includes integrating data with some accounting system, then you'll need some way of capturing the requirements. But not in all cases.
What's includedEverything I need for every project is included in this template. This includes the project identification (to know what is to be done, who is the client, why he wants the project and so on), the team in the project and so on. Details follow, and you can download the template from this link or check the complete list of the downloads available in the downloads section.
The main advantage of having all this captured in a single document that uses the same format for every single project is that people know where the things they need are. So even if it's a bit of hard work that you may find that you won't get any return, the fact is that I do get enough return.
For example, you could argue with me that not all projects have issues - just like some don't need requirement management. But even if there's a project without issues (I'm still to find one), you know that later on, after the project is closed, if something about that project arises you can check this document and confirm that there were no issues with that project.
IdentificationAlongside with some basic facts about the project (client name, sponsor, start date and so on), you'll also find some useful information. Business objectives serves to capture why the business needs the results of this project (the outcomes). And the project deliverables will show what will the project deliver (the outputs) so that the business gets the outcomes they want. For more on outcomes and outputs please check the Beginners Guide To Project Management.
TeamThis just serves to capture who was working in the project and their contacts. During the project this is somehow useless as you probably have the contacts of your team in your email, phone and so on. But after the project is done it can be really useful to have one place where you know this information is stored.
StakeholdersSame here. This section is too short when you need to actively manage your stakeholders but it serves to record who the project stakeholders were and retrieve that information after the project is done, if and when needed.
MilestonesThe record with the project milestones goes in this section with the target dates and when they were actually achieved.
CommunicationThe simplest form of a communication plan that I know of is included in the template. It basically states what information should go to whom and when.
Risk/opportunity registerThis is where you register the risks and opportunities that you and your team identify in this project. You may find odd that I'm leaving out requirements and business cases and including risks and opportunities. But again, in my experience, all projects have risks and opportunities. And if they don't (which I've never found) at least you have a record that says "this project had no risk and no opportunity" - and only reading this sounds reaaaally weird...
Risk/opportunity qualificationAnd for each of them, you're forced to think for a couple of minutes about them so you can classify the risks and opportunities and select which you should focus your attention on. Just this. If you get a way to put this information in just one table, please let me know.
Issue LogWhen problems arise, record them here. This can take a wide range of different forms, this particular one captures all the basics for me.
ConclusionThis is an approach to manage and record the most basic needs of any project. I don't really know how widely you could use this template but I can tell you that it works just about perfect for me.
And this is something that I'd like some feedback on: can you use it? is there something missing? is there something that you don't need?
Image from http://berxblog.blogspot.pt/
Posted by Luis Seabra Coelho