If you frequently get stuck while setting up a project, this article will help you. What I’m gonna show you is a document based approach to prepare and set up new projects. Any project.
By following my approach — and doing your homework (mainly clarifying the project goal) — you’ll no longer get stuck during project launches.
From overwhelm to clarity
We get stuck when we are focusing on too many things at the same time:
- Figuring out how to go about for your project
- Getting estimates from team members
- On-boarding stakeholders
- Setting up a budget
- Setting up a document share
- Getting your new laptop to work
- .. ADD 100 OTHER THINGS TO WORRY ABOUT
What happens is you end up completely overwhelmed and not moving forward.
And I don’t want that to happen to you.
Here’s how you can avoid overwhelm with new projects:
Ask yourself this question
Instead of starting with a blank page, ask yourself this question:
What documents do I need to prepare for my new project?
Your work becomes much easier that way.
Why it is smart to start with the documents
When you focus on the documents that need to be created, you have a step-by-step process for setting up a project. Setting up a project becomes like painting by numbers.
And even painting a Mona Lisa becomes achievable when all you have to do is fill out a pattern.
Look at this:
I’m not saying everything will become easy. Leading a project remains a tough job. But at least now you have a path that will take you to a complete and consistent action plan.
And all you have to do is fill out documents, one by one, until your project is fully-planned.
You can organize your calendar this way.
- Today you write the project charter
- The next day you create the schedule
- Again the following day you plan out the budget
After 2-3 weeks of juggling Word and Excel, your project is ready to go!
Writing is thinking
You know what I found most helpful about this process?
Putting your ideas on paper forces you to think through your idea and to verify if it actually makes sense. This is how your initial, crappy plan becomes rock-solid in the end.
Just by writing it down, thinking and refining.
The documents you need for any project
Here’s the minimum set of documents you need:
|action and issue tracker||track pending actions and open issues|
|project charter||a sort of contract between the customer and contractor|
|project organization||overview of people and roles in the project|
|project roles and responsibilities||description of roles and responsibilities|
|project plan||activities and timeline|
|project budget||project cost (plan and actual)|
|stakeholder matrix||list of stakeholders involved in the project|
|risks log||critical risks|
|project communication plan||structures communication and meetings in a project|
|scope statement/requirement specification||description of customer requirements|
|change request tracker||track changes to the project scope|
Description of the documents
Learn what each document is for. I added my templates.
1. Action and issue tracker
Record all action items and issues in a simple Excel file. Here’s the action tracker I use:
2. Project charter
A project charter is like a contract between you and the client. It contains essential project information like milestones, budget, schedule and the high-level scope in a summarized form.
Learn how to fill out a project charter and download the template (same link).
The project charter is usually created in close collaboration with your client. You sit together and discuss expectations, responsibilities, important milestones and other things. Then you document everything in the project charter and make revisions factoring in the client’s feedback.
3. Project organization
A simple org chart of the entire project organization. It shows who is working in the project.
You’ve seen such kind of org charts before:
Read also: How to create an org chart using Powerpoint (external link).
4. Project roles and responsibilities
People need clarity on what they are expected to do. Otherwise, team members will be running around like headless chicken and the project will not move forward.
Create a simple Powerpoint with the key roles and responsibilities. I recommend reading my article on defining roles and responsibilities.
Once you have defined the roles and responsibilities, share the information in a team meeting or project kick off. It’s not enough that you know what team members are supposed to do. You need to explain this to your folks!
5. Project plan
The project plan shows everyone what has to be done by when. You can use my project plan template for Excel.
If you are creating project plan on a regular basis, I recommend using a tool like Tom’s Planner — it makes drawing Gantt diagrams much easier.
6. Project budget
Obviously, you need to put the cost somewhere. If you haven’t already downloaded my project budget tracker, you can do so here.
The file allows you plan estimated effort and cost and to track actual expenses on a monthly basis.
If this is the first time you’re setting up a project budget, read my practical guide on project budgeting. The article shows you how to estimate and calculate project costs for each category, from personal effort to material and service fees to capital expenditures.
7. Stakeholder matrix
I recommend you also create a stakeholder matrix. This is an overview of all stakeholders of the project or – in other words — a list of people (or organizational entities) that might be affected by your project.
Why is it a good idea to create the overview? You don’t want to miss anybody in your project who might actually have a saying in it. Also, you want to communicate early to people who might be affected by the project’s scope.
Remember that stakeholders can be internal as well as external (for example government agencies).
Putting together a stakeholder matrix takes some time and a bit of “detective work”. That’s why I suggest you follow my guide on performing a stakeholder analysis.
8. Risks log
The benefits of the document-centered approach to project planning becomes clear when we talk about creating a risk log.
A risk log (or risk register) is where you record the most critical risks your project could be facing. It doesn’t just define those risks, but it also requires you to think about mitigating actions. Actions that either reduce the negative impact of a risk or alternative steps you could take if your original plan fails (your plan “B”).
Should you create a risk log? Absolutely! My article on performing a project risk analysis walks you through the process (includes a risk log for download).
9. Project communication plan
How often does the project team meet? When do you send out email updates to management? What’s the escalation process?
That’s what you define in a project communication plan document (includes template).
The reason why a communication plan is so important: As I’ve been stressing in my other articles too, good communication is absolutely essential for the success of your project:
- Good communication means that that news and updates are regularly shared with the team and stakeholders. This way people know where the project is at. And they know what actions or issues are still open and require their attention.
- Good communication also means fostering team collaboration. That is to bring the participating team members together on the same desk in order to work on common tasks or to brainstorm potential solutions for the issues the project is facing.
The communication plan defines the type and frequency of meetings and email updates and thus enforces proper collaboration and communication within the project.
10. Scope statement (requirement specification)
This document should include a detailed description of the project scope and the customer’s requirements (what is meant by project scope?)
For example, if you’re building a new machine for a customer, the scope statement must specify in detail what the machine is supposed to do and how it’s going to be used.
If you’re setting up a new IT system, the scope statement (or requirement specification) must include a detailed description of the system features and interfaces with other systems.
The scope document determines the timeline and budget of the project, so it must be put together with great care. Often this can be a long process but it’s worth to put in the time until you have an approved and accurate scope document.
11. Change request tracker
As a project progresses, there will be changes to the initially agreed scope. This is totally normal and you can’t completely avoid that.
- Your customer may decide that he would like marble instead of wooden flooring for his new home.
- In an IT system rollout, the customer realizes that the system needs to be hooked up with another external system which wasn’t considered at the start.
Both examples are so-called changes (or change requests) to the original project scope. They both will impact the project cost and maybe also the timeline. In other words: the project may require more time.
It’s a good practice to track such changes in a simple change tracker. Even if they are small. This allows you to set up a formal and well-organized process where every change gets reviewed, estimated (extra cost) and approved.
No change will be forgotton and nobody can blame you when the project budget goes up because a change was implemented. So, it’s a way to protect yourself as well.
For bigger changes I recommend you create a dedicated change request form. This is simply a detailed specification of the new requirement.
In my project scope article, you’ll find an Excel change tracker as well as my change request form.
A few more project documents I did not list here
There are a couple of project documents I did not include in the overview. That’s because I don’t consider them as essential for a successful project. However, you may want to use one or the other if internal project regulations require you to do so, or if you just consider them helpful.
- Business case: You create a business case to show that your project has economic and strategic benefits. For many projects this makes sense. On the other hand, many projects are started without an economic benefit in mind. They are just launched because they have to get done. An example would be upgrading a company’s outdated PC or network infrastructure.
- Project status report: Everybody uses their own template for communicating the project status. I didn’t want to limit you in that respect. If you are looking for proven template, get my project status template.
- Lessons learned document: It’s a great practice to conduct a lessons learned workshop after a project is complete. It makes any future project better, because you learn from the things that have worked (or that didn’t work). But for your project itself a lessons learned document is not required.
Do you have a question about project documents?
Happy to help you. Just post your question as a comment below and reply.