Starting Strong: My Top 3 Tools for Any New Project

I’m building all my knowledge and experience into a set of templates and processes to help people run projects better. I thought I’d start at the beginning: thinking about a project from start to finish and building the artefacts and processes in the order in which they’re likely to be used. So, what order is that?

I think it’s subjective for everyone. We all have our own preferences based on our experiences, where we’ve been stung before, and what we’ve been taught. We also adapt our preferences to the environment and context in which we’re operating. Certain projects or environments call for processes or artefacts to be done earlier than others. Despite that, everyone I talk to still seems to have a preference, a go-to kit they like to pull out. Let me know your top 3 in the comments. Here are mine and why.

Scope

I always start by trying to understand what system or behaviour change I’m expected to deliver.

To me, this is a level below benefits. I like to have clarity on what I’m accountable for and why it’s important. This helps me stay focused and be clear on the things that matter to the organisation. I elevate the conversation beyond just the solution I’m being asked to deliver. In the past, I’ve been stung by delivering exactly the solution requested, only to find it didn’t deliver the required outcome. Today, this is my first priority when starting a new project. By focusing on the outcome rather than just the solution, it allows for creativity and flexibility in how the solution is delivered. I think teams like to have some control over their destiny, and focusing on outcomes rather than solutions fosters this conversation with the new team.

Equally important in this discussion are the things that are out of scope. I document the scope and get it approved by the sponsors, sharing it widely with everyone on the project. Knowing why we’re here is my number one go-to.

Authority Matrix

Once I understand the scope, the next thing I focus on is defining decision-making rights—what decisions I have the authority to make and who holds authority where I don’t.

Many of us in the world of projects are natural problem solvers. It’s in our nature to tackle challenges head-on. But if I’m not authorised to solve a particular problem, I need to know that. I need to understand the boundaries so I don’t overstep them, so I can understand which tools and techniques I should use to deliver the project, and so I get an early indication of the organisational culture. Documenting decision-making rights gives me insights into all of these things early on. It also helps prevent conflicts down the road.

Being clear on my decision-making rights also helps me set expectations with the project team about what I can and can’t do for them.

Pre-Mortem

The final of my top 3 is the pre-mortem.

Most of the time when I’m managing a project, I’m the least informed person in the room about the subject matter. I might have the most project management capability, and I have good leadership skills, and I’m confident I can deliver the outcomes—but when it comes to the specifics of the project, I’m usually the least informed. Most of the team will have been working within the system, the organisation, or the subject area for much longer than I have. A pre-mortem is my way of tapping into their knowledge, fears, concerns, and expertise, and immediately putting that to the benefit of the project. It’s my way of saying, “Tell me what I don’t know,” and bringing that valuable input to the surface early.

A pre-mortem also helps me gauge the dynamics of the team—who are the doomsayers, who is sharing insights to be helpful, and who are the quiet ones I need to encourage to speak up.

Of course, there are situations where these wouldn’t be my top 3, as it always depends on the context and project. But as I start a new project, these are the things I’m thinking about and seeking clarity on early. What are your top 3, and why?