The IT Holy Grail: Part 2 – Start with the End in Mind

The Typical Strategy Process indicates:

  • Where we are
  • Where we want to be
  • How to get there

In my experience IT strategies tend to get stuck defining “where we are” because the sort of people doing IT are often detail oriented people and defining the as-is becomes an exercise that spirals into ever increasing levels of detail and never finishes, or becomes obsolete before it’s finished because some other imperative forces a change before the process completes.

My recommendation is to switch the order slightly for a very specific reason.  I propose that we define IT strategy in terms of

  • Where we want to be
  • Where we are
  • How to get there

This seems like a minor change, but there is method in this.  It is more difficult to define the future in terms of extremely fine-grained detail, so the future view tends to be defined in terms of principles, and characteristics or properties of the future state – A High level description of the future.

The trick then is to structure the definition of “Where we are” in terms of the deltas with the “Where we want to be” description.  So we shouldn’t try to define the “As-Is” in all it’s glory, but only the aspects that will be impacted by the notable differences with the “to-be” definition.

For example if we have a proprietary solution in the “as-is” and the “to-be” says we will use a commodity “off the shelf solution”, The definition of the “as-is” can be limited to the description of the critical features of the “as-is” that must be carried forward into the future solution and why.

In many future scenarios we want to add some capabilities that were never there in the “as-is”.  In this case the “As-Is” can be captured as a check-list of areas against which the new capabilities must be developed.

So the basic idea is to use the “To-Be” view as a guideline to indicate how much detail is required in documenting the “as-is”. When you have enough “As-Is” documented to be able to create a “How to get there” plan, then stop.

When the individual projects kick-off to actually implement the changes, these projects themselves can go to a greater level of detail if required.  The important point here then is to ensure that these updates of greater detail are recorded in the architecture artifacts of the organization, and not only stored with the project documentation.

I use a number of patterns or templates for documenting the “as-is” and to be.  A List of those next time.

This entry was posted in Management, Philosophy, Strategy. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *