By Richard Smith | October 2, 2018
Learn how to find your stakeholders, determine their real needs, and identify at least one thing you could actually deliver to someone to make their lives better within just sixty minutes! You will also start learning about some highly effective techniques for requirements analysis and design evaluation that are useful on any type of project.
The idea is to challenge yourself (and your team, if you have one) to come up with at least one small improvement you can actually deliver to one of your key project stakeholders in a very short timespan, say within a week. You will do this by quickly following a series of simple carefully-designed mini-brainstorming sessions, set to a strict timeframe, to help make sure you have time to complete the most important last step!
I invented this little exercise whilst lecturing alongside Tom Gilb at a requirements course held at the BCS in London in September 2018. The willing participants split up into four small groups, working on their own project ideas. One of the teams came up with two novel quick win ideas; they told me later in the week they had decided to go ahead and do them. One of them said “Why didn’t I think of that before?”. I believe it was because they had just gone through this exercise, focusing on the real needs of their stakeholders.
All of the steps described below map onto very detailed value planning and systems engineering concepts and processes described in Planguage, and supported by Needs & Means. If you know something about those already, great! That will help you understand what you should be focusing on for each step. If not, don’t worry, just go with the flow and see what happens. At the end of this post, you can find out what you can do next.
Enough! Let’s get started…
What You’ll Need
A known project or problem to work on.
Post-It notes or similar
A board or wall to stick your notes on. A whiteboard you can write on too is even better, because you can quickly draw the chart outlines (see below)
A stopwatch, or clock
(optional) A camera to record your progress as you move notes around (particularly for the chart steps below!).
Pre-prepare the two simple charts shown below in steps 3 & 9, so that you can move your post-it notes or cards onto them without interrupting the flow of your thoughts. Write them onto flip chart pages or just large sheets of paper. Or draw them on a whiteboard.
The challenge is a series of short, targeted brainstorming sessions, with a couple of evaluation steps (using the charts). So, all the normal rules for effective brainstorming applies here: Keep the ideas coming, shut down discussions, and keep an eye on your stopwatch.
Each of the steps is equally important, so do try and stick to the suggested times. It doesn’t matter if you leave a trail of other potential ideas to explore behind as you do. In fact that’s great, as you can decide to re-run some of the later steps at another time but focusing on a different stakeholder or need.
At the end of each step, declare that the task is done to everyone, and then move on to the next task straight away.
Step 1 - Your Project
Write down the name of the project and / or a single sentence summary of the problem that you want to work on.
Step 2 - Who Cares?
Identify who is in charge and sponsoring your project. Then think about everyone and everything else that has some interest or might be affected by the outcome of the project in some way. Quickly write each down on a separate note or card.
Planguage defines a “Stakeholder” as any person, place or thing that has some requirements, directly or indirectly, for the results of the project. Together, they determine the degree of product or system success or failure.
Step 3 - Influence / Interest
Now, place each of your stakeholders somewhere on this chart, rating each against the two criteria below:
Influence: how much direct influence will they have in shaping the results of the project? How much priority will their own requirements have over everyone else?
Interest: How much will they affected by the success (or failure!) of the project? How valuable will the project benefits be for them?
This is a prioritisation exercise, to find stakeholders that can make or break the success of the project (high influence + high interest). Planguage calls these “critical stakeholders” … all of their must-have requirements must be satisfied before those of anyone else. You can also identify any risky stakeholders (high influence + low interest) which you may need to engage with more so you don’t get any nasty surprises near the end!
Step 4 - What do they do?
Focusing on any high influence + high interest stakeholders you identified in the previous step first, quickly identify and write down what is it each of them do (e.g. are responsible for) that is relevant to your project or problem. Imagine they only had access to “a pen and paper”, what jobs or roles would they still need to carry out? Try to find at least one thing for at least two or three of your stakeholders.
You may want to move your stakeholder stickies off the chart as you work on each one … you will associating a number of additional notes to each one in the steps ahead!
Identifying and understanding all of a stakeholder’s relevant “functions”, as distinct from the means (systems, processes) by which they achieve those things, is an essential step in ensuring your project does not miss any critical requirements.
Step 5 - What needs to be better?
For each of the functions that you identified, consider what is it about that function that the stakeholder wants to be made better (faster, more robust or secure, bigger etc). Words describing things that vary or change over time, or “qualities” ending in “…ility” come up a lot here.
Again, don’t focus on “how” to make it better. If you can only think of solutions or system enhancements, ask yourself “Why?”. Why is it they have asked for a particular service or system improvement?
Identifying Stakeholder “Values” is a key concept in Planguage and value planning. Often, these are called “non-functional requirements”, but are actually much more important to understand than “function requirements” to ensure the success of a project. Planguage takes this much further than we cover here, by re-writing values as numerical “scales of measure”, but the idea is the same.
Step 6 - What is it like now?
For each quality or thing that needs to be better, try to write down a very brief description of what is it like now. Try to give real examples of how the current situation affects the relevant stakeholder(s). Here, you are still focusing on the stakeholder, not the “system” or what is delivered from your project.
Planguage refers to this as the “Status” level of an identified “Value” requirement. It tells us where we are now in relation to where we started from (the “Past” level) and where we need to get to (the “Goal” level). In Planguage, this is expressed as a number along the Value’s “scale of measure”.
Step 7 - How much better?
Alongside your descriptions of what the situation is now, describe how much improvement they need in that value by the end of the project (or any other times in between now and then). It might help you to imagine travelling forward in time to the end of the successful project … what would the stakeholder experience differently if the improvements have actually happened?
This initial expression of the desired amount of improvement is called a Value “Wish”. In Planguage, this is expressed as another number along the Value’s “scale of measure”.
Step 8 - Improvement Ideas & Restrictions
Finally, you get to work on how the project might achieve some stakeholder’s real valued needs. Focusing only on the Values and desired amounts of needed improvements, brainstorm some ideas that the project could deliver that might make these improvements actually happen. Be creative! See if you come up with some new ideas, because you should be thinking only about achieving the amount of improvement required by someone, rather than a typically narrow focus on “functional requirements”.
At the same time, think about and write down anything that significantly restricts what kind of solutions you could actually complete by the end of the project (mark these with a “*” ). E.g. existing systems, legal, management - imposed deadlines
Planguage uses the term “Solution Idea” to describe any strategies, systems, processes or tasks that may make some improvement that a stakeholder would value and want. The most interesting and valuable Solution Ideas are those that target improving the performance or quality of something that a stakeholder has to do.
Any restrictions that are imposed on the project that effectively say “You are not allowed to do that” are called “Constraints”. It is essential to check that all of the solutions delivered by a project do not break any of these!
Step 9 - How good?
Place each of the improvement ideas from the previous step (the ones without the “*“) somewhere on the this chart, rating each against these two criteria:
Effectiveness: What might be the impact of the idea on achieving the stakeholder values you have been considering? Rate these on a scale from “not effective at all, or make things worse!”, through “just good enough”, “good / acceptable” and maybe even up to “awesome!, exceeds expectations”.
Cost: Give a rating of the total cost of delivering the idea to your stakeholders including everything (e.g. time, money, people, good will etc). Try rating between “Low”, “OK, within our budget” and “Too much!”. If you have no clue here, assume “Too much!”.
You may have difficulty in deciding where to place some of your ideas on the chart, possibly because they represent a larger complex idea that has many facets and components. Don’t worry too much, just try to think about the relative impact of that idea vs the other ideas.
This is the crucial step in Planguage that makes it a true “engineering” approach. Engineers systematically estimate the likely benefits vs costs of designs or strategies before committing to do them. Planguage describes a whole set of powerful, simple methods & tools such as Value Decision Tables that allow any team to do the same.
Step 10 - What can we deliver next week?
Look at the ideas on the Effectiveness vs Cost chart. Find the best ideas to work on first (those that have the highest effectiveness for the lowest relative cost), by working diagonally down the diagram from the top left-hand corner to the bottom right-hand corner:
For each idea in turn, challenge yourself and your team to figure out something related to that idea that your project could commit to delivering really soon, like, by the end of next week. It must be something that:
- Is low cost (because you only have, say a week to complete it in)
- Provides a small but real (measurable) improvement towards one of the Value goals of at least one stakeholder
- Is actually deliverable (i.e: released, published etc) to a real stakeholder, not just implemented or coded.
Decomposing a bigger idea into a series of smaller chunks of “value delivery” is one of the core ideas of the “Evo” evolutionary value delivery method invented by Tom Gilb, which pre-dated “Agile” by 10+ years. It is probably also the most difficult to learn how to do effectively and repeatedly over time. But that shouldn’t stop you from starting the journey!
If you have followed the steps above, and stuck to the suggested timeline, there is a good chance that you will have come up with at least one concrete idea for something your project could work on and deliver in a short time, within one hour of work. If so, that’s great! You’ve done the hard work, now you just need to do get on and make it happen.
Even if you were not able to complete the final step, I hope going through this process has at least provided a greater insight to some of your stakeholders real needs and how you or your project might go about meeting them. Or, maybe it has highlighted that you really need to do some more work understanding who all your stakeholders really are before committing to delivering something.
The real aim of this challenge is to quickly demonstrate that thinking carefully about who or what a project is really going to effect, and then focusing and prioritising all project work based on how much value can be delivered to them can be incredibly powerful.
If you happened to hit upon just one “Why didn’t we think of doing that before?” moment, this approach has already proved its worth!
Of course, there is a big gap from working on a whiteboard with some sticky notes for an hour, to managing a business - critical project.
It would be great if you could get in touch to let me know if you took the Value Challenge, and what was the result? Were you and your team able to come up with some new ideas? I can also help you find out more about the detailed value engineering techniques that underpin this exercise, and help apply them to your own projects and organisations.