Monday, May 13, 2013

What are the potential risks in EA practice?

Improper analysis/knowledge of existing components in the system and lack of understanding of their interfaces to extend and re-use.


EA project has a high rate failure rate, due to the scope and complex nature, as you know, walking in the bush, you need to know about potential risks. Not pitfalls. Pitfalls are often hidden and not easy to identify. Risks could be very obvious sometimes, For instance, 
  1. Incorrect understanding of business strategy
  2. Incorrect translating from strategy to architectural design
  3. Incorrect prediction of the future business
  4. Possible the decrease in productivity in the short run
  5. Incorrect technology stacks selection. 
  6. Improper understanding of non-functional requirements.
  7. Not giving adequate importance to security aspects, which potentially expose system to Vulnerability attacks. 
  8. Improper analysis/knowledge of existing components in the system and lack of understanding of their interfaces to extend and re-use.
  9. Not balance well on EA aspiration & EA practicality 
  10. Lack of an effective set of metrics to measure delivery. 
  11. Time to value or no value delivered or out of date value
  12. Be focused, have the end in mind, why are you engaging in an EA project. 
  13. Do EA for EA's sake 
  14. Lack of executive sponsorship 
  15. Lack of strong internal program leadership 
  16. Lack-focus on adoption process & roll-out plan
  17. No focus on delivering quantifiable business value 
  18. No leverage the wider data team & process
  19. Lack of flexible tools
  20. Too focused on IT
  21. No mandate, no clear rollout plan 
  22. Modeling the Universe’ 
  23. unable to articulate the value proposition of EA 
  24. confused about the purpose and scope of EA (business vs. technical investment decision) 
  25. unable to communicate effectively with stakeholders 
  26. unable to execute in an appropriate risk management approach that matches the effort (investment) with return
  27. Lack of EA people with broad technical skills (business, applications, infrastructure) and soft skills too (communications, negotiation, presentation, management, etc) 
  28. Confidentiality prevents business plans being fully available to the EA team
  29. Business interlock hampered by "go-betweens" (claiming to represent the business leaders but actually promoting their own or others' ideas). 
  30. Business strategy and plans are not fully formed....(and no one wants to hear this from the EA team !)..i.e. insufficient input...and this can lead to "speculative" filling in... 
  31. Lack of good executive sponsorship i.e. an owner with clout in the organization and buy-in from other stakeholders 
  32. participants being fearful of negative impacts on their function (silo) e.g. job losses and becoming defensive as a result... 
  33. Separation of duties & regulatory separation of functions prevents full co-operation 
  34. Consultants, brought in by some affected functions, pursuing an agenda to bring them follow-on work. 
  35. Internal politics....business functions, people with their own agenda's (take over the company) jockeying for position...up to board level...and causing a distraction! 
  36. Too much influence of some suppliers or partners. IT vendors with their "product maps" which they like to market as EA ! 
  37. Inertia "that's the way we've always done it". 
  38. Too much focus on EA tools and frameworks....particularly from consultants...... 
  39. Disconnect with pre-existing EA-like functions; many companies have a semblance of EA but called something else
  40. "Waterfall" type of EA, lack of Agile practice - Incremental-ism, Improvement   and Iteration. 
Further Lesson: If the stakeholders know what's being presented, the buy-in will be made smoother. Give the stakeholders to have their say and take them into consideration but do not let them undermine the findings. The project may fail--
    • If you assume that the executive or manager actually knows what he wants or needs. 
    • If you assume that the user knows what she could have and what she should have. 
    • If you assume that the executive knows what he DOES have. 
    • If you assume that the user actually knows what they have to do to achieve the strategy. 
    • If you assume that there IS a strategy.
    • If you assume that the strategy is actually appropriate and good. 
    • If you assume that a 'balanced scorecard' will mean the strategy is good. 




0 comments:

Post a Comment