We must buy this product, our competition uses it…
With limited exposure to many industries, I can only guess that many people have similar problems with the way is work is funded. Work is…
With limited exposure to many industries, I can only guess that people have similar problems with the way work is funded.
Work is often dreamt up by a senior executive type, often who has recently joined from elsewhere and is looking to make their mark on the organization instead of looking to stabilize.
This often ends up as a ‘copy-paste’ job that the executive tries to install into the new organization without realizing the context, people and customers were all different. I refer to this as ‘ego driven architecture’.
Chris Matts refers to this as the community of needs vs the community of solutions. Check out his brilliant talk on Vimeo for a much richer explanation.
With the confident executive at the helm, with a tried and tested solution from a competitor — what could possibly go wrong?
If you thought that was scary enough, just wait for the smooth talking consultants in expensive suits to bolster the new executives solution with largely circumstantial industry reports of what other companies have done and how the same consultants played a key role (in many cases I have personally seen at least 3 consulting companies claim they were the ones responsible for another companies success (no names, I’m a professional!).
The pitch and the contract
Once the consultants have a race to the bottom in terms of bidding the executive and his colleagues agree on the ‘best’ and largely ignore price as they had already made their mind up before the initial discussions.
It is easy to pick holes in one presentation, once you’ve three others just like it.
The final selection involves the most senior of the partners to wow the senior business executives who suffer from altitude sickness due to their proximity to the work and customers.
Post signing of the contract based on a largely fabricated requirements the consultants arrive ‘weeks later’ with an army of talent. Except it’s an army of college / university grands in many cases who still have their mother pack their lunch and iron their shirts.
The consultants
These people are smart, they are bright eyed and motivated to learn, but they learn on the customers ‘dime’ and aren’t ready to hit the ground running. Usually just hit (metaphorically of course) by their senior managers and their textbook example of how now to be a servant leader or demonstrate psychological safety.
One of my favorite hobbies is making nice with the consultants to understand the work life balance and pressure they are put under by their own company to meet the clients needs. Many senior partners make promises and just expect the graduates to do the work (oh you want to sleep? you can sleep when you retire… or at least become a partner and you have some graduates of your own to whip).
I genuinely don’t envy the situation they are in and even worse is when the customer (myself in this case isn’t asking of expecting work to be done over the weekend or at night… I want sustainability and quality, not slick slides with no substance and sleep deprivation).
The work if usually disconnected from the customers / users, although sold within the company as a ‘strategic simplification’ with a viable business case that some how miraculously seems positive over x number of years.
The business case
That same business case touts a simplification (though decommission and consolidation of functionality from many systems to a singular state of the art off the shelf product that the consultants know how to configure in less time and your company could even flip through the manual. It is the only way to keep up to date, deliver the cost savings and simplification business case, it is perceived as home run idea (often too hard to resist, even the finance team are licking their lips). All that’s missing now is a mysterious program name that is named after an animal, an ancient god, a type of tree or a mountain range. Project Redwood is now in flight.
The business case is often supported by a small army of well-dressed consultants who have a routine template they can use to churn out the same made-up numbers as the drop of a hat.
These numbers and impressive looking PowerPoint slides have seldom involved much more than domain architect / CTO type, some senior executives, and some Excel file full of cryptic system names and acronyms very few people understand.
The target architecture
Then, a mythical architecture diagram is revealed originally created years ago and not updated, made in MS Word or PowerPoint and is so high level no one knows if it is still accurate (the diagram was never intended for the purpose it’s being used for now).
The people who produced he diagrams are long gone or can’t remember why they made it in the first place (often a simple image to convey on a call but no bearing to the actual systems architecture).
This outdated artefact is treated as gospel by the consultants, they create their own version with fancier visuals and now everyone is really impressed with how pretty the picture is, this is now the base for the business case and they start working on a target state architect.
The execution
The program gets funded and runs with the help of consultants who are usually quite comfortable rolling out an ‘off the shelf product’ as long as you don’t want to customize anything or use other tooling they aren’t used to using (which is common when a large enterprise has ‘enterprise standards’ for integration.
The users are seldom consulted until a UAT (User Acceptance Testing) phase and then they pull out their hair in frustration with the shiny new system that’s taken years only to miss half the expected features they use every day from the old system…
The shiny new system was never intended to do ‘all the things’ the users expected, they weren’t involved in the discovery, evaluation or rationale. The system was being forced onto them for simplification reasons. These users are often unwilling to give up their beloved advanced features only they knew about but depended upon staying on top of their job for the past years. Users don’t like the change when they aren’t used to it, especially significant change.
What they get is a new system, UI, and some functionality, most of which doesn’t work how the users expect it and somehow the processes have all changed and the users don’t know why (even through the new process design was signed off by a steering committee). It breaks my heart when the users aren’t treated like customers, they will be there long after the consultants leave and they must deal with it quite likely for the next 5–10 years.
The program runs for multiple years, it goes over schedule and the business case has well and truly eroded. Only half of the original systems were decommissioned. The systems that remain have an army of angry users who will only move to the new system once their favorite features have been copied exactly or they simply can’t do their job.
In extreme cases the business get so frustrated that they go and buy their own software as a SaaS solution. They are pitched on a simpler UI, process and something that can be turned on in weeks and already have a demo version up and running with dummy data.
The business mange to get things mostly working, only to realize they can’t get authorization & integration working without the help of the technology organization (the same people who rolled out the solution that they are running from). There’s been no security, risk or compliance assessments, the vendor uses a data center in a location that the company doesn’t allow the companies data to be hosted and now the company has two new products competing for the same users.
The citizen developer comes to the rescue
This is usually where the users wise up and start creating RPAs (bots) to papier-mâché over the new system and enable the users to still get their work done.
These same ‘bots’ remain running give the users a false sense of security because they no longer need to work late each night or on the weekends to do the same job they did before. The bots run until the next software update of the system and a new / refined UI is released by the vendor and the technology organization had no knowledge of the bots and the users had no idea of the planned changes. Trust has all but eroded at this point.
The technology organization gets the blame for not delivering on what the consultants had promised. The business are furious and the senior executives quickly slip away to another company with an updated LinkedIn / resume touting experience with the latest system and major program deliverables and promises of simplification.
The cycle continues
The next executives join, they bide their time for a new company wise simplification / technical debt remediation initiative and the cycle continues.
Whilst this story is made up and comes across as ludicrous, the reality is anyone who has worked at a large, complex company with too much money has see a similar story.
There is a whole cottage industry preying on these opportunities and people can’t get off the treadmill to pause and think. These patterns show up in different variants, with different names and paradigms, the fundamental problems remain.
The prognoses
These are systemic issues and often caused by people not knowing better and relying on old paradigms of doing things that they may have learnt in university, MBAs, from consultants or even their former managers.
There are other ways to deal with these problems, there are no silver bullets, Agile and DevOps aren’t going to make these problems go away, lean isn’t going to make them go away and certainly machine learning and AI won’t either.
This creates a rift between factions ‘business’ and ‘technology’ (or IT). It takes a noble steed (senior program manager) in the business to come in and whip technology into shape, they take a micromanager stance with such a detailed Gantt chart the team barely have any time to do work. Eventually people start leaving and the vision continues to compromise to the point where only a portfolio of the capabilities are actually working as ‘promised’.
What’s next
Over the next few blogs, I’d like to explore several tools and practices I’ve found useful, that have allowed me and others to consider other options, approaches, and alternative ways of dealing with massively complex challenges that can be done differently.
I won't make promises, I will pre-commit (thanks to Jon Smart for that reference) to sharing what I’ve learnt and found useful within a given context.
Practices are context specific, there are no best practices in complex, knowledge work and what you did before, is no guarantee of future success.
Future topics to explore
Moving from funding programs / projects to products and value streams
Team topologies and establishing a product mindset, thinking in platforms and ecosystems, and organizational and team design
Making sense of enterprise architecture and agile without resorting to the black arts of SAFe
Establishing OKRs when people really don’t want them
Tools for thinking (Cynefin, Wardley Mapping, Purpose Alignment Model, Theory of Constrains, Impact mapping etc…)