August 21

Last week I stopped at the local Barnes & Noble's to pick up a book. The tab came to $23.72. I gave the cashier $25 and started fishing in my pocket for 72 cents. The cashier looked up in surprise when I handed her the coins. "Oh, it's too late," she said, even though she had not yet made change. She had already rung up $25 tendered, and she was committed.

Refiguring the change mentally probably didn't even cross her mind. And I suspect giving her all the change I had at the end of the transaction and asking for $1 would have been enough to shut down the register.

I'm sure the cashier was smart enough to be able to stop, think, and make the right change. But in her mind, she committed to a course of action.

Seems like a trivial matter when discussing technology and management, but the incident triggered an immediate association with a topic I'll be presenting to the local consultants association: The classical approach to IT strategy sometimes leads IT to "stay the course" when it shouldn't. A comparison between two approaches to IT planning will show why.

"Industry Standard" Strategic IT Planning

The classical approach to strategic planning - often embodied in templates one can download from various sources - has five steps for developing the content:

1. Discover the current state (scans, SWOT, etc.)
2. Envision a future state
3. Analyze the gap
4. Define projects that bridge the gap
5. Score and select projects and plan the work and the funding

To align IT strategy with company strategy, steps 1 and 2 consider the company's current business situation and strategic plan.

So, what do you get once the plan is approved? A commitment to build the systems and organizational structure of the future.

Now that IT is committed, what happens when IT gets a curve ball - something like a change in technology, or a new business opportunity that fits the business's direction, or a change in thinking that suggests a different IT organizational structure? Does IT stick with the plan (like our cashier did, but on a much bigger scale)? Does it tune or overhaul the plan, which takes the time and money needed to re-execute the process? Does it abandon the plan altogether, leaving none in place?

While this approach provides a long-term roadmap, it may not provide much flexibility. Ultimately, down the road, IT may continue to work on projects consistent with the commitment even though the strategy no longer makes sense.

Separate Strategy and Plan

Another school of thought separates strategy from the execution plan. The strategy provides the framework for making decisions about projects; it's aligned with company strategy, and it has a similar time horizon. The execution plan is a list of funded projects to be executed; they're chosen using some scoring system that includes consistency with the strategy.

The critical distinction here is that the plan is fluid. The plan can change any time one project completes and the resources and funding are available for the next; simply choose the highest scoring project proposal from among those waiting in the wings. Regardless, IT's commitment is to further the strategy by picking the best projects when it's time for a decision; the commitment is not to a list of projects. For those interested, an example appears below.

My recommendation: Split strategy from the execution. Keep the strategy short and sweet, and use it as a guide to decisions. Make the execution plan a living document, make sure it implements strategy, and change it in light of current conditions. (And for a topic that deserves its own newsletter, use the steering committee to score and select the projects!)

An Example

ABC Company's IT group develops a strategy that includes, among others, three strategic objectives:

1. Increase internationalization of customer facing applications
2. Decrease the proportion of money spent on old "run the business" applications (i.e., increase the proportion spent on new transformative and revenue-generating applications)
3.  Reduce the company's risk arising from losing application internals knowledge

These objectives, and their associated metrics, are elements of the strategy, and the steering committee has blessed it all.

The scoring scheme set up by the steering committee responsible for choosing projects allocates points for

• Number of strategic objectives served by the project (higher count gets higher score)
• Business effect (a complex measure of ROI, if any, and criticality) (higher ROI or criticality gets higher score)
• Time until outcome is felt (shorter time gets higher score)

Resources for projects become available when a project in the current execution plan completes. In the wings are three proposals, one to modify a customer facing application to use a new multi-language translation capability, one to begin exploring an open source DBMS for future use, and one to cross-train two developers on applications they know nothing about. Incidentally, the company has just set up a promising new branch office in Brazil, and a developer has just resigned.

Under the scoring scheme, the cross training project gets points for criticality, one month to outcome, and meeting one objective. The language related project meets one objective, has high ROI projections, but takes 4 months. The DBMS serves one objective but gets few points on other criteria. Given the budgets, the first two are added to the execution plan and the third remains in the wings.