These articles are aimed at senior management funding Software Developer or IT Professionals attempting to show the ROI benefits of what can sometimes seem counterintuitive.
This ever growing library is provided free of charge and can be found here.
Complexity increases the costs of anything.
This is true in Software Development and pretty much everything else in the world.
Complexity is an important consideration in understanding, and thus improving, the ROI of your software development.
What is complexity?
Within software development, complexity is the difficult of delivering a project.
A great way to consider this is through the Cynefin Framework:
“Cynefin offers five decision-making contexts or "domains"—simple, complicated, complex, chaotic, and disorder—that enable managers to identify how they perceive situations, and to make sense of their own and other people's behaviour” Wikipedia
By Snowden - File:Cynefin framework Feb 2011.jpeg, CC BY 3.0
Aligning a project to a specific domain shows us we should be thinking about it.
The domains (at a basic level), map to the 5 domains;
Simple or “known known”
We know problem and we know the solution. In software development, this will be something we have already done and being asked to do again.
Generally this not the focus of software development. If we’ve already solved the problem, why are we doing it again?
Complicated or “known unknowns”
We know the problem but not the solution.
This could be considered the “base” state of software development. We are presented with an understood problem which should be analysed to arrive at a solution.
Complex or “unknown unknowns”
We don’t have a clear idea of the problem or the solution.
This is where we need to do more than just analyse the problem to arrive at a solution. We need to probe and sense our way.
Chaotic
This is where the domain is “too confusing to wait for a knowledge-based response”.
This is where we need to act (almost on gut) to establish some level of order and stability to get the problem into the complex domain.
Generally any action is better than inaction.
Disorder
Disorder is a state where there is no clarity about which of the other domains apply.
For the purposes of this article, I’ll exclude disorder.
Costliness of domains
A project will increase in cost as it moves anti-clockwise from Simple, through Complicated, through Complex to Chaos.
And while any given project could fall into any one of those domains, there are factors that can push them into one of others.
Environment
I’ve talked previously about how the environment can impose an additional tax on any work being done.
Looking at it through the Cynefin domains, if your project is in a messy problematic environment, it is easy to see that a Complicated project can be pushed into the Complex domain.
So take for example an environment in which “corners have been cut”; historically, tactical decisions are likely to have been made on a project by project basis. A little bit of “that will do” here and a little dash of “oh, we’ll come back and fix that later” there … before long you have messy environment (I generally talk about this in the sense of “Technical Debt” … more on this in future articles).
As with the stones, we are balancing solution on top of solution. The foundation for each solution is less and less stable. We have to take more effort to balance our solution to avoid the whole lot falling to the ground.
That extra effort is our tax and thus additional cost on top of the cost to resolve the actual project.
I’ll come back to how we should address this in a future article on Technical Debt … but for now, just know that our environment can increase the inherent complexity domain of any given project.
I’ve known environments that can increase even the simplest project into being complex.
Right staff, the right skills, the right experience
Again something else I’ve talked about.
No all Software Developers are the same. They are people with individual skills and experiences. They are unique snowflakes.
Thus you cannot assume that a given project will be resolved independently by two Software Developers (or teams) expending the same level of effort.
As such, again a project may move into another domain because of that level of skills and experience available to resolve it.
Conversely, if you have to have someone that has a high level of skills and experience pertaining to the project (they’ve solved it in a previous organisation of example) – they may be able to reduce the complexity domain.
How do you solve this?
Training and sharing experience.
I’ve written previously about the benefits of training. In short, the better trained, the more productive your team.
Shared experience is avoiding the trap of silo’ing the work to an individual. It can be really tempting to always pass a certain type of work to Jeff because he knows it best – he will get it done quicker and cheaper.
While tactically that maybe true in the short term – in the long term this is a disaster if Jeff leaves or you have more work than Jeff can handle. (This also falls into the Technical Debt category that I’ll be picking up in the future).
At minimum, work should be shared by a team. That experience is then shared – reducing your risk going forwards.
Many hands make for complex work
The more parties involved, the more complex a project becomes.
If you’re in the middle of coordinating two 3rd parties then complexity is a given.
The more dependants the more complex (I’ve a mini-series coming up looking into this).
How do you eat an elephant?
If increased complexity adds cost, then reducing that complexity should reduce that cost.
When looking at a projects, can we split it down into smaller (hopefully less complicated) projects?
Can we think about it in a different way?
It is common for me to find that projects are, to be blunt, “everything including the kitchen sink”. They will include a variety of “would likes”, “nice to haves” and the occasional “half-baked ideas”.
There may be value in all of those things – but trying to achieve all of them adds to the complexity.
Looks to break the project down into focused and clearly understandable deliverables – then build on them layer by layer – a wall rather than a stack of misshaped stones.
Much better to add a brick at a time. Build up each layer. Then add to each sound layer.
Summary
The take away from this article was simply to set the scene that a project cost is heavily influenced by its complexity. And that there are outside factors that can influence that complexity.
This is fairly obvious when you think about … but it is commonly overlooked as a factor in establishing good ROI from Software Development.
And it was something I wanted to cover in advance of a couple future articles.