What do you do when you’ve just landed a new project? Do you start scheduling tasks straight away and get the team into gear? Here are six things you should strive to do as early as possible.
1. Validate business case
One of the first things you should do as a project manager when a new project gets assigned to you is to find out why the project is important and to validate that it has an acceptable business case. As a PM you are not responsible for the business case, but it’s important that you are familiar with it and that you buy into it. Too many projects get kicked off without a clear objective, rationale or benefit and when it later runs into trouble it can easily reflect badly on you as the PM. Don’t let that happen. Have a conversation with the managers who allocated the project to you and ask them what the reasons are for the project, what success looks like once the project has been completed and how they would like to measure it. Fully understanding the business case will make you better able to make decisions and steer the project in the right direction.
2. Identify sponsor and steering committee
The next thing is to understand who the decision makers are on the project and who you are reporting to. Ideally there should be one person who is accountable – the sponsor – and who acknowledges their accountability. I’m often asked if the PM and sponsor can be the same person, but that’s not an ideal scenario. As a PM you are responsible for delivering the project according to the time, cost, quality and benefit parameters set out by the sponsor. If any of these parameters change you need to escalate and seek guidance from the person above you in the project hierarchy. The sponsor will normally need support from other senior players within the organization, and together they form the steering committee. Make sure you know which decision-makers sits on the steering committee and that they meet on a regular basis to provide executive guidance to your project.
3. Analyse stakeholders
It’s very important that you don’t jump into the project and start scheduling tasks without having a good understanding of who the stakeholders are. A stakeholder is anyone who is either impacted by the project or who can impact the project. If you don’t identify all the stakeholders early on there is a risk that fundamental requirements are omitted and that the project won’t be fit for purpose. Another reason why you have to pay attention to the stakeholders is that you need to manage them in such a way that they will back up the project. Ask yourself who the most important decision-makers are and how supportive they each are of the project. Your role is to secure each person’s buy-in to the project by taking on board their reservations and by working with them to create the best possible outcome for everyone.
4. Set ground rules
On many projects it’s not uncommon that tasks don’t get completed in the desired timeframe and that the work isn’t done in the way the project manager was hoping for. The fundamental problem is that the PM has a set of expectations that have never been explicitly stated or discussed. These are expectations that don’t just relate to the quality of the work but also how it’s getting done. Having a rulebook that no one has had input to - let alone been told about - is a recipe for conflict. The best way to create an effective and harmonious project team is for the team to produce a common set of ground rules that addresses how they will work together. It’s not for the PM to set these rules but for the core team to define. One such rule could be that we always deliver what we promise and that we will inform our co-workers at the first opportunity if we aren’t able to fulfill our commitment. Another ground rule could be that the PM will always keep the team informed of what is decided at a steering committee level. It doesn’t matter what the rules are as long as they have been collectively agreed and work for everyone.
5. Gather requirements
It’s likely that only the top level requirements or objectives have been identified by the time the project gets handed over to you. It’s then up to you and the team to interview the stakeholders to find out what they require from the project in detail. The mistake that many teams make is that they don’t gather the core requirements in enough detail and that they are not explicit about what they will not deliver. That can result in misunderstandings, disputes and rework. Set up a series of requirements gathering workshops where you talk through the current state and the future state and map out all the changes that are required. On some projects it isn’t possible to define all detailed requirements up front as not everything can be decided that early. You do however need to map out all the core functions, set priorities and understand what a successful outcome looks like before you start the work. Creating flow diagrams, storyboards, mock-ups and prototypes are excellent ways to shed light on the requirements as opposed to simply putting words on a page.
6. Create high-level plan
Another activity that needs to be completed before the team embarks on the work in earnest is to create a collaborative milestone plan. After having gathered the majority of the requirements you are in a good position to identify the top 10-15 milestones and decide when they need to get completed by. There is a huge difference in doing this work on your own and engaging the team in doing it. When you engage the team and come up with the high level plan in collaboration you gain their buy-in in a completely different way. After you have identified the key milestones, discuss who owns each milestone and the detailed plan below it. This collaborative planning session should also comprise a discussion about what the most important risks are to the project, what you are going to do to address them and who owns each risk.
When you get allocated a new project, don’t just start executing the work straight away. At the least you must first understand if the project has a valid business case, who the project sponsor and the remaining stakeholders are, help the team come up with a common set of ground rules, gather all core requirements and create a high level milestone plan that the entire team is bought into.
If you liked this post, you may also like:
Initiating and Planning Your Project, Part I
What makes a perfect Project Initiation Document (PID)?
How to deal with skeptical stakeholders
What you should do in the first month to set yourself up for success
Top Tips for Gathering Requirements
One of the first things you should do as a project manager when a new project gets assigned to you is to find out why the project is important and to validate that it has an acceptable business case. As a PM you are not responsible for the business case, but it’s important that you are familiar with it and that you buy into it. Too many projects get kicked off without a clear objective, rationale or benefit and when it later runs into trouble it can easily reflect badly on you as the PM. Don’t let that happen. Have a conversation with the managers who allocated the project to you and ask them what the reasons are for the project, what success looks like once the project has been completed and how they would like to measure it. Fully understanding the business case will make you better able to make decisions and steer the project in the right direction.
2. Identify sponsor and steering committee
The next thing is to understand who the decision makers are on the project and who you are reporting to. Ideally there should be one person who is accountable – the sponsor – and who acknowledges their accountability. I’m often asked if the PM and sponsor can be the same person, but that’s not an ideal scenario. As a PM you are responsible for delivering the project according to the time, cost, quality and benefit parameters set out by the sponsor. If any of these parameters change you need to escalate and seek guidance from the person above you in the project hierarchy. The sponsor will normally need support from other senior players within the organization, and together they form the steering committee. Make sure you know which decision-makers sits on the steering committee and that they meet on a regular basis to provide executive guidance to your project.
3. Analyse stakeholders
It’s very important that you don’t jump into the project and start scheduling tasks without having a good understanding of who the stakeholders are. A stakeholder is anyone who is either impacted by the project or who can impact the project. If you don’t identify all the stakeholders early on there is a risk that fundamental requirements are omitted and that the project won’t be fit for purpose. Another reason why you have to pay attention to the stakeholders is that you need to manage them in such a way that they will back up the project. Ask yourself who the most important decision-makers are and how supportive they each are of the project. Your role is to secure each person’s buy-in to the project by taking on board their reservations and by working with them to create the best possible outcome for everyone.
4. Set ground rules
On many projects it’s not uncommon that tasks don’t get completed in the desired timeframe and that the work isn’t done in the way the project manager was hoping for. The fundamental problem is that the PM has a set of expectations that have never been explicitly stated or discussed. These are expectations that don’t just relate to the quality of the work but also how it’s getting done. Having a rulebook that no one has had input to - let alone been told about - is a recipe for conflict. The best way to create an effective and harmonious project team is for the team to produce a common set of ground rules that addresses how they will work together. It’s not for the PM to set these rules but for the core team to define. One such rule could be that we always deliver what we promise and that we will inform our co-workers at the first opportunity if we aren’t able to fulfill our commitment. Another ground rule could be that the PM will always keep the team informed of what is decided at a steering committee level. It doesn’t matter what the rules are as long as they have been collectively agreed and work for everyone.
5. Gather requirements
It’s likely that only the top level requirements or objectives have been identified by the time the project gets handed over to you. It’s then up to you and the team to interview the stakeholders to find out what they require from the project in detail. The mistake that many teams make is that they don’t gather the core requirements in enough detail and that they are not explicit about what they will not deliver. That can result in misunderstandings, disputes and rework. Set up a series of requirements gathering workshops where you talk through the current state and the future state and map out all the changes that are required. On some projects it isn’t possible to define all detailed requirements up front as not everything can be decided that early. You do however need to map out all the core functions, set priorities and understand what a successful outcome looks like before you start the work. Creating flow diagrams, storyboards, mock-ups and prototypes are excellent ways to shed light on the requirements as opposed to simply putting words on a page.
6. Create high-level plan
Another activity that needs to be completed before the team embarks on the work in earnest is to create a collaborative milestone plan. After having gathered the majority of the requirements you are in a good position to identify the top 10-15 milestones and decide when they need to get completed by. There is a huge difference in doing this work on your own and engaging the team in doing it. When you engage the team and come up with the high level plan in collaboration you gain their buy-in in a completely different way. After you have identified the key milestones, discuss who owns each milestone and the detailed plan below it. This collaborative planning session should also comprise a discussion about what the most important risks are to the project, what you are going to do to address them and who owns each risk.
When you get allocated a new project, don’t just start executing the work straight away. At the least you must first understand if the project has a valid business case, who the project sponsor and the remaining stakeholders are, help the team come up with a common set of ground rules, gather all core requirements and create a high level milestone plan that the entire team is bought into.
If you liked this post, you may also like:
Initiating and Planning Your Project, Part I
What makes a perfect Project Initiation Document (PID)?
How to deal with skeptical stakeholders
What you should do in the first month to set yourself up for success
Top Tips for Gathering Requirements
RSS Feed