Finding Clarity Through Context

Meaning, just like a melody, is carried in the spaces between things, as well as the things themselves. Understanding the context of projects allows people to see the space between requirements, objectives, goals or what ever else we’re using to communicate the work needed. This helps them see the true shape of work.

Missing context is common. Sometimes from the beginning of projects, but even more commonly the closer to the ‘coal face’ you get, but It is invaluable for decision making. From early design and approach considerations, right down to ad-hoc development decisions or prioritising test cases, the speed and quality of these decisions can be greatly improved by context. What’s more, team members who understand the full context of projects are more motivated and more able to spot issues or see opportunities.

What goes into providing great context? And what is enough?

Think about building out two things at the start of a project:

• The vision of the goal – a context rich ‘to-be
• A model of the whole – a really broad ‘as-is

With a clear Vision of the goal, complete with it’s surrounding business context, we can agree and share a successful project *end-point. With a detailed model of the whole, complete with technical and business context, we can understand both the landscape we are working in, such as compliance or customer expectation, and our start point from a data, process and technology point of view. With these two clearly defined, and shared amongst the full project team, charting the optimal journey from one to the other, is infinitely easier.

* It is also super helpful to build early context around delivery and longevity expectations – how fast are we hoping to get to our end state, at what kind of budget, and is this a quick fix / toe in the water or a strategic deliverable for long term use?

This may seem like a lot, but it can often be covered in a few paragraphs in an RFP or project summary, or 10mins of the kick off call. And if it can’t, it can be a sign that work needs to be done to clarify those things, and get the stakeholders aligned.

When this kind of broad, rich vision of the goal state is provided, it is infinitely more meaningful and easier to work with. Requirements within it ‘come to life’; further analysis can more targeted, and numerous solution and approach options can be taken off the table as unsuitable. What’s more, both potential pitfalls and opportunities are easier to identify, and the whole project team can be on the look out for them.

How do we build a complete Vision of the Goal?

Start with Why.

Capturing Why our goal is desirable tells us more about it than almost anything else. It enables us to validate that the project deliverables really are going to give us what we want once we reach them, but also provides a vast amount of information around the goal that will help drive out detailed requirements for the project.  

Take the example of a Beach Trip. If I say ‘I want to go to the beach’ I am likely to have a lot of ‘obvious’ assumptions in my head.. but they are far from explicit in my request.  A helpful planner could arrange me anything from a one off family picnic to an annual week’s research trip for 30 undergrads!

But if I say I want to go to the beach to surf, we are infinitely closer to a successful outcome in a very small step. What’s more, my planner knows a lot more about how to go about getting me closer still. If I want to go to the beach to surf, they know they need to target a specific type of beach, in the right weather and tide conditions. And they know to ask me about my skill level and expectations for surf conditions and amount of challenge.  

Capturing ‘Why’ will also make sure I arrive there prepared. My helpful planner now knows I need to arrive on a beach with a surfboard, perhaps a wetsuit, and maybe even a surf instructor or lifeguard. They can direct specific requirements questions far more accurately from this small bit of context.

For businesses, the goal of ‘moving into the cloud’ might be because they expect to need to scale significantly to support a new global customer base, it might be to improve resilience and availability, or it could be a means to an end of reducing internal IT efforts and move towards managed services. The ‘Why’ helps us instantly understand what’s important to deliver when we get there, ‘the Cloud’ alone, wouldn’t necessarily guarantee the outcome they want, but if we know why they want to be there, then we can make sure it does.

What’s more, there may be multiple ‘Why’s’ across the stakeholders. In our example of a Beach trip, if we have a family beach trip with multiple stakeholders with different needs then we might need to support surfing, sunbathing, sandcastles and a donkey ride, and it’s very helpful to know that as early as possible so we can find a solution to make everyone happy!

Understanding assumptions or exceptions around When, and At What Cost.

These are also incredibly valuable in finding the right strategic approach and roadmap. Early understanding of these aspects of context can help our ‘Planner’ understand what kind of quality and expediency we’re expecting – If I can give my planner an idea of budget & timelines for my ‘surf trip’, they can get a sense if I have tropical surroundings and Michelin star snacks in my vision as opposed to a windy Cornish coast and a flask of coffee, or vice versa. They can also quickly understand if I’m hoping to go next weekend or next summer.

Finally, the ‘Who’ / ‘What’ is key, and not just a persona or two, or some sample data, but volumetrics. A ‘beach trip’ for a family of 4 is not going to be suitable for a school trip of 30 or vice versa. And is this for a weekend, the whole summer, a lifestyle change & house move? Are we surfing once for an hour, or 24 hrs a day in shifts of 5 at a time? You get the idea.

For our cloud migration we need details of data volumes, user volumes, patterns of use. Ballpark numbers to use as a guide are absolutely fine early on, and make massive differences to early thinking, and recording and communicating usage requirements to the project team throughout the project lifecycle also means that context is kept and used in the day-to-day decision making of the project.

So that’s our Vision pretty well Defined:

Beach Trip’ for 2 adults, strong & experience surfers, wanting a weekend break to get some serious surfing done (4+ hrs each day), but drive-able from London, on a tight budget, next weekend.

Model the Whole

Where are we now? And what do we know about our goal, our objectives, and the space we’re operating in right now?

Once you have a clear goal, the next thing to do is to understand your start point. This might seem obvious, but often organisations don’t want to talk about what they have, but like to focus on where they’re going. Or sometimes they do want to talk about what they have, but a specific part of it they have concerns about or a desire to keep. The key objective for context gathering here is breadth.

In our example – have I already got a holiday home on a surf beach? Have I got a camper? surf gear? sleeping bags and a first aid kit? do I have cooking facilities or know great pubs in the area? Do I have kids and need someone to watch them?! All that context massively informs what needs to be done to get me and my partner to my perfect surfing weekend….

It’s still not enough..

Finally, we want to gather everything we know about the current state of the ‘goal’ .. i.e. what do we know about beach(es) and surfing? Do they need permission to be at or surf at a certain beach? Or inform anyone of where they’ll be surfing for safety? Are their seasonal tidal risks? Can we get recent pollution reports? Do they currently visit any suitable beaches frequently or have a great recommendation already? Do they know anyone like them who has done a similar trip before?

For an organisation about to embark on a change, this kind of context gathering is building an early picture of our ‘as is’. Not just the data, technology and process ‘as is’, also the state of our industry, compliance commitments, historical forays we can learn from and competitor analysis. Anything that might better inform our project team and the myriad decision makers that make it up.

Building this information up into a single ‘model of the whole’ enables us to validate it, an communicate it more easily. This part of our context setting is great for targeting the next phase of analysis, and understanding which kinds of areas we’ll need to cover, in particular with regards to legal, regulatory or compliance requirements.  

Now we should have a fairly rich Vision of our Goal, and an accurate Model of our Whole. We need to weave these into into an output that is easy to validate, communicate and comprehend.  Once it’s sharable, we can use it to quickly:

• Unify the goals of your stakeholders
• Solidify for the full project team what success looks like
• Right-size our thinking re solutions and project approaches
• Devise accurate roadmaps to get us from our current state, to our desired outcomes

This output is fantastic for project leadership teams, but is equally valuable to share with the implementation team, and any new team members joining a project – it can make the project ‘come alive’ for them, and turn them from Devs, into informed decision makers who can contribute to our outcomes to the full extent of their, often considerable, abilities.