One of the difficulties with implementing a software factory is measuring development-team performance. Depending on the culture of the team, and the desired outcomes for your team, the approach may be fundamentally different, but here is an approach I have implemented, that I believe is fairly unique in a corporate environment.
The Typical Strategy Process indicates:
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
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.
A friend of mine liked this video on Facebook today. I liked it so much, I decided to make it the first post on my blog in a very long time. Enjoy.
Some great lessons, and an excellent reminder
At the end of November, I moved to I-Net Bridge to take on a CIO role. The move back to financial services is very refreshing.
I am excited about the opportunity and feel the weight of a great responsibility to an already successful organisation.
Strategic Alignment of IT with the declared business strategy is a topic that seems to be widely regarded as a holy grail. Something Everyone Strives for, but seldom achieves.
In my last few roles I have encountered a number of challenges in achieving a satisfactory IT strategy:
Let’s face it, if the business strategy is clear, and is officially published, the task is not so daunting. If however you are in an organisation that exhibits some of the above difficulties, then the task of defining an aligned IT strategy looks a little more tricky.
I firmly believe that when we are looking at the problem of an aligned IT strategy, we incorrectly try to engage our engineering skills, instead of our artisitic skills.
Now clearly there should be a balance, but I do not believe the right strategy can be defined with purely technical analysis. Lateral thinking, creative solutions, cross discipline thinking, presentation and graphic design; These are the most valuable tools.
For me, the most impactful and resonant IT strategies have been created when I have simply mulled over the business strategic problems for a period of time, and one day woken up thinking “aha – this is what IT should do to respond to those”. I have wondered if this process could somehow be defined or mapped out, like an engineering process, but alas, lately I have come to believe it is not a process, so much as an art. Now every artist has their own creative process, but most use the same tools: easel, paintbrush, paints etc.
So in this series I shall attempt to describe my own creative process, and also some of the tools I believe every IT strategist could employ to great benefit.
Add to Technorati Favorites
Subscribe to Sober Counsel