Taking the sting out of strategy
A few years ago I did a long freelance stint for one of the big oil majors. In the last week of my tenure there I found myself sat in a presentation on their new IT strategy. Interesting stuff, perhaps, but with my exit only days away, I confess I wasn't paying all that much attention.
The presenter was making the point that the following year would be all about getting the foundations right for business growth, and to make sure this initiative got the appropriate attention from the executive sponsors, it was going to be packaged up as a Foundation Programme.
Business leaders love stuff like that. "Getting the foundations right" sounds good to shareholders and managers alike, and acts as rallying call to IT staff after a long and tiring year.
The cynic in me was thinking that it would probably turn into another one of those big budget programmes, overpopulated with consultants, that gets confused about its scope and rationale quite quickly and drifts along until someone charitably winds it up. But the sincerity of this kind of proposal is not in doubt - it is, of course, a good thing to build tomorrow's market-leading ideas on a sound, strategic and scalable technology base.
As the presentation went on, I started to think about whether it would be even possible in a practical sense to make a concept like this actually work.
The rationale for creating independent foundational work is clear but worth stating:
Concurrent Projects - Overlapping Requirements
It's very common indeed 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.
Sequential Projects - Overlapping Requirements
Projects that follow one another create even more of an issue. The communication problem is now affected by the passing of time (read: having useful documentation) 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.
Independent Projects - Strategic Business Growth
But let's say that none of our new projects have overlapping needs. If the marketing guys are intending a big push into new markets, or new products (that these projects will be supporting) it's entirely likely that something, somewhere, is going to break when all this new business comes in. If the first two situations involve scouring business ideas for common themes, this involves identifying themes that are in the process chain but that haven't been included.
We can summarise this in business terms by saying that when creating an annual operating plan for the forthcoming year, it can be beneficial to amalgamate some projects (or parts of some projects) when:
The combined outputs of one or more projects are foundational to the business model - such that, if delivered well, multiple future projects become possible, or easier.
The outputs 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 outputs 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 strategic foundational initiatives, that support business benefits, rarely work when planted inside projects with direct business benefit because they:
- Confuse the business project mission
- Can break the financial business case of the mother project
- Create a priority conflict which will, more often than not, result in strategic elements being cut or reduced in quality
Ideally, we want each year's project portfolio to be completely transparent to the business. That is to say every bit of cash that's being spent should make sense to the executive board. What we don't want, and it's a depressingly common practice, is to start having conversations about business projects and technology projects. They're all business projects, it's just some have a direct business focus and others suport these projects indirectly (projects that are two levels of indirection away from the business I would suggest get canned).
So we can propose that any agreed foundational initiatives should be managed in their own right because:
- This forces a clear business case to be made for a programme, even when it delivers indirect business benefit
- The programme content is clearly visible and so can be budgeted and managed in a manner that supports a just enough approach
- Any scope that doesn't directly benefit business projects can be removed
Let's look at some simple examples:
A retail organisation that sells through multiple channels should have a strategic order management solution 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, or warehouse fulfilment code, or account management on a channel by channel basis.
Reference (static) data in a financial trading organisation should be mastered in one application. You wouldn't want each traded product keeping copies of counterparty data in local silos.
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.
Creating foundation projects often gives rise to conversations that remind me of Eric Raymond's marvellous essay The Cathedral and the Bazaar. His choice of metaphor for open source development (secretive, hierarchical and authoritarian versus open, egalitarian and accessible) applies just as well in corporate enterprises - the architects being the self-appointed bishops and senior clergy, with the Chief Architect or CTO as the Pope, and the rabble in the bazaar being the product managers and developers. Not that I mean that as an insult to developers, far from it. Bad architects love a bit of hierarchy to preach from, and good developers rightly ignore this and get on with the job at hand.
While projects are still in a vague we'd-like-this-kind-of-thing-next-year form, and undergoing the kind of review that will determine whether three projects are indeed one, or two, or distinct enough to remain three, the architectural temptation is nearly always to apply a kind of combine-and-conquer approach, risking the creation of a megaproject that will lose it's way, incur the ire of finance, and lose the trust of the business. The developer temptation is to just start, risking more proliferation as the same thing is built multiple times.
In fact, it is possible to address both sides. You can call it a foundation, an essential, a backbone, a core, or a primary programme, the name isn't important, what's important is that it does work.
Three years ago I made this very case to a project board and tried it. The trick is to adopt an agile delivery model that isolates the foundation services and delivers them before they're needed elsewhere, this way the strategic approach also becomes the tactical. Here's the essence of my original concept document, with the commercial elements removed.
The pitch goes something like this.
Pretty much everything that's been written above. i.e. foundation initiatives are a good idea, but need careful management.
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.
A cleanly iterative and agile delivery approach is the only way to prevent this.
Create a small expert centre that takes the form of a never-ending project. A lead, who codes and doubles up as a design authority (and a good relationship with the architects), no more than four extra coders; a systems support engineer to handle the environment, build and infrastructure; one or two test engineers (ideally the initiative will adopt a test-driven model with plenty of continuous integration so the test 'phase' is minimised); a project manager.
Work together to draw up a hit list of prioritised foundational services. Select small subset required by business projects over next six months, and start producing them. Repeat for each iteration.
Single Point of Contact
Define a single point of contact for each foundation service set. Business Project Managers from other projects feed in requirements through this link. This gives some dotted line business control, but as team members still report to IT managers there's no risk of them going native.
Project initially given an opex budget for three months, or three iterations. Budget renewable on results. The cost of service assets utilised as by new projects is capitalisable.
Foundation team scales up and down as needed, maximising resource efficiency. Drops are made into production when they are ready not just when they are needed. This gives a tactical path of least resistance to future projects, which also happens to be the strategically approved option.
Team members swapped out and replaced every once in a while to circulate knowledge. This reduces feelings of envy for those not selected to be on the foundation team and allows other team members to get experience working within an agile environment.
The foundation team runs their own WIKI, explaining progress and allowing for comments, suggestions, requests from outside. The Enterprise Architecture team is responsible for guiding other projects towards deployed services.
Hopefully that sparks a few ideas. I'm not pretending it's possible to put all the answers in to one short essay and of course the devil is in the detail, but I can say that the notion of a regularly reviewed, but ostensibly perpetual, project that races ahead of tactically obsessed 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.