Documente Academic
Documente Profesional
Documente Cultură
Enterprises the world over spend billions of dollars on technology enablement of business functions. A significant portion of those dollars end up creating suboptimal solutions. Most IT project problems are rooted in ambiguous business definition, churn in requirements gathering, scope creep beyond a minimum marketable feature set, wild cost guestimations, not planning for interdependencies, and a lack of strong governance. Everyone agrees that a sizeable portion of IT projects fail to meet or under deliver on expectations. However, while there is agreement that most technology projects end up in trouble, the business and technology teams disagree on why IT projects fail. Several research studies have shown that the larger the budget and the longer the timelines, the greater the cost and schedule overruns, and the poorer the outcomes for IT projects. Business and IT professionals, in fact, believe that 75% of IT projects are doomed from the start (Figure 1).
Business
Why does this button cost a million dollars to build? Each BU wants different changes to the same thing at different times Business is incapable of thinking through the implications of their small tweaks All business needs are urgent we are drowning in unnecessary technical debt
IT
We need to go to market in two quarters. Why does a small feature take so long to deliver?
How much detail do you need to build something? Weve already provided volumes of documents
I cant wait for other groups in the firm to agree to a path forward. Why not build for us and then add on stuff for others?
Things that can go wrong and those that shouldnt go wrong, always do!
Depending on the maturity of a firms people and processes, large transformation projects and programs may suffer from many of the following issues. Challenges Project and organizational goals unclear Scope not well understood Lack of clarity in business requirements Constantly evolving needs and requirements Multiple projects needing/building similar overlapping capabilities Overlapping capabilities create a complex web of interdependencies Time to market considerations trump all others Thinking is encumbered by current system constraints rather than capabilitybased future evolution, especially given the complex interdependencies that are hard to untangle Focus on User Interface rather than user experience (UXD) Skill and role mismatch Lack of balance between content and coordination
What happens if some or all of the challenges afflict your enterprise projects and programs? Implications Disjointed strategy, organizational goals, and execution Scope creep due to ambiguity of deliverables Increased complexity and cost due to lack of reuse resulting in unnecessary redundancy of capabilities Enablement of convoluted processes rather than reengineering of processes for the future Accumulation of technical debt due to unnecessary expediency and lack of rigor in architecture and design Regular cost overruns and project delays Suboptimal solution delivery and stakeholder dissatisfaction
2. Distill the strategy into a succinct target operating model o If the firms strategy resides in an ivory tower, it does not help the programs or projects downstream. It is essential to translate the high level business motivation into a target operating model. The target operating model creates a blue print of the future state and allows business to make the right strategic choices to improve the way the organization, business processes, IT and governance are structured and managed.
3. Focus on the What first focus on the capabilities o Business capabilities are the foundational layer of an enterprise. Business capability modeling represents a stable description of what a business does (capabilities) to reach its objectives, instead of a dynamic description of how it does it (processes). A capability map or model decomposes what a business does into a granular, hierarchical structure. A capability model that is decomposed to a level one or two captures a 30,000 foot view and mostly works as wall art. It is essential that capabilities are defined to be granular (typically level 4-6), mutually exclusive, collectively exhaustive and individually a whole at each level of granularity. Also it is paramount to capture rich content and context for these capabilities. The capability semantics will help define the business services, which in turn will inform and influence the coarseness and modularity of the IT services. The MODAF (Ministry of Defense Architecture Framework) SOV (Service Oriented Views) provides a great exposition on how to transition from Capabilities to IT services.
4. Foster the discipline of composition and capability reuse o More often than not, projects and product functionality are developed in silos. Instead, in the new paradigm, a product or platform owner can compose a new product or project by leveraging the underlying capabilities as Lego blocks. Since capability maps are cumulatively exhaustive, it should be possible to describe each project and product fully using the underlying capabilities and how these capabilities are expected to be used. Since the underlying capability map is mutually exclusive, mapping projects and products helps quickly identify overlaps across them, fostering reuse, minimizing replication, lowering cost, engendering agility, and speeding time to market (Figure 3).
Business
Project 8
IT
Product 1
Overlap can be easily identified and managed, avoiding unecessary redundancy and fostering reuse
Program 4
5. Define requirements as a way to evolve capabilities over the long haul o Some of the constant challenges in requirements gathering and analysis are lack of consistent granularity and detail, and disparateness of requirements with hard to decipher interdependencies across projects. By gathering capability-specific instead of project-specific requirements, interdependencies can be easily spotted and the granularity and required detail becomes immediately obvious. This small change can go a long way in streamlining roadmaps and eliminating churn.
6. Link funding to multi-year capability maturity, not siloed projects o Demanding change at the execution layer will only yield minimal dividends if it is not driven by the top and linked to tangible budgets and resources. Funding capability refinements and evolution over piecemeal projects can help ensure that strategy drives execution with complete short, medium and long-term view of expected outcomes.
7. Rationalize the application portfolio o Rationalizing the application portfolio can significantly reduce IT complexity. The best approach to do this is using lenses to evaluate the application footprint across capabilities and quickly identify overlaps. Lenses can also help assess each application across key dimensions such as business value, customer affinity, maintenance and support costs, and architecture compatibility.
8. Layer in process and data o Once the capabilities are defined and the landscape mapped and simplified, it is important to understand how things work or should work. At the highest level, one can start with Michael Porters value chain concept to understand the key demand and supply drivers and flows. Stakeholder centric value streams, process models and customer journey maps can further help communicate the business processes and workflows.
9. Monitor and measure against KPIs o Some is not a number, soon is not a time. It is essential to set up, monitor and measure granular success metrics and performance indicators across cost, timeliness and quality of each area you want to make progress against. KPIs have to be granular enough to quickly identify and address any problems. If possible, key metrics should be benchmarked against peers to help provide a point of comparison and highlight areas of opportunity.
10. Establish a capability-centric organization design o The pinnacle of this approach is structuring the organization around capabilities, supported by communities of practice and centers of excellence. While it is easier said than done, at least for core capabilities a notional capability-centric organization model can effectively complement the rest of the traditional structure.
Summary
It is possible to align business and IT around a common framework and language, link execution to strategy, and optimize the IT landscape. It takes leadership, a holistic framework, and a disciplined implementation plan to make the transformation endeavor a success. A capabilities-based approach can provide the much needed bridge between business and IT. Heres how you can get started: Secure executive buy-in and support Unless the top level support to a better way is not strong, the changes will be peripheral and impact will be minimal. Showcase small wins prior to firm-wide roll out Avoid boiling the ocean. Pick a highly visible project and celebrate the win. After refining the approach with the lessons learnt, move forward cautiously. This is an evolution, not a revolution - The capabilities-based framework is not a rip and replace method. It is an evolution of various past frameworks and approaches. You can mix it and match it with different ideas for example, lean manufacturing, extreme programming etc. Get training and change management right Executive fiat does not generally work in fostering inherent and lasting change. Provide adequate training and support throughout the process.
If you are able to encourage your team to adopt the capabilities-based framework to enterprise transformation, you will see: A common language between business and technology Better alignment and shared vision Reduced requirements churn Capability evolution, rather than project focus Significantly lower IT complexity Focus on composition and reuse Lower cost structure and faster time to market Reduced complexity by avoiding application proliferation Global optimization rather than local optimization in silos
To make your Enterprise Agile and Optimize your IT, get started with CAPSTERA today.
Contact: Satya S. Iluri, Founder and CEO Capstera www.capstera.com Twitter: @Capstera Email: Satya.iluri@capstera.com