A new project starts with a slide deck. We’ll think about the details of our problem, come up with a solution and present a high-level plan. The board agrees and a budget is allocated. Let’s go!

There’s a business case with clear goals. We’re doing feedback-driven Agile software development and our management is Prince2 certified. There are strict reviews and controls, right? Right?

The truth is, once a project starts, we tend to get a bit more lenient. A bit too lenient.

We’ll do planning meetings where we carry over stories from the last sprint. The project manager will present a status report that’s a bit biased to make sure the stakeholders pay attention to the “right” problem. Months will pass and we’ll lose ridiculous amounts of time and money on hardly anything.

Sounds familiar?

What we’re missing is the magic ingredient: Focus.

Focussed teams don’t get lenient. They can’t. They are dedicated to getting their project done. They are not working on the urgent while neglecting the important.

The key to being focussed is knowing what to focus on and then actually doing that. Sounds simple, but most companies don’t seem to do this. Most project teams know the solution they need to build, but are clueless about the problem they need to solve.

And that’s where the opportunity lies. Each project has a problem to solve. A mission. A goal. Only one goal at a time.

“We’re trying to IMPLEMENTATION so we can OUTCOME by DEADLINE .“

There are four parts to the goal.

First off, there’s the word “trying“. It’s an experiment. We’re not sure this will work. That’s part of the Lean approach. We’ve accepted that this is an attempt that can be adapted and revised if the results are not what we expect.

The second part is the Implementation. It’s a high-level solution. It’s the thing we are going to build in the hope of fixing our problem. This will impact which skillsets we’ll need on the team or which vendors we need to contact.

The next part is the Outcome we wish for. It’s the lens through which we’ll look at our solution. It has to consist of measurable, hard numbers.

The last part is the Deadline. This can be a fixed date or a quarter. That’s the time when the outcome is achieved, not the deadline for the project!

“We’re trying to build an e-commerce site so we can increase sales by 15% by Q3.“

“We’re trying to redesign the onboarding page so we can convert 200 new visitors by June.“

“We’re trying to migrate to AWS so we can cut costs by 30% by October 1st.“

With this goal spelt out, your planning and status meetings should go a lot smoother. Instead of discussing abstract and meaningless things like velocity, Story Points or “percentage done”, you can answer these questions:

Are we closer to the Outcome? How do we measure we’re on the right track? How much of our time did we spend on things that do not contribute directly towards the Implementation? Why is that? At this rate, is it still feasible to get the necessary feedback before the Deadline?

If the answer is positive, keep going. Often, the answer will be negative, or worse: We don’t know. In that case, we’ll need to refocus on the goal. How can we quickly get feedback that allows us to verify that we’re getting closer?

We want to be in a position where the team will push back to tasks that don’t add to the goal.

“Sure that bug in the reporting tool is annoying, but we are focussing on the sales funnel now.“

Having focus means saying No to anything that doesn’t add to the goal. That’s hard in an organisation that has a firefighting mentality. If your team is putting out every fire you throw at them, they won’t get anything done.

They need to work more on the important stuff and less on the urgent. A written goal gives them the mandate to do so.