Project management is a difficult undertaking for any team. Essential tasks like ensuring the right resources are available, assigning responsibilities, spotting potential risks, and proper communication can be nerve-wracking and it’s not surprising if something or other gets forgotten and falls off the radar.
In fact, it turns out that only 2.5% of companies successfully complete 100% of their projects.
Why is this? Mainly because unexpected obstacles or events pop-up to derail and hamper the progress of the overall project.
But also because good project managers don’t always have team members who understand project management or who can see how and why everything fits together.
Here’s a live example:
We’d been working with a team in a large organisation who had a few holes in their project management process, especially around communication.
The person in charge of projects wasn’t hearing about the problems that were happening until it was too late, and various things went wrong:
- There was a lot of repetition and inconsistencies
- Communication was not going to the right people
- Teams in different silos did not understand the relative importance of timelines
- One manager wasn’t updating on a project until very late in the day
- Things weren’t checked before they were sent out
It caused a lot of headaches.
To help them solve this, we worked with the whole team to design the best project management format for them – because they had all been engaged in the design of it, they all understood the necessity of using it. By the end so many decisions were made, agreed, and had champions to ensure the roll out, it worked really well.
This is what we learned: the best way to manage projects is communication, communication, communication.
If you have issues with project management, it’s worth looking at how you run projects to make sure the right steps are being taken in the right order, people know what’s going on, and issues are resolved in a timely manner to keep the project on track.
Partly this is about setting the project up in the right way, making sure everyone is on board at the get-go, and that you can foresee potential risks.
There are usually 4 phases in managing a project – which make up the path that takes your project from beginning to end:
- 1. Initiation
- 2. Planning
- 3. Execution
- 4. Closure
(sometimes there’s a 5th – monitoring)
The stages in managing a project
With so much riding on project management, we’ve put together a three-part guide to make sure your projects go well.
- Part one: Things to do before you start a project
- Part Two: Things to do during the project
- Part Three: What to do after a project is finished
Read part one below, parts two and three are in separate blog posts.
——
Project Management Part 1: Things to do before you start a project
There are six things you need to do before you start a project.
1. Ensure you have a common language
When you talk about projects and project management, make sure your team shares a common language so that when you use a specific word, everyone knows what you’re talking about.
For example, are you all clear on what these mean:
- Project
- Manifesto/Mission statement
- Client
- Stakeholder
- Audience
As a test of this, does everyone in your team know the difference between an audience and a stakeholder?
(fyi An audience usually means a receiver of one-way messages and information, whereas stakeholders have something to gain or lose, and can impact an organisation by what they do. Stakeholders include employees, customers, suppliers, shareholders, NGOs, regulators, policy-makers and the general public.)
What terms do you use?
What you’ll find is that not everyone shares the same understanding of these words, so create a shared glossary of terms with definitions of what it means in your organisation, so that there’s no misunderstanding.
Creating the glossary as an exercise with your team will help you uncover assumptions that you didn’t know you’re making. Some things are very obvious to some people but they’re not to others, and if you’re not using the exact same words, then it’s not obvious to everyone what’s meant.
Check in with your team members from time to time during the project to make sure they know what you mean.
2. Get your team on the same page
Use the Team Canvas to get everyone on the same page
Before you start the project make sure everyone is aligned, conflicts are resolved, and you have a productive culture.
Try using the Team Canvas tool (pictured) – to work out where you’re all at, what you all want out of the project on a personal level and on a team level, what skills you’re all bringing to the party, and what the purpose of the project is, so that you’ve got alignment and everybody is on the same page.
3. Work out the project plan
A standard approach to working out the project plan is to use the Waterfall model. (Read about another way to manage projects – Agile – in Project Management part two.)
The Waterfall model has five phases that follow in a strict linear order, where one phase can’t begin until the previous phase has been completed:
The Waterfall model has five phases
- Requirements
– gather everything needed to initiate the project (see below) - Design
– breakdown the tasks and create the schedule (see below) - Implementation
– complete the tasks. - Verification
– the customer reviews the product to make sure that it meets the requirements. - Maintenance
– fix any problems and errors that come up.
We cover the first three of these steps below. The remaining steps are covered in the next two blog posts.
i. Requirements Phase
Create a Project Initiation Document
How do you initiate a project? A Project Initiation Document is a way to provide the foundation for the project, and typically includes goals, constraints, stakeholders, risks, sign off and more.
If you don’t have a standard format, or even if you do, try designing a Project Initiation Document using CPORT as a structure – it’s a good starting point. CPORT stands for:
- The Context
- The Purpose
- The Outcome
- The Resources
- The Time
Read more about CPORT here, a key part of it is the critical questions that help you identify the risk factors: ie ‘what if X happens, what if Y happens…’
Pay particular attention to what comes up when you ask these questions and make sure you look at the risks and what might go wrong first, and definitely as part of the process of starting the Project.
ii. Design phase
a. Map out all the project steps at the start
The next step is to map out all the steps and actions involved in completing the project before you start. This is the design phase.
Woking on the design phase as a group gets it out of everyone’s heads and makes it visible: everyone will understand the stages involved, see where overlaps are, and where the blocks might be.
We use a Project Mapping tool for this, writing each action on a blank card to map what happens at each stage, and what needs to happen.
We use a Project Mapping tool to map all stages in a project
b. Put all the actions into a timeline – to show what needs to happen when
Put all the project actions from the mapping exercise on a timeline. What will become clear to everyone when you do this are the things that need thinking about earlier on in the project, so you can plan them in to make sure there’s no surprises or spanners-in-the-works later on, and the critical dependencies – the things that must happen in the right order or the project will derail.
Many people associate GANTT charts with projects. They can be really useful though not every project needs one. So before you do a Gantt Chart, it’s really useful to map the project out on a rough timeline with the team first, so that everyone gets to chip in and share what matters.
For each project step, interrogate the timeline working backwards from the delivery date, to make sure you have identified what needs to happen when, how long are things going to take, and where the inefficiencies or holes are.
It may unearth more problems you might have, in how you start projects and where they need to be more clear right at the beginning, and what the purpose of things are.
You’ll end up with a project map in front of you.
c. Make a GANTT chart if needed
A Gantt Chart illustrates a project schedule – use if needed
If your project warrants it, build a Gantt Chart – a type of bar chart that illustrates a project schedule – allocating dates and times.
When working on this with one client, we created a version on paper together first. This helped everyone see what needed to happen when, and the project managers gained respect as other team members understood the necessity and complexity of a Gantt chart.
You don’t necessarily need to do this as a group, but if you do, then everyone can see what’s involved – not only the Project Manager who might otherwise only be able to do it from their own point of view.
A Gantt Chart will show up helpful stuff, like for example, if the data department are saying they need to know something earlier on – then you can map the project out in a way that’s more realistic to complete.
In another example, we used it for a team who are based in different locations. We mapped out how they communicate as a group – what normally happens, when, and who needs to know. By doing this they worked out new ways of communicating who was doing what, and what stages different bits of their projects were at.
As part of this process it’s important to work out how you centralise communication. You might end up using a shared calendar that everyone has access to, and colour coding it so the whole team can know what’s going on and see where things are at.
d. Get clear on roles and responsibilities (RACI)
Once all the tasks involved in a project are put on a timeline, next look at roles and responsibilities: who’s going to be doing what? Who reports to who?
We use a RACI chart for this which shows: Responsible, Accountable, Consulted, Informed.
How to do this:
1. Create a Matrix on a big sheet of paper
2. Put all the Tasks down one side,
3. Put the Names of everyone involved in the project team along the top,
4. Using post-it notes assign the actions and responsibilities to each task.
Often the Project Manager will do this, and allocate who is going to be responsible, accountable, consulted and informed:
- Responsible (R)– who is actually doing it?
eg carrying out the work, writing the report, organising the event, visiting the clients etc. - Accountable (A) – who owns the project and is delegating the task to the person who’s responsible?
If you’re accountable, your head is on the line, it’s your job, but you are not necessarily doing the actual work ie a project manager. - Consulted (C) – whose input is important for the project?
- Informed (I) – who needs to be told what’s going on?
Use a RACI chart to get clear on roles and responsibilities
What’s important when assigning roles and responsibilities
Make sure someone is accountable for each task.
Look to see whether too many people are accountable for some tasks, or too many people are being consulted, working out whether every task is covered, but not too heavily covered.
It’s good if everybody can see this process. It should be part of the Project Initiation Document.
Be clear on who’s consulted and who’s informed, and be clear on what the responsibilities mean – ie what does being accountable for something mean?
Make sure people know the difference between those things – so when they talk, everyone will know what’s meant when someone says, “we’ve got to consult so and so.”
In conclusion
Project management is all about clarity and communication across the whole team at the start, during the project and at the end.
So once you’re clear on who’s doing what and when at the start, when you’ve mapped out all the steps and your team are on the same page, take a look at Project Management Part 2: Things to do during the project.
If you’re struggling with projects and everyone is doing things differently and inconsistently, and need some help, get in touch. At Then Somehow, we have tools and programmes that are good at helping your team agree a consistent approach. Get in touch here.