Potential Pitfalls in Technology-Enabled Business Transformations
In my experience, when Enterprises perform Business Transformation design exercises where the solution is to be enabled or underpinned by technology, a core list of the same potential pitfalls are regularly encountered. It would be interesting to see whether others come across the same types as well, so here are a few examples of what I always tend to come across:-
Technorati Tags: Business Transformation Enterprise IT Business-IT Alignment IT Excellence Solution Architecture Enterprise Architecture EA
| Potential Pitfall | Ways to Avoid It |
| Lack of clear business justification for all IT decisions | Retain a clear audit trail for Design Rationale through a fit-for-purpose framework that leads from Design Objectives->Design Rationale->Business case->Executive sign-off. |
| “Package-Think” | These exercises are almost always about more than a package, there are almost always other pieces required, needing the correct sequence of SMEs to cover all, not just the biggest and highest profile one. |
| Technology instead of Architecture | A solution architecture approach (rather than a technology beauty parade) is the only way to consider the implications on the design and technology decisions, and therefore deliver the best-fit technology portfolio for the solution with the most accurate and informed business case. Performing your 'as-is' analysis to surface the constraints and opportunities you have, and use of external SMEs for what’s possible. |
| Too Much Detail Too Early | Don't get bogged down in analysis for analysis sake in the early stages. Get enough information to understand enough to make a decision rather than know everything in detail. An 80/20 approach will identify the hot-spots. Focus down on areas that will deliver the most benefit. Move to the detail when the way forward has been agreed. |
| Focusing on the First Step | A balance of ‘art of the possible’ with ‘what needs to be fixed’ is necessary to design a solution which meets the requirements, but also delivers the business case through its life. Generally this requires that as well as agreeing objectives and design principles, the early phases also need to collect the hypotheses on what needs to be fixed, whilst of course doing the necessary identification of the 'as-is'. |
| Wish List | There is always a great temptation to use a transformation design exercise as a means to fix bug-bears which can colour / mitigate the value of the transformation. These quite likely need to be recorded, but the process must manage them so they don’t dominate. Not everyone likes the word 'strategic', but here it is important. |
| Reinventing the Wheel | Use best-practice 'off-the-shelf' processes as a design input, and try to stay vanilla (minimising customisation to where it's really needed for good business reasons that can't be standardised) to minimise IT costs and maximise efficiencies. |
| Waterfall | To avoid a sequential ‘waterfall’ where the outputs of one team become simply the input to another (with the inadequacies & risks that carries). The process needs to be iterative to repeatedly test assumptions, consider implications & and refine the design. |
| Lack of joined up working between IT and the Business | The work-streams need to work together to mutually inform each other, and to generate the cross-functional buy-in. Of course the IT solution will not drive the to-be business processes and operating model, but it will be an influence on them - unless you believe that what is available and what is achievable doesn't influence what is feasible and deliverable. |
Technorati Tags: Business Transformation Enterprise IT Business-IT Alignment IT Excellence Solution Architecture Enterprise Architecture EA
posted by Sam Lowe at
12:36 am
10 Comments:
you forgot :-
1) Lack of clear program organisation.
2) Staffing the project with people who you can afford to lose from the business instead of your good people.
3) Lack of ANY ROI or business case.
4) A plan that has not been resource constrained.
5) Lack of aligned project deliverables.
6) Padding the plan so the SI can make the most money from the cheapest resources.
7) No effective project reporting against deliverables that have also not been clearly defined.
8) Having project managers from the business who have never ever managed a project of any type.
That should be OK for starters.
By
Owen Pettiford, at 12:58 pm
Absolutely, good additions.
Although you've come at it from a slightly different angle - yours are mostly project planning and management pitfalls as opposed to my list which were mostly approach and ways-of-working pitfalls. Of course you need to consider both.
By
Sam Lowe, at 4:44 pm
I'd lob in architecture over technology as another challenge. Where the work disappears into a theoretically perfect architecture which ignores the actual technologies available, somewhat impressively this tends to alienate both the business and the technologists.
Linked to this would be the famous "delivery by powerpoint" approach to technology change. Lots of simplistic pictures and statements but no real meat on the bones, leading to an organisation that has a clear split between the "change-IT" and BAU-IT.
By
Steve Jones, at 8:48 pm
True, although you need an architecture-driven technology approach at such an early stage if you are going to be able to work out how the new potential technology options will:-
-work with each other
-work with the existing or planned technology, systems etc
-work over the life expectancy (beyond the immediate deployment)
but as you say, at the same time the architectural-approach has to execution-minded and technology-informed otherwise it is pointless academic debate and you will eventually disappear up your own analysis.
So the difficult question always is, as Owen's asked, How much architecture is enough??
By
Sam Lowe, at 10:26 pm
Ah, what you're talking about there is the architecture of the architecture.... ;-)
And the answer is "it depends", isn't it?
My suspicion is that a large factor driving the answer is the potential volatility of the business activity/ies which is/are being transformed
By
Neil Ward-Dutton, at 10:03 pm
so how about some of the softer/boardroom issues that probably contribute most to BT fiascos...how would for example someone here approach a scenario wherein the 'executive sign-off' mentioned right at the top of Sam's list is itself questionable..someone approving a project budget not because the new product or service is actually needed but because he/she needs more resources to do existing housekeeping ?plenty more such examples but maybe someone can comment on this one?
By
Anonymous, at 9:45 pm
I suppose there's no real accounting for hidden agendas, and in such cases these projects can be considered doomed for failure.
If you are dealing with knowledgeable stakeholders who have a realistic grasp on what the technology elements will deliver as part of a larger business transformation, you're moving in the right direction.
One of the greatest pitfalls comes from the user population, who should never be under-estimated in introducing the most challenging hurdles. Users are often the most resistent to change as they are the ones that are impacted the greatest. Despite having user representation on any steering committee, it is infeasible to capture the underlying concerns that are associated with any form of business change (ranging from loss of job/responsibilities to additional responsibilities).
This then begins to fall within the realms of psychology. However, would you then consider this as the responsibility for business consultants or architects? How can the new technology be introduced to reduce the impact (i.e., small steps rather than big-bang)?
But I suppose this can be addressed through the point raised about closer alignment between the business and IT streams... but the first step in achieving this is to understand each other which can sometimes be a challenge in itself.
Something else that has just occured to me is the need to be mindful of the external environment. Given the time frame of some of these transformation programmes, monitoring the external environment is essential to ensure that the changes being implemented remain valid and appropriate. In commercial environments, such changes form a foundation of delivering some element of competitive advantage so it is critical to ensure that alignment with the business strategy is maintained.
- RD
By
Anonymous, at 1:16 am
I guess the role of an effective governance function needs mention here.you dont want a 'rubber stamp' governance council that lacks the requisite authority, financial clout or worse a clear mandate/terms of reference.Neither do you want micromanagement in the name of governance.what you definitely dont want is ambiguity about the difference between EA/strategy/governance !
Semantics apart,the point here is that there needs to be some effective discipline that can constantly validate and steer the implementation of an IT strategy.
By
Anonymous, at 1:37 pm
Hi!
Indeed an interesting perspective on IT and EA strategy.
May I ask who is your source and where is your data?
Best wishes,
Peter Sjoelin
By
Anonymous, at 9:04 pm
Peter, just myself from my own observations in practice.
Regards,
Sam.
By
Sam Lowe, at 1:13 pm
Post a Comment
via Haloscan
<< Home