Implementation Roadmap
•
3 recomendaciones•2,435 vistas
Building a Roadmap for Implementing SocioTechnical Change - Notes on Accommodation, Assimilation and Maturity
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (19)
Similar a Implementation Roadmap
Similar a Implementation Roadmap (20)
Más de Richard Veryard
Más de Richard Veryard (20)
Último
Último (20)
Implementation Roadmap
- 1. Building a Roadmap for Implementing SocioTechnical Change Notes on Accommodation, Assimilation and Maturity Richard Veryard September 2012
- 2. Implementing something somewhere Something … Somewhere … Suppose we wish to implement … into some system or A technology environment A product or platform An organization, which may be distributed or federated A solution (to some problem or requirement) An ecosystem A strategy or policy A community, which may be homogeneous or A complex change heterogeneous A concept (e.g. “excellence”, “org intelligence”) Let’s call this “the target”. Let’s call this “the solution”
- 3. Implementation requires Adaptation Accommodation Assimilation The target must The solution must be accommodate the assimilated into the solution. target. Therefore there must be Therefore there must be some managed change to some managed change to the solution. the target. E.g. detailed solution E.g. organizational development or development customization
- 4. Accommodation Organizational Intentions Organizational Realities Plans, policies, strategies, People, behaviour, beliefs, expectations, tactics, budgets, skills, resources, mechanisms, contractual commitments, software, tools, interfaces, espoused procedures, formal actual organization structure organization structure reality gap
- 5. Assimilation Solution as built Solution in use Devices, support systems (vendor Local instructions & guidelines, hotline), general interfaces, local interfaces, working training packages, standard practices, fixes and work- (reusable) solution templates arounds, user templates, usability gap
- 6. Adaptation = Assimilation plus Accommodation assimilation Solution Target accommodation
- 7. Implementation Endpoint: Maturity A mature solution … … in a mature target Solution as Organization Designed aligned Intentions aligned aligned Solution aligned Organization in Use Reality
- 8. So this gives us five streams of managed adaptation/adoption Direction and Coordination Solution as designed/built maturity Solution in use Organizational realities Organizational intentions time
- 9. Each stream can be managed separately Different management concerns Different specialist skills (technical, organizational, political, cultural) Different timescales, characteristic rates of change
- 10. Multiple Time Horizons Hours Install software Days Train staff Months Pilot project, Renegotiate incentives Budget cycle Years Technological maturity Cultural change Decades Technological lifecycles Deep cultural change
- 11. Management Hierarchy months years decades days months years decades hours days months years hours days months hours days
- 12. Two Perspectives Target Management Perspective Supplier Perspective Can we implement this Can we deliver this solution? solution? How should we How should we deliver implement this solution? this solution? How much will it cost How much will it cost us? overall? How much will it cost the How long will it take? customer overall? How long will it take?
- 13. Implementation Roadmap implies a Maturity Model SOA example NCW example Command and Control Self- Traditional Collaboratio Synchronizatio n n Shared Awareness 3 4 Business Consistency & Design Developing Information Situational Sharing Time to Market Awareness 1 2 Cost Reduction Risk Reduction Organic Sources 0 Source CBDi Source: CCRP
- 14. Capability Levels Readiness Maturity Null No relevant capability identified Learning Excellent Some relevant initiative or trial identified Adequate Improving Sufficient to get started Improving Getting more efficient and/or effective Learning Adequate Excellent Null Enabling maximum performance. Must Should Could Source: CBDI Forum
- 15. Two Dimensions of Capability Maturity <<C2 Maturity Level>> Agile Enterprise <<C2 Maturity Level>> Agile <<C2 Maturity Level>> Collaborative <<C2 Maturity Level>> Coordinated <<C2 Maturity Level>> Deconflicted <<C2 Maturity Level>> Conflicted 15 <<Scope>> <<Scope>> <<Scope>> <<Scope>> <<Scope>> Fragment Process Domain Enterprise Ecosystem
- 16. Outcome Distribution Differentiation Intense usage by selected Deep Full users Usage Usage Integration Initial Broad Usage Usage Occasional Outcomes usage by many users
- 17. Capability Stepping stone Phasing capabilities Set of capabilities needed to support proper usage by selected users Differentiation Focus on integration Deep Full (=joining things up) Set of capabilities needed Integration Initial Broad (Deep Usage = Applied) Outcomes to broaden the user base across the extended enterprise Focus on differentiation (=supporting diversity of Set of capabilities needed to get started usage across different (Initial Usage = Early Learning) classes of user) (Broad Usage = Enterprise)
- 18. Capability Dependency Quantity of Usage Phase 2 Citizen-Centric Integration Diversity of Applications Value of Usage (“Joined-Up 18 Experience”) Understanding Citizen Process Integration of Portal Semantics Supply-Side Integration Outcomes Integration Outcomes Knowledge about usage Technical Rich Integration Content (WSRP?) User Differentiated Popular Textual Awareness Feedback Support Content Solution Support for Loop (“user-friendly”) Funding Special Stakeholder Groups User Support (Help Desk) Communication “My Page” Customization programme Profiles Additional (Marketing) Solutions Funding Stakeholder Broad range Strategy Citizen Identity and Identification of content Authentication Phase 1 Phase 3
- 19. Phasing and Milestones (SOA Example) Adoption Fragment Project Domain Enterprise Ecosystem Phases Committed Committed Status Interested (Domain) (Enterprise) Expertise Isolated Shareable Widespread Assets Low Medium High Activities Volume Volume Volume Standard Provisional Adopted Optimized Practices Few Minority Minority Majority Projects Pilot Stand-Alone Integrated Integrated
- 20. Evolutionary Adaptation The Solution Changes Over Time The Taregt Changes Over Time Evolution of Learning by doing requirements - what we Ongoing interaction with really want countless other change Demanding solutions – programmes and what the solution requires initiatives from us
- 21. Moving the GoalPosts Maturity as Sociotechnical Congruence Socio … … technical Actual Technology Organization in Use Envisioned Installed Organization Technology
- 22. Balancing the Elements of Implementation based on ancient Chinese thought Fire represents drive or purpose The Implementation Program Fire champions the benefits of the solution Earth represents the raw material, networking, social infrastructure. The Program Office acts as a Center of Wood Earth Excellence Metal represents formal structure Custodian of architectures and processes Water represents intelligence, insight Identifying and promoting opportunities for sharing, collaboration and synergy. Water Metal Wood represents planned activity A Program Office to performs programme management and coordination functions.
- 23. … based on ancient Chinese thought which leads to a cycle of workshops Benefits Agree business case Motivation Support Agree the transition organization, including Project(s), Program Office and Steering Committee. Provision tools and Delivery Support infrastructure. Growth Network Structure Adopt and customize formal structures (Reference Architecture, Process) Understanding Opportunity Architecture and planning Delivery Understanding Formal Opportunity Structure Benefits Review ROI from implementation activity, approve next iteration
- 24. History This framework was first developed in the late 1980s for implementing software development tools and methods (Information Engineering and associated CASE tools) into large organizations. The framework has also been used for subsequent technologies including SOA. The theoretical framework has been presented at a number of conferences including IFIP WG 8.6 (1994).
Notas del editor
- User perspectiveFrom the perspective of the user organization, technology is usually acquired as the solution to some perceived problem or opportunity. This often follows a requirements engineering process, in which indeterminate wants are converted into defined needs, and a business case is constructed to support investment and/or procurement judgements.Procurement and implementation are often regarded as separate concerns. In the worst case, this may result in the procurement of solutions that turn out to be completely unimplementable. More frequently, attempted cost savings in the procurement process can result in significant cost escalations in the implementation process.Existing methods for requirements engineering, business case formulation and procurement are weak in methods for analysing implementability and for optimizing the total costs of acquisition and implementation. For a given solution, the main questions from the user perspective are as shown above:Users will want to compare several alternative solutions against these four criteria. They will also want to consider interactions between technologies, since they are unlikely to have the luxury of implementing technologies one at a time. Vendor perspectiveFrom the perspective of the vendor, technological products are usually developed to provide a solution to some class of perceived problems or opportunities, in some class of potential user organizations. This may follow a market requirements survey (demand pull), or may emerge from research and development (technology push).During the planning, development, marketing and selling of the solution, the vendor needs to think about the deliverability and implementability of the solution. Once the solution is developed and sold, the vendor may need to think about the actual method/approach of delivery and implementation. For a given type of user organization, main questions from a vendor perspective are:Vendors also wish to develop generic approaches, so that they can reuse tactics, materials and skills across many customers and prospects.
- Capability Depth“These C2 maturity levels are scalable, in that they can be applied to groups of individuals and organizations of any size.”Source: Maturity Levels for NATO NEC Command, Dec 2006Capability Breadth“A scope based approach to maturity is the most useful determinant of maturity that decomposes well to each of the stream views because services are increasingly useful as they are used more widely, and conversely expanding the SOA scope beyond traditional organizational boundaries is without question the hardest thing to achieve “Source: CBDI Forum, Fine-Tuning the SOA Maturity Model, April 2007
- OutcomesOutcome DistributionIn many situations, outcomes are not just simple binary events, but can be quantified. It is often useful to distribute outcomes across two dimensions – breadth and depth. Breadth refers to the scale, quantity and diversity of the outcome. For example, the penetration of a given technology across a target user population. Given an assumption of heterogeneity across the target population, greater breadth typically requires some degree of differentiation. Depth refers to the quality and intensity of the outcome. For example, the ability of some sectors within the target population to achieve maximum exploitation of a given technology. Given an assumption of complexity in the systems architectures, greater depth typically requires some degree of integration (which may be physical or virtual),