In my last post I looked at the importance of lists and used an example of a project initiation checklist. Naturally, I wanted my next post to follow in logical and chronological order.
After project initiation comes project setup, so I thought I’d get writing again and share a method of 'project framing’ which we ran recently with a major UK travel provider. The method proved to be an extremely useful part of the project set up, time efficient, and massively helpful in reducing any ambiguity in those crucial early stages.
The contract has been signed, the initiation checklist checked, and you’re all gathered in a conference room with coffee and pastries, ready to kick things off. And the senior stakeholders promptly leave the room (if they had even entered it in the first place). In my experience that’s pretty standard. It makes sense, right? The decision making around embarking on the partnership has been made, so everyone can just crack on. Sound familiar? So far so good.
Ordinarily, when the original brief came in, there will have been a load of back and forth around “deliverables”. The same old questions come up time and time again: “What exactly am I going to get for my money?”; “When will I start seeing value?”. Rightly so, and justifiable from a client’s perspective.
A good agency won’t be in a position to answer these questions in detail immediately, so will begin with responses around time and materials and immersion weeks. (It’s worth noting that partners who suggest they have all the answers and a pocket full of silver bullets from the off are the least likely to deliver both fast and long lasting business value.)
In some cases, this (sometimes) perceived lack of clarity can often bamboozle the senior stakeholders until they get to the point where they greenlight the project and handover to an internal team to deliver, who might understand the approach better.
Then, stealthy as you like, disaster strikes! You’re a few weeks or months into the project and rumblings of confusion and ambiguity are felt in the room. And it turns out that those rumblings set in when they snuck their way through the door left open by the departing senior stakeholders straight after that initial green light. ‘Disaster’ might sound a bit dramatic, but make no mistake, when ambiguity sets in, it becomes a big threat to the value the project will deliver to the client, regardless of the skills and experience in the room.
Fast forward to when the senior stakeholders reappear at first playback, or perhaps even at the end of the project. By this point, a whole host of decisions have been made by the project team and the original goalposts have shifted so much that the senior stakeholders are left puzzled at the output.
For me, this is a failure and should be avoided at all costs. If those who hold the purse strings are not confident on the deliverables, what chance do you have on securing future work?
There are a ton of blog posts out there telling you that ambiguity is one of the leading reasons for project failure. There are also a load more offering tips on how to avoid it, as well as a whole bunch of posts devoted to suggesting that using an Agile methodology can actually cause ambiguity. This last point is of little surprise, especially if you’re a small agency working with a large corporation with too many stakeholders, most of whom are used to working in a traditional Waterfall method.
Never fear, there is a solution. Address these ambiguities early,with the right people, and you will ensure that everyone is on the same page from the off.
In the introduction above I mentioned that we used a particular approach to project framing with a recent client, and to great effect. During our Kickoff we sought to try and nip the ambiguity possibility in the bud and involve the key stakeholders and project sponsors in discussions around the approach and logistics. Interweaving these discussions with the big picture questions allowed us to address the often overlooked minutiae that lead to senior decision makers being kept in the dark.
We sandwiched these discussions in between two parts of the project setup: setting the project goal and looking at the KPIs. The approach that worked for us involved splitting the conversation in to four key areas; I’ve listed them below with a brief summary of the questions to ask and what the outcome should be.
This is the most important one and it should be handled with care - we are not trying to force ways of working, rather coax an approach that works for everyone. This may at first be unfamiliar to the client, but with the right guidance, a shared understanding can be easily achieved. In this instance we were hoping to run the project using a scrum framework. As a team, start by answering the following questions:
The key here is to identify who’s going to actually do the work and who will be needed from the client on a more regular basis. This is the time to establish a product owner and ensure they understand their role in the project. Answer these questions:
You need to all be clear on who you need to keep updated on progress outside of the meeting room. There are a bunch of RACI (Responsible, Accountable, Consulted, Informed) exercises that can help with this. This will help back up the conversations around the team and highlight the roles of the stakeholders and what you expect from them as the project progresses. Ask yourselves:
4. Communication channels and tools
What tools does the client currently use? Are there any IT restrictions we should be aware of? Having a senior mind in the room really helps with this, as they are typically au fait with the restrictions in place. Answer these questions:
When we did this with said recent client, each area was either a discussion or a small exercise with the aim of everyone agreeing on and answering the questions. By the end of the session, not only had we agreed on the vision and goal of the project but we’d also framed the logistics and roles within the wider team.
Involving the wider stakeholders allowed us to get a little creative about our ways of working. For example, it was suggested that we keep a private blog to document the work in progress which can be shared across the business, giving everyone of all departments a flavour of what we’re up to. This is exactly the sort of thing that can normally be overlooked by a core project team who are mainly focused on achieving sprint goals or working through a backlog.
We were also able to fast-track some of the, often time consuming tasks, such as finding desk space and ensuring we had building passes. These little (annoying) things often need senior stakeholder sign off which, once a project is underway, can take a while.
Yes, there is an argument that the small details should be kept between the core project team, because senior stakeholders don’t have the time to go in to the nitty gritty, but I say “NO!”
The nitty gritty is what helps clear the path for the big picture and nip any ambiguity in the bud before it takes hold.
Too often we shy away from inviting senior stakeholders to these kinds of meetings out of fear that they are too busy or it’ll be a waste of their time. Yes, they are often too busy, but no, it’s never a waste of time.
The key to getting this right is to keep it collaborative. Remember, from an agency perspective, you’re not forcing your ways of working on the client, you’re guiding them and easing them in to an agile way of thinking. By suggesting approaches and tools that help enforce these ideals, and compromising on areas that they are rigid about, you’re strengthening that partnership, which will help achieve better outcomes.
Senior stakeholders are the people that commission the project, so why keep them in the dark?
We’re keen to hear your thoughts, ideas and tips around project management - tweet us @clearleft- we’d love to hear from you!