One of the largest challenges preventing organisations from competing effectively in the market is their structure. When you are optimised for technology or role, then you are not optimised for customer value. But how do you actually get there? What does good look like for your organisation if you went back to the drawing board? I’m going to share a process I’ve developed for redesigning a system for outcome alignment.
Note that this is not going to be a full article on digital transformation or strategic redesign. I am simply going to focus on the guiding principles and a specific approach to assist in exploring an outcome aligned design.
After some of my recent articles on building a dependency map, a few people got in touch asking for tips on actually creating them. Here’s a quick way to get started.
You might have noticed the following example in my previous posts.
I created the graphic above with an amazing bit of kit called Neo4j. It’s actually an incredibly sophisticated graph database technology, so it almost feels a little sacrilegious to be using it for this.
If you’re not up to speed on the concept of dependency mapping, then I’d suggest taking a look at my previous post where I talked through how to go about building a dependency map.
So what happens now? You’ve gone through the workshop and now have a bunch of data that’s telling you what? Something about your system? I’m going to run through some of the actions I take when attempting to understand a dependency map.
Recently, I published an article where I discussed the concept of dependency as a proxy for complexity. I also tried to show that complexity is the biggest aspect to consider when attempting to improve the flow of value. This is all part of a concept I call Dependency Mapping.
Following publication of the article, I had a few people who read it on LinkedIn reach out for some advice on actually doing it in their place of work. In this article I will dig deeper into the process by which we can start to map out dependencies. With the map completed, we can then work to remove them.
Dependency maps are going to be messy as they try and convey a huge amount of information. We’ll aim small, and then offer some suggestions for improvement from there.