A dependency chain is where you have a number of functions that all need to do some part of a piece of work in order to fully deliver it. These functions complete their part and then pass it along to another.
In my last article I showed why your IT requests were likely taking so much longer to service than you expected. But what if you have multiple dependencies chained together? How can you get a rough idea of how long something is going to take when you have a disconnected dependency chain rather than an end to end view of the system. In this article, I’ll explain the process of getting a rough statistical idea of how long something is going to take when you have multiple dependencies all linked together. I’ll explain this through an R script, but the concept is easily transferable.
You’ve got a quick job to do so fire it off to an IT team. It should only take around half a day of effort so you expect to hear back by the end of the week. Three weeks later and you’re still waiting. So why is this happening? What is the deal with IT delays?
Apologies in advance to all scientists, engineers, and mathematicians.
Over this series, I’ve spoken in detail about the organisational impact of IT dependencies in your system. I’d like to take a diversion and discuss how it can impact the individual.
I posit that even without the work benefits you could derive from eliminating dependencies, the quality of life changes you could bring about would more than pay for the effort.
This isn’t an article about workplace stress, we’re all pretty familiar with its cost to our economy. Nor is this an article about the cost of employee churn. It’s not even about the cost to productivity through disengagement. Let’s move forward knowing the impact of people not being happy.
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.
If you ask 10 people why Digital Transformations fail, you’ll get 10 different answers, often with phrases like “buy-in” and “culture” thrown around. Although there isn’t a simple answer to this question, I’d like to talk about one that often gets ignored. Dependencies.
You have a dependency if something is contingent on another, here are some examples:
“Getting this work complete is contingent on the tests passing.”
“We need the platform team to spin up a test environment before we can run the tests.”
“We need to have sign-off before we can allocate time to create the instance.”