How do you start a project effectively?
By understanding what problem you are trying to solve.
This was previously posted on my blog.
I was once involved in a project to roll out a new system. I had lots of questions to clarify and points to understand, but the executive in charge wasn’t interested.
Instead, gantt charts of devastation were created that were the size of a small Dev team. Work was pushed down and deadlines were made up on the spot in board rooms rather than with data, insights or buy-in from those in the know.
Every day the stick would come out and humiliation based management would prevail.
Why have you not delivered yet? Why don’t you just follow the plan? If you’d just complete the actions we can say we’ve done it. Just do as you’re told. It doesn’t have to be right, it just needs doing.
Well, it wasn’t that easy.
The work was cross-functional, we had no idea where we currently stood with the process we were replacing. We had no idea how we were measuring the success of the project – according to the exec it was little more than the gantt chart actions being completed. The plan was also set in stone and the tool of choice was already decided. The tool didn’t do what the exec had promised and the underlying problem this solution was supposed to solve didn’t actually exist. There were problem, but they weren’t acknowledged in the plan or used to drive a solution. A mess.
Sadly, this is how many projects run and some people may have some success with following an incorrect, uninformed plan with few measures of success other than ticking a box somewhere. That doesn’t work for me. Following a bad plan, failing at delivering and being hit with a stick is unlikely to be a good career move.
So we quickly went back to basics and used the ideas from the following framework to get clarity. To work out what the purpose was. To work out what problem we were trying to solve. In the end it rolled out and solved a few problems. It was late (but then that’s what happens when commitments are made on nothing but a guess). There were also some tough conversations and stubbornness on my part in moving forward with incorrect assumptions and data. But slowing down and understanding what you’re doing is essential to deliver value, reduce costs and not waste time. It’s also essential for fulfilment at work – delivering something you believe in.
Have you ever worked on a project like this and not known what the goals are?
- Ever started building software but not known why? Or who it’s for?
- Ever engaged with a customer on a project and not had enough detail to get started?
If you’re ever in this situation maybe the following framework can help you take stock and get clarity.
The following framework is a collection of ideas from the many years of running Dev and HR teams and launching projects; software projects, management projects, new initiatives, personal projects, hiring revamping and now my own consultancy services.
They are all the same – they are projects that need shipping and require knowledge about what problem you’re trying to solve.
In the Dev team it became a running joke. Every meeting would start with “What Problem Are We Trying To Solve?”, but the joke stemmed from a deep understanding that more critical questioning at the start of a project, meeting or plan contributes to faster and more effective delivery.
It’s a bit of a myth about agile that it’s all about just cracking on and experimenting with no planning. Not in my experience. When I build agile teams we slow down, we take our time, we discuss and ensure we have clarity and then we move rapidly.
Here’s how to get that clarity.
Step 1 – Get Knowledge
The first step is to get knowledge so you can collectively agree on what you’re doing.
- What problem are you trying to solve?
- What are we trying to achieve? (i.e. what does the future look like?)
- What is our purpose? (Why are we here and how do we add value?)
- What are we assuming or presuming? (Do we have facts around everything or is it just opinions?)
- What are we predicting will happen? (Management is all about prediction. As is estimation, scoping, planning – all predictions of the future)
- Do we have a strong business case? (Are there some tangible, measurable values associated with this?)
- Do we have support from the right people? And the right budget?
- Do we have all of the right people in the right places? (Any skills/experience/people we need? Do we have any coasters who aren’t adding value?)
Step 2 – Clarity
This stage is all about gaining clarity.
The acid test – do you feel comfortable presenting the plan to a wider team with clarity and passion?
- Can we articulate our strategy simply and without jargon?
- Can we explain what success looks like, or at least have a True North?
- Can we explain how our people will contribute to this success?
- Will our teams be emotionally connected to this? Is it powerful enough? Is it compelling enough?
- Are we ourselves visibly passionate about this? If not, why not?
- Do we believe in it? Do we think it’s doable? If not, why not, and what can we do?
Step 3 – Measures
This stage is all about deeper measures. It’s important to define measures at step 1 and 2 also, but I break this out as a distinct section to spend time talking about, defining and communicating measures.
The measures need to be communicated and owned by the very people who can influence and change them through doing good work. The measures need to be used by the team to improve, move forward and learn. This is hard to do if the measures are never communicated and are at the wrong level in the business.
- What does success look like?
- What are we measuring?
- What are we not measuring and why?
- Who owns the measures? What are they doing with these measures?
- What data do we have?
- What data are we missing that we should have?
- How much does it cost to measure this data?
- How reliable is that data?
- What trends do we see? (Trends are often more informative than single measures)
There will be deep discussions in this section and be sure to define the measures from the customer’s perspective.
Also be careful about setting targets. Targets often drive the wrong behaviours.
Step 4 – Experiments
I call this section experiments as that is what creative and innovative work is all about, but some execs, managers and clients may not like the word experiments. Substitute this with initiatives or tactics if you like.
These are the actual options that we have in order to fulfil the purpose, achieve what success looks like and have measures moving in the right direction. At this stage you’re planning how to ship and what to ship.
Experiment, initiatives, tactics, work – call it whatever you like – these are the plans, next steps, milestone, moves, backlogs, etc.
This section is all about your path to production and how to Ship. No shipping, no feedback. No shipping, no payment. This is all about getting results. How do we move forward?
I would never plan too much in this section. Instead, set milestones and dates for review. Plan the next month, fortnight or week. Get to the next location and see what options are now available. You know the main direction, now you need to see the lay of the land. It’s all about shipping and getting to the next step – all within the measures of quality that you define. In a nutshell, this is agile. Have a direction, plan enough, have a next milestone, adapt where needed – remove friction.
And with that – here is the handy diagram taken from my consultancy service.
It is hard to get clarity, and asking questions like these is sometimes not enough. You’ll also need good facilitation skills, excellent communication skills and a team bond that allows these tough conversations to happen.
Setting off on a project or implementation based on assumptions, hot air and opinions is a recipe for a problematic project and disappointed customers.