A few years ago I was on a contract with a large oil company. During my last week, I attended their big annual presentation on IT strategy. The presenter was making the point that the following year would be all about getting the foundations right for business growth. To make sure this initiative got the appropriate attention from executive sponsors, it was going to be packaged up as a Foundation Programme.
I confess I’d not been paying much attention until that point. With my exit a few days away, most of what was being said did not concern me. But this piqued my interest. Because my mind immediately started thinking about why such thinking might be doomed to fail.
Business leaders love phrases like “Getting The Foundations Right.” It sounds strong and directional and like the precursor to success. It also (sort of) implies the current foundations are not right and it (sort of) implies that the target of the work will be structural, and not about delivery. Exploring what’s broken and not actually delivering anything - catnip to consultants.
So yes, the cynic in me was thinking that it would probably turn into another one of those big-budget programmes that are overpopulated with advisors and coaches. A programme of work that has its own codename, t-shirt and logo, and very quickly becomes confused about its scope and rationale for existing. Big companies do this a lot: fund major change initiatives that start well, spend huge sums of money and drift for a while until someone (usually a new exec-level hire) charitably winds it up to show that they have leadership (i.e. replace it with their own programme).
Let’s be more positive
Are Foundations A Thing?
The sincerity of this kind of proposal is not in doubt. It can only be a good thing to build tomorrow’s market-leading ideas on sound processes and a strategic and scalable technology base. And big companies do need to change to be able to adapt.
So is there a rationale for creating Independent Foundational Work?
My mantra for any initiative is:
The name of the initiative must state (or indicate) the business outcome. Project Phoenix is only acceptable if the team are classics professors studying Greek mythology. Say what you want to achieve and call it that so that in every meeting people know what the goal is.
Outcomes can NOT be technical. Project Cool Message Broker is not a project. It’s a sub-part of a project that has a business goal. That way when it’s being implemented people will ask the right questions.
What I am saying is by all means fix foundations, but do so under the auspices of something that needs and uses those foundations. Not stand-alone.
The counter to this argument is that architectural change at the scale this oil company desired is not possible using my mantra. Everything is just too big. And size and complexity lead to three issues:
1. Concurrent Projects with Overlapping Requirements
It’s very common to discover concurrent projects from different areas of the business that have overlapping strategic requirements. Daily pressures being what they are, it’s not easy to get concurrent projects, with different project managers, to communicate effectively enough to build a shared architecture.
2. Sequential Projects with Overlapping Requirements
Projects that follow one another create even more of an issue. The communication problem is now affected by the passing of time and there’s the unrealistic expectation that one project will expend time and budget building for a future project that isn’t even defined yet.
3. Independent Projects targetting Strategic Business Growth
Even without requirement overlap, we have potential problems. Some project outcomes are aimed at a move into new markets (i.e. new products). You can fix issues from 1 and 2 by identifying cross-project themes and structuring delivery accordingly. But when the product itself is new so are the business processes to support it. Now we have to imagine the themes and try to turn them into a delivery plan.
Making A Plan
We can summarise this in business terms by saying that, when creating the operating plan for the forthcoming year, it can be beneficial to amalgamate some projects (or parts of some projects) when:
The combined outcomes of one or more projects are foundational to the business model - such that, if delivered well, multiple future projects become possible, or easier. And those functional goals can be stated in business terms, not technical ones.
The outcomes of one or more projects, if delivered independently and strategically, are burdensome enough that they may undermine the business case of the individual projects
The outcomes of one or more projects, if delivered independently and strategically, are significant enough that parallel delivery could create delivery risk
In fact, we can state the corollary of this and say that in very large companies if you embed a foundational initiative in another project you will most likely kill it for three reasons:
You confuse the mission by having a business outcome and a foundational outcome
You can break the business case of the business outcome by making it pay for a reusable foundation
You can create a priority conflict which will, more often than not, result in business outcomes trumping foundational ones
The goal of the annual plan is to be clear and transparent to the whole business. That is to say, every bit of cash that’s being spent should make sense to the exec team.
What we don’t want, and it’s a depressingly common practice, is to start having conversations about business outcomes and technology/foundational outcomes. They’re all business outcomes. It’s just that some have an immediate business focus and others support current and future outcomes indirectly (I would suggest dropping any initiative that’s two levels of indirection or more away from the business outcome).
So, yes Foundations Are A Thing.
And we can propose three new directives to the mantra:
The same business case requirements must be demanded of foundational programmes, even when they say they’ll be delivering indirect business benefit
All foundational programme outcomes must be shared in public so that they can be budgeted and managed in a manner that supports a just enough approach
All scope/outcomes in foundational initiatives that do not directly benefit business outcomes must be removed
A lot of this feels contradictory. Let’s work through some examples.
A retail organisation that sells through multiple channels should have a strategic (foundational) order management system that uses business rules to apply channel variances in the processing pipeline to orders but reuses code across all common process steps.
You wouldn’t want separate teams building and rebuilding a credit check engine, warehouse fulfilment, or account management on a channel-by-channel basis.
Reference (static) data in a financial trading organisation should be mastered in one place. You wouldn’t want each traded product keeping copies of counterparty data in local silos.
Product Lifecycle Management
A product company should have a strategic product-centred application for managing the product lifecycle. The code to manage complex data models that underpin products, their interrelationships, pricing structures, introduction, configuration and eventual decommission has great potential for reuse.
You wouldn’t want complex products mastered on spreadsheets and multiple applications, relying on manual activity to keep things in sync.
His choice of metaphor for open source development (open, egalitarian and accessible) vs closed source purchased products (secretive, hierarchical and authoritarian) applies just as well in corporate enterprises:
the Chief Architect, or CTO, is the Pope
the Architects are the bishops and senior clergy
the Product Managers and Software Engineers are the rabble in the bazaar
Obviously, there are two sides to this story. The higher up you go the greater the temptation to use projects to combine and conquer, which risks the creation of a megaproject. The software engineering temptation is to just start, risking proliferation and duplication.
It’s possible to cater for both views by structuring the work better. The pitch would go something like this:
Foundation Project Pitch
If we make projects too small they’ll create duplicate work and we’ll have a comms nightmare. If we make them too big they’ll become confused and collapse under their own weight. Equally, we don’t want to have any project that thinks it’s building the future without any immediate well-understood requirements.
There’s a critical moment in large programmes when major changes to infrastructure, and supporting elements such as reference and operational data stores, reach the point of no return. Discovering only then that they will take years to complete, and cost a small fortune, is too late.
An iterative and agile delivery approach is the only way to prevent this.
Foundation Product Factory
Assign a small cross-functional team to determine common needs that might be candidates for foundational work.
Work together to draw up a hit list of prioritised foundational services. Select a small subset required by business projects over the next six months, and spawn a team to deliver them. Repeat for each iteration. Do not look further out than a year other than at a very high level.
Single Point of Contact
Identify a single point of contact Product Manager for each foundation service. Leads from other projects feed in requirements through this person only.
Foundation Product teams are initially given an opex budget for three months maximum. Or for one spike-style iteration if the goal is less clear. The budget is renewable only on results. The cost of foundation products utilised by other projects is capitalised.
Foundation Product teams scale up and down as needed, maximising resource efficiency. Drops are made into production driven by demand only. Nothing is released without a consumer. This gives a tactical path of least resistance to other projects, which also happens to be the strategically approved option.
Foundation Product team members are swapped out and replaced regularly to circulate knowledge. This reduces feelings of envy for those not selected to be on the Foundation Product team and allows other team members to get experience working in a different environment.
The Foundation Product team runs their own knowledge management tooling, explaining progress and allowing for comments, suggestions, and requests from outside.
The Enterprise Architecture team is responsible for guiding other projects towards deployed services, not designing the foundation product itself.
Hopefully, that sparks a few ideas. I’m not saying it’s possible to put all the answers into one short essay and of course, the devil is in the detail.
I’m saying the notion of a regularly reviewed, ostensibly perpetual, product factory that races ahead of tactical business projects, to provide them with short-cuts, is far more efficient than the alternative, which is chasing down every errant solution or risky manoeuvre and having to make a retrospective case for doing things properly.