Foundations

Taking the sting out of strategy

By Julian Browne on February 12, 2008. Filed Under business, 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:

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:

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:

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:

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.

Background

Proposal

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.