In my new role as Global Partner Program Manager at HubSpot, I'm involved in a ton of projects. I run quite a few of them as well.
I knew this was going to be the case before I officially got into the job so as with anything else that I'm not a full expert on (yet), I read a ton of literature and did a few courses on project management, including getting Scrum certified.
By doing so I managed to develop a framework for project management that I now use and I have shared with colleagues at HubSpot who have also used it.
I thought it only makes sense for me to share this knowledge with you because I believe that almost every professional runs some sort of a project and so putting a formalised structure around it can only make you more effective and efficient.
Bear in mind that the way I've gone developing this has been from the standpoint of a process or operational improvement rather than product development but it can be applied there as well or any other area/department with some tweaks (even marketing/PR agencies).
Here we go.
Project Management Framework Steps
I've defined six key steps for running projects. We'll go through them in detail below but here's the list.
- Plan the Project's Initial Scope, Time, Budget and First Hypothesis
- Define the Project's Stakeholders with the DARCI Model
- Work Through the Project with Sprints
- Communicate the Project's Results
- Run a Post-Mortem Assessment
- Evaluate the Project's Results & Adoption
Project Management Framework Steps in Detail
1. Plan the Project's Initial Scope, Time, Budget and First Hypothesis
Step 1: Make a copy of this problem analysis template and follow the steps to answer all the questions. In essence, this is your initial discovery and problem definition phase as well as planning and identification of a first hypothesis to solve your problem. A3 will give you a lot more clarity about what the issue is exactly, why it is important, how it can be measured, what some solutions could be and the right people you need to involve to work through these solutions. It will also help you define whether this really is a project or just an ongoing initiative you need to run. (Projects will typically be time-bound.)
Step 2: Speak to the key affected stakeholders about the problem to ensure you have all information needed within A3. These would usually include the person who brought up the issue and the functional leaders of the same department (manager, director) and/or other departmental stakeholders that might have insights (e.g. sales, marketing, product). Ask the functional director if there's someone you should definitely speak to as you are scoping out the problem.
Step 3: Once the real problem has been identified after your research and conversations with affected stakeholders, discuss this with your Project Sponsor to agree on a potential solution and the approach for developing it. You should always have a Project or Executive Sponsor that has your back and can help you get executive buy-in or push people to do the work when something is lacking. If you don't have one, ask your manager who this should be and get their buy-in once identified.
Step 4: Make sure you document all of this thoroughly. You should write down at least the following and make it visible to the rest of the organisation and the involved stakeholders:
- Project Description and Why:
- Project Goal/Objective(s):
- Project Scope (list of activities you need to do to hit the goals/first hypothesis):
- Project Timeline (when the project will need to be completed):
- Project Budget (in some projects, those would be internal resources you need rather than $):
You can always share the full A3 template from step 1 if you feel necessary.
Going all the way, you could put the scope, timelines and resources in Smartsheets or Microsoft Project if you have any of those tools to allow you to uncover the dependencies and which activities are part of the critical path as well as to project manage this. It's important to understand where in your project management triangle (scope, time, budget) you might have to make constraints, optimise, compromise or find trade-offs.
As you go through your project, be mindful of the relationships between scope, time and budget as you can see in the image below:
2. Define the Project's Stakeholders with the DARCI Model
Step 1: Define who needs to be part of this project based on what you've uncovered about the problem, the root cause and the possible solutions within A3 in step 1 of the previous point. This is a very important step as you need to know who you will and must be working with or speaking to - your stakeholders define the success of your project and if you don't have the right people in your room, you won't be able to launch whatever your project is about. I recommend using the DARCI model here:
- Decision Maker(s): This should be a very short list. These individuals have the ultimate and final approval or veto for decisions related to the project.
- Accountable (1 Only): The single person fully accountable for making the project happen. The A must also be given sufficient decision-making power. Do not start a project if the A isn't also present in the D column! There should never be more than one A. This is an invitation to lack of clear accountability.
- Responsible: Those responsible for doing the work on the project. There may be a number of Rs on a project. Rs are responsible for dealing with roadblocks, raising questions, etc. – not just being “good soldiers.”
- Consulted: Those from whom input will be solicited. Note this doesn't mean 100s of people in every meeting. Rather, the decision makers should make sure they've consulted with people in their area of the business and can speak on behalf of this group of individuals.
- Informed: Those to be kept apprised of relevant developments. This is an FYI role. NOTE: Is may not use the information to undermine the process. Unless someone is officially an I, consider not cc’ing them on emails. This is a good way to cut down on unnecessary emails.
Using a table is usually best to visualise this.
| Decision Maker(s) | Accountable | Responsible | Consulted | Informed |
|
Person 1 - Team/ Department Person 2 - Team/ Department Person 2- Team/ Department |
Person 1 - Team / Department |
Person 1 - Team/ Department Person 2 - Team/ Department Person 2- Team/ Department |
Person 1 - Team/ Department Person 2 - Team/ Department Person 2- Team/ Department |
Person 1 - Team/ Department Person 2 - Team/ Department Person 2- Team/ Department |
Step 2: (This step is key!) Communicate this table out to everyone you've identified and ask them (via email or a meeting): "Here's what the project is and its scope, why it's important and how I think the roles and responsibilities should work for this project. Are you in the right place? Do you agree with the goals and action items? If not, please let me know by (date)."
Step 3: As you go through the project and you hit key milestones, be sure to actually inform the list of people in the informed column, along with the other stakeholders you've identified, of your progress.
3. Work Through the Project with Sprints
After getting Scrum certified and evaluating the framework, there are some things that I felt could work in the HubSpot world of my department. I took the most valuable pieces and what I believe would help us run projects efficiently, quickly and with as little friction as possible within my team to ensure that we hit our goals and are able to focus.
But if your whole company can adopt Scrum, that is certainly something I recommend looking into. (More about Scrum here.)
The following steps tell you what you need to do and the table below sums it all up so populate it as you go.
Step 1: The A person from your DARCI model to define how many sprints you need to complete the project within your timeframe. A sprint is a time-boxed event (e.g. one week, two weeks, one month max) with the goal to deliver a "shippable" result. For example, if you are building a software tool, think about whether you need Alpha and Beta versions before the Launch - in this case, you have three sprints with three different goals. Explaining this in product-development terms first is easier than when we speak about process change so here's your sprints framework for when you are designing a new process: discovery & definition, design, test & optimisation, roll out & communication, ongoing adoption & measurement.
Step 2: The A to define the backlog (or work breakdown structure - WBS) for the first sprint. This is a list of everything that needs to be done to hit the goal of the sprint, e.g. have an Alpha product, and a lot of this can be taken from the A3 from the very first step at the top of this page, however, here you are aiming for an exhaustive list now that you've spoken to many of the stakeholders. Ideally, you'll document all of this somewhere in Excel/Google sheets, Smarsheet or Microsoft Project any other project management tool.
Step 3: The A to run an initial planning meeting with all Ds and Rs to agree on whether the backlog makes sense (and add or delete items if necessary), define priority points for each (choose between 1,2,3,5,8,13,21&34 from the Fibonacci numbers as this will help Rs prioritise items and plan execution better), pick who is going to take care of which backlog item (Rs) and by when (deadline). Arrange all backlog items in a logical time-based order. Make sure to plan at least another 10-20% of total points as a buffer.
Step 4: The A to schedule daily or weekly (depending on the sprint's length) Scrum meetings with the Ds and Rs for the duration of the sprint so that the people involved can update each other on progress. The status of the backlog items needs to be updated during this time (or as people tackle issues if they can remember to do this) in terms of Planning, In Progress, Complete as a status update. This way you can track progress quite nicely in your Excel sheets, Smarsheet or Microsoft Project or project management tool where you have all your backlog items from step 1.
Ds and Rs are responsible here as they see fit to discuss backlog items with Consulted and update or do changes as they go as well as to test.
Step 5: The A to schedule and run a sprint review with the Rs and the Ds at the end of the sprint to evaluate results, discuss with the group what worked well and what didn't and plan the next sprint.
Step 6: Repeat the above for each sprint.
Step 7: Once your project is complete, the A to meet with the Ds and Rs to discuss the results and how you want to roll out this change. This links well with the next big step around communication.
4. Communicate the Project's Results
Once you are happy with the outcome of the project and all sprints, update your project's documents with the results, if needed write a new article for your intranet and share with the relevant stakeholders. In essence, this is a separate sprint but is so key so that we have it as a separate step to be mindful of (along with the next one).
Depending on the scope of the project, agree with the Ds and Rs if there's a need for an email update to the whole org or particular teams and whether this needs to be communicated during any meetings.
The easiest communication framework you could use is Why, How, What and TL: DR at the beginning.
5. Run a Post-Mortem Assessment
A retrospective of how the project went is essential to continue learning and ensure that the next project is even more successful. Reviewing what worked well and what didn't, writing it down as a short summary and/or meeting with the people involved in the project will allow you to share learnings and ideas for improvement. In addition, if it's published on a shared company intranet or resource, it will allow others to learn from your experiences too.
At this stage, you would usually want to evaluate the key project aspects: scope, time, budget and how your project tracked against the bets you made in the beginning around these.
With some projects as mentioned earlier, budget would not necessarily include a sum of money but internal resources such as a designated designer and how many hours they will need to spend on this project etc. Time tracking in this case, especially for agencies, is crucial.
6. Evaluate the Project's Results & Adoption
We often get too excited when we launch things and get into our daily routines so that we forget to actually evaluate whether the rolled out changes, processes or products are being adopted (globally, cross-functionally and optimally). This step is essential to ensure whatever your project and its results were are accepted and implemented well, and if something is broken, this would allow for identification and fixing.
Use a separate sprint for this step and add monthly/quarterly reviews as a backlog item which would ideally be a meeting with the Ds and Rs to assess how things are progressing, what's working and what's not until you're comfortable with adoption.
And that's it - now rinse and repeat.
Here are also some recommended resources:
- Terrific free course on project management
- Fantastic ebook on how to excel at project management
- Blog, ebooks and tools from Project Smart
- Why do projects fail blog and resources
How do you run projects?
