Using Wardley Maps to execute projects — part I
Atlas is an open source project created by the Leading Edge Forum that is supposed to make using Wardley Maps easier. If you do not know what Wardley Maps are, I strongly recommend you to watch this introductory video on Youtube.
The mapping technique can be applied in many different contexts — building an appropriate strategy for your company is one of them, but what is more important for you and me, it can be also used to manage regular projects. You do not have to wait for your board to start using mapping — you can start using them right away, and show their value in practice.
Step I — create a map
Wardley Maps are all about context and situational awareness. Therefore, to create a map, you need to figure out who is the project for and what the customer is trying to achieve. More than 80% of IT projects is, at best, neutral to the worth of the company, which means that cancelling them would be more beneficial than executing them. Even if you are delivering the project for an external company, verify that it really makes sense, because your reputation is at stake here. For the purpose of this map, I will be using a map that I have used to check how buffer.com may be working.
Step II —think of user needs
Put detailed objectives of systems users here. This part is not about the customer who pays for the system, it is about real users whom the system is going to help in any way.
If necessary, use the description field to link user needs to more detailed analysis hosted on your wiki or google docs. Once you understand what is the goal of the project, from perspectives of the paying customer and end users, you may proceed to the next step.
Step III — fill the map
Filling a map is one of the most challenging tasks in this process.
You need to start with user needs identified in the previous step, and ask yourself a question “What do I need to do X” a number of times, unless you reach components that you will buy from external providers. Chances are you will not know everything. It’s normal, although your attitude to unknown is extremely important here — you should not, under any circumstances, make any assumptions here, especially for mature and stable components. Look at the final map below:
I do not know how to figure out what is the most appropriate time to post anything on social media, so I have admitted it openly by putting the component in the ‘custom built’ section. Now, imagine what a mistake it would be to commit to a project deadline at this point. Removing uncertainty takes time, and requires experimenting. Therefore, if I need to spent some time on research and prototyping before I will be able to say whether this project is actually doable.
Step IV — delegate responsibilities
If the project is of considerable size, you may not have time/skills to do everything by yourself. Instead of relying on always cluttered-email or issue tracking systems, you may put a reference to a wiki on your component details.
Thanks to this simple trick, knowledge related to the component is easily accessible all the time, to all interested parties. Such approach triggers creation of teams oriented on one component only.
Summary
Using Wardley Maps to execute your project is supposed to help you avoid a couple of very critical mistakes, that is:
- Doing a project that is a waste of time, because it does not add any value either to the customer or to end users life.
- Overcommiting — assumptions like to be wrong. By identifying and testing them early, you can make more precise plans.
- Blurred responsibility — by identifying components early, you can not only properly assign them to people, but also let those people know how final success of the project depends on them.
In addition to that, you open yourself for the whole set of cost-cutting optimisations, which will be covered in the next post.
The tool used to create those maps is named Atlas, and is available on Github here.
