Dot-coms ain’t all technology

Earlier this year I had the privilege of doing some work for a fast-growth dot com that had reached USD100M revenue in around seven years with on going 30% CAGR.

The reason they had called me in was to help out with the business ends of their project lifecycle. The specify, build, test and deploy activities were well documented and were working quite well, but the concept, shape, business case and benefits activities were not being done at all. This had three disruptive effects:

  • There was no solid business foundation – purpose, targets, scope – for any project, which meant that the project managers could change direction at will, delivering what they wanted rather than what the business needed; and conversely the product managers and sales executives lodged change requests at will, destroying any form of scope control.
  • There were no real boundaries upon which to measure project success or failure - no technology success criteria such as architectures or service levels; and no business performance success criteria such as customer experience, effectiveness or efficiency.
  • The loudest voices received all the attention - resources were allocated to projects sponsored by the loudest voices; and those resources were reallocated between projects depending on which crisis evoked – yes – the loudest reactions.

From what I could see at the time there were three causes:
  • The fast growth had been achieved at the expense of formality, in fact the senior IT managers were proud that they had avoided being slowed down by formal processes;
  • IT was a “common good”. In other words, even though the business as a whole paid for IT no business unit was recharged for project or production services.
  • The techo’s were out of control – aside from the project disciplines they had no quality processes: no architectures; no accountability for system reliability, usability, maintainability or efficiency; and no accountability for delivering what was needed.

All in all quite a common situation.

So with some very effective senior sponsorship from the CEO we cleaned up the governance, put in place some roles and accountabilities, and introduced some lean processes that imposed some end-to-end rigour without imposing time and cost burdens.

But it was still going wrong – projects were starting without proper business foundations, marketing and sales executives were still expecting to impose late changes, and there were still no post-project success stories.
We sniffed around looking for causes without much success until one of those “coffee machine” epiphanies.

As part of the end-to-end process deployment we were running workshops to help staff understand the process, its rationale, and methods. During a break I was queuing at the coffee machine along with a gung-ho sales exec and a search engine optimisation analyst. It could almost have been scripted:
  • Nathan the sales exec was enthusiastic about recent sales performance: “Hey Tony! How come small business traffic from the search engines has dropped off recently – I’ve been counting on that traffic to meet my growth targets!”
  • Tony the SEO analyst looked nonplussed: “What do you mean? I’ve been putting all my budget into the consumer end in line with the what the Directors were saying last month!”
Each was following what he saw as the overriding strategy.

Both were right. Each had been told separately, by the same Director, about an overall push away from large corporates into small business and consumer segments. The trouble was that the Director had filtered the strategy to suit the audience, but did not put the tailored strategy into a broader context.

It turned out that strategies consisted of conversations (which is good) but were never written (which is bad) on the pretext that they “change too quickly”, and were never put into context across the organisation and with each other (which is very bad). The result was an ostensibly united organisation heading in twenty different directions, with different assumptions and different views of roles and responsibilities. The only common ground was the revenue target of 35% CAGR.

I went back to the CEO and asked to see the strategic plan so I could feed the business/IT project pipeline. Of course he couldn’t show me one, so I requested 15 minutes with his leadership team.

At the team meeting I explained quickly the defects and rework that result from ad hoc project requests, then posed several questions:

  • Aside from profit and return to shareholders, what is this company trying to do?
  • What is its role in the industry?
  • What are the market segments? What does each segment need?
  • What are your commodity products? What are your premium products?
  • How do you measure the end-to-end customer experience?
  • How do you know your marketing is successful? Sales teams? Fulfilment and servicing?
  • How do you know when you need to be efficient? How do you know you are efficient?
  • What are your aspirations? How will you achieve your aspirations?
  • What are your priorities? What should happen first?

And importantly:
  • Where is the document that lays all this out so that your market, sales, service, and IT people are working from the same blueprint?

It took a few minutes for the leadership team to understand the problems caused by fragmentation and lack of a single reference document, and seconds to commit to action.

From that meeting it took two weeks to write down the different views of reality, another two weeks to agree consistent working, then another week to publish a six page magazine-style booklet on paper and on the intranet.
The booklet now serves as the single reference point for all business units and projects, is updated monthly with the latest business performance and project news, and is refreshed annually to reflect changing circumstances, directions, and priorities.

The impact on business/IT governance was sudden and far-reaching. Projects came to IT better defined by the business, with better understanding of impacts across both business and IT, and with clear performance targets that aligned explicitly with corporate targets. Post-project follow-up was much easier because the desired outcome was better defined up front. Because both business and IT had to think about projects in terms of the booklet, fewer “it was a good idea at the time” projects were proposed and fewer started.

The flow-on effects have been diverse and interesting:
  • Because the strategy is documented in a form that encourages discussion, the project requests tend to have longer term views (but still have short term pay-backs) that in aggregate form a directional statement of how the company will deliver on its non-financial vision.
  • Now that project outcomes are expressed in terms of business performance indicators, business leaders are scrutinising their own parts of the organisation in new ways to improve their performance in support of the corporate targets and in terms of the performance indicators.
  • Business analysis and architecture, which had both been ignored, suddenly became fashionable as tools to improve business and IT, and for a short time were put on pedestals (a state which has since slipped back to a more healthy “part of the performance management mix”.
  • The whole organisation is taking a longer-term view, at the same time as focusing on today’s revenue generation. This long term / short term balance seems to pervade the whole organisation, with sales teams thinking about how to retain customers they have acquired, rather than thinking about how to maximize the one-time revenue.

The overall outcome shouldn’t have been a surprise, but the transformation in this case was dramatic and almost entirely business-based. Without too much fanfare and without following a “best practice recipe”, the leadership team:
  • Provided unified top-level sponsorship
  • Involved every one of the 300+ employees
  • Built a big picture that showed clearly the organisation’s values, aspirations, priorities and actions
  • Made sure that every employee understood the big picture, why it was important, and how to apply it

This provided the context within which business/IT governance had clear terms of reference, targets, and accountabilities. The business/IT governance council was able to:
  • monitor IT performance using very few metrics,
  • evaluate proposals and performance exceptions against clear business and project criteria, and
  • provide clear direction to both business and IT.