-Have a clear shared vision of the change that is continuously communicated to everyone.
-Ensure understanding and acceptance of the reasons for the change by everyone.
-Create and implement metrics linked to the desired business results.
-Be quick and nimble with interim deliverables that are 80% right
Interestingly or maybe not so surprisingly these behaviours would apply to any transformation project. Additionally I think these behaviours are directly in line with Enterprise Architecture objectives. "So what?" you ask. In many organisations on their Enterprise Architecture journey, the IT shop is seen as imposing Enterprise Architecture upon the business. At a very high level there is some acceptance that IT is needed to enable the business outcomes and an architecture is required to better manage the IT assets. But what this actually means and how to engage across the organisation is a bit of a mystery.
It is expected that the IT shop will get a handle on the technical architecture to drive it from what may have been an piecemeal organic architecture to one which will enable greater flexibility in supporting the business. So there is also acceptance that IT will model the business to demonstrate relationships between IT assets and the business outcomes.
Supporting the the last point is probably the most critical and yet for many the most difficult. The architecture team needs to be nimble to keep up with the 80% solutions and the refining their architectures as the transformation progresses. If this is not happening the architecture will quickly be seen as out-dated or simply an after the fact documentation process or even worse an impediment to the transformation, stalling the deliverables because the development of the architecture artefacts is slower than the transformation cycles.
So back to IT transformation and EA, what's the connection? EA practices may be used to support IT transformation. Not just IT transformation in the sense of what IT assets are required to support the outcomes of the transformation, but to work hand in hand with the transformation program and develop dynamic easy to understand artefacts that communicate the vision, tie the vision to the stakeholders view point to give them an understanding of how they impact the vision, interdependencies, identify metrics and the transformation steps.
To me it seems the separation of EA and continuous improvement/transformation programs is counter-productive. As I wrote in a previous post, I believe that EA should facilitate change, not just change in IT assets but business change, otherwise EA will become another stove pipe.