Alan McSweeney, profile picture
Uploaded byAlan McSweeney
PPTX, PDF1,733 views

Solution Architecture and Solution Acquisition

The document outlines a structured approach to solution acquisition that emphasizes the importance of solution architecture from the beginning to better understand the required scope of acquired solutions. It highlights current trends such as a shift towards external and cloud-based solutions, increased complexity, and the lack of proper governance in the acquisition process, which contribute to poor outcomes. Key objectives include enabling efficient business processes, providing suitable choices, and ensuring successful implementation through collaboration and effective management of business change.

Embed presentation

Downloaded 294 times
Solution Architecture and Solution Acquisition Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616
Introduction And Scope • This describes a systematised and structured approach to solution acquisition/procurement that involves solution architecture from the start • Involving solution architecture means that the true scope of both the required and subsequently acquired solution are therefore fully understood • By using such an approach poor solution acquisition outcomes are avoided February 2, 2020 2
Solution Acquisition Demands, Trends And Outcomes February 2, 2020 3 More External Solution Acquisition and Less Solution Development More Hosted/Cloud Outsourced Solutions and Fewer On- premises Options Slow/ Unskilled/ Understaffed IT Solution Acquisition Informal/Dark/ Shadow IT Solution Acquisition Fragmented IT Solution Landscape Lack of Knowledge, Certainty and Control Over Solution Lifetime Costs Solution Scope Not Known or Defined at Acquisition Stage Digital Initiatives Extending IT Solutions to Outside the Organisation Greater Solution Complexity and Data Interoperability Needs More Complex Solutions Available Poor Overall Solution Acquisition Outcomes Solution Acquisition Not Aligned With Strategy Sourcing Objectives Increased Security and Data Integration Concerns Absence of Solution Architecture Involvement in Solution Acquisition Absence of Solution Architecture Involvement in Solution Acquisition
Solution Acquisition Demands And Trends • More External Solution Acquisition and Less Solution Development – greater tendency to buy rather than build • More Hosted/Cloud Outsourced Solutions and Fewer On-premises Options – solution suppliers are changing their delivery model resulting in more solutions are available in cloud/outsourced deployment model rather than being available to install on-premises • More Complex Solutions Available – more complex solutions are available from suppliers, especially in the areas of data and integration • Digital Initiatives Extending IT Solutions to Outside the Organisation – organisation digital transformation involves implementing solutions to a user population outside the organisation • Solution Scope Not Known or Defined at Acquisition Stage – solutions are acquired without their full scope being defined leading to lack of control over cost, resources and time • Absence of Solution Architecture Involvement in Solution Acquisition – solution acquisition proceeds without formal solution design with business users engaging directly with solution suppliers, leading to lack of control over cost, resources and time • Greater Solution Complexity and Data Interoperability Needs – solution complexity is increasing especially in the areas of data, integration and security • Slow/Unskilled/Understaffed IT Solution Acquisition – the solution acquisition skills of the organisation are not keeping pace with solution acquisition trends February 2, 2020 4
Solution Acquisition Outcomes • Informal/Dark/Shadow IT Solution Acquisition – business functions bypass formal solution acquisition processes and go directly to solution suppliers without controls over cost, resources and time • Increased Security and Data Integration Concerns – multiple separate solution acquired without integration and security requirements being incorporated into solution design leads to additional work and risk • Poor Overall Solution Acquisition Outcomes – solution acquisition outcomes are poor in terms of solutions meeting business requirements and cost and delivery overruns occur • Fragmented IT Solution Landscape – solutions are acquired without an overall architectural context leading to a fragmented and poorly integrated solution landscape that is complex and costly to support and operate • Lack of Knowledge, Certainty and Control Over Solution Lifetime Costs – there is no real knowledge about the long-term solution costs • Solution Acquisition Not Aligned With Strategy Sourcing Objectives – solutions are acquired without adherence to any solution strategy or strategic supplier management leading to multiple February 2, 2020 5
Solution Acquisition Demands, Trends And Outcomes • In summary: − More packaged/product/service-based solution acquisition activity − Increasing trend of solutions hosted outside the organisation − Increasing solution complexity − Increasing direct sourcing of solutions without formal acquisition process, including solution validation − Lack of knowledge of solution lifetime costs leading to increased solution acquisition and ownership costs − Poor solution acquisition outcomes and getting worse February 2, 2020 6
Reasons For Solution Acquisition • A need for a solution to a business problem, need or opportunity has been identified that is best met, for cost, time, flexibility and other reasons, by a solution acquired from a external supplier • Solution can be entirely packaged or customised and implemented on organisation infrastructure or delivered as a service • Axes of solution: − Degree to which solution is packaged or customised − Whether the solution is implemented on-premises or delivered as a hosted service − Whether the solution is supported in-house or by an external service provider February 2, 2020 7 Packaged Solution Customised Solution Outsourced/ Hosted Hosted In- House Externally Supported Internally Supported
Solution Acquisition And Implementation Failure Keeps Happening • Solution implementation failure keeps happening despite years of work on attempting to improve outcomes • For example, Standish Group figures on project outcomes from 1994 and 2015 • Most solution implementation projects still cost more, take longer and deliver fewer benefits than expected or planned • Other solution delivery statistics show higher rates of failure February 2, 2020 8 Survey Year Projects Succeeded Projects Challenged Projects Failed Projects Failed or Challenged 2015 36% 45% 19% 64% 2014 36% 47% 17% 64% 2013 41% 40% 19% 59% 2012 37% 46% 17% 63% 2011 39% 39% 22% 61% 2009 32% 44% 24% 68% 2006 35% 46% 19% 65% 2004 29% 53% 18% 71% 2000 28% 49% 23% 72% 1998 26% 24% 28% 52% 1996 27% 33% 40% 73% 1994 16% 53% 31% 84%
The Contributing Elements Of Poor IT Solution Acquisition 02 February 2020 9 Lack of IT Solution Procurement Skills and Experience Business Bypassing of Procurement Processes and Standards Slow Procurement Process Lack of Compliance with Strategic Sourcing Standards Inaccurate Information on Solution Requirements Unmanaged Solution Supplier Risk Poor Procurement Outcomes Poor Solution Outcomes Causes Delays in the Solution Procurement Leading to Results In Leads To Contributes To Adds To Causes Leeds To Causes
Sources of Solution Acquisition Challenges and Problems • If you know the sources of problems then you can mitigate their impact February 2, 2020 10 Sources of Acquisition Challenges and Problems Hidden, Unforeseen or Ignored Costs Ineffective Delivery Governance Contract Rigidity and Inflexibility Ineffective Contract Planning Required Solution Functionality Not Known or Defined Poor Solution Supplier Governance and Controls
Sources of Acquisition Challenges and Problems • Hidden, Unforeseen or Ignored Costs – actual costs that are incurred during solution delivery are not identified or are ignored during the solution acquisition process • Ineffective Delivery Governance – solution delivery controls are weak and not fit for purpose • Contract Rigidity and Inflexibility – solution delivery contract does not allow for change • Ineffective Contract Planning – the acquisition process does not plan for the contract to deliver a workable and usable solution • Required Solution Functionality Not Known or Defined – the required solution is not known during the acquisition process • Poor Solution Supplier Governance and Controls – the controls around the solution supplier, the management of the scope of the solution and negotiation with the supplier are poor and weak February 2, 2020 11
The Scope Of The Acquired Solution • The scope of the acquired solution and the (implied or actual) work required to get the solution operational and usable involves components of some or all the following types: • Complete IT solution view requires that the true extent of the solution being acquired be known • An acquired IT solution never consist of just software or a service – there are always other solution components that contribute to the real solution costs – see later details on Solution Topography • Solution architecture involvement in the solution acquisition process will ensure that the likely solution cost components are identified February 2, 2020 12 • Changes to Existing Systems • New Data Loads • New Custom Developed Applications • Training and Documentation • Information Storage Facilities • Central, Distributed and Communications Infrastructure • Acquired, Configured and Customised Software Products • Sets of Installation and Implementation Services • System Integrations/ Data Transfers/ Exchanges • Cutover/Transfer to Production And Support • Changes to Existing Business Processes • Operational Functions and Processes • New Business Processes • Parallel Runs • Organisational Changes • Enhanced Support/ Hypercare • Reporting and Analysis Facilities • Sets of Maintenance, Service Management and Support Services • Existing Data Conversions/Migrations • Application Hosting and Management Services
Acquired Solution Components • The acquired solution will have many components of each of these types • The acquired solution may provide most of the required functionality but it will very rarely, if ever, deliver all • Knowing the likely solution components means the solution acquisition process is not proceeding blindly February 2, 2020 13
Solution (Cost) Components Types Solution Components Changes to Existing Systems Component 1 Component 2 Component 3 Component 4 New Custom Developed Applications Component 1 Component 2 Component 3 Component 4 Information Storage Facilities Component 1 Component 2 Acquired, Configured and Customised Software Products Component 1 Component 2 Component 3 System Integrations/ Data Transfers/ Exchanges Component 1 Component 2 Component 3 Component 4 Changes to Existing Business Processes Component 1 Component 2 Component 3 Component 4 New Business Processes Component 1 Component 2 Component 3 Organisational Changes Component 1 Component 2 Component 3 Component 4 Reporting and Analysis Facilities Component 1 Component 2 Component 3 Existing Data Conversions/Migrations Component 1 Component 2 Component 3 Component 4 New Data Loads Component 1 Component 2 Component 3 Component 4 Training and Documentation Component 1 Component 2 Component 3 Central, Distributed and Communications Infrastructure Component 1 Component 2 Component 3 Sets of Installation and Implementation Services Component 1 Component 2 Cutover/Transfer to Production And Support Component 1 Component 2 Component 3 Operational Functions and Processes Component 1 Component 2 Component 3 Component 4 Parallel Runs Component 1 Component 2 Component 3 Component 4 Enhanced Support/ Hypercare Component 1 Component 2 Sets of Maintenance, Service Management and Support Services Component 1 Component 2 Application Hosting and Management Services Component 1 Component 2 Component 3 February 2, 2020 14
Solution (Cost) Components • One of the key functions of an effective solution acquisition process and function is to know and be able to control solution lifetime costs • Knowledge of the solution cost profile is essential and necessary for successful cost control • You therefore need to know what will contribute to the solution lifetime costs • Solution architecture provides the structured approach to capturing all the cost contributors and knowing the true solution scope February 2, 2020 15
Solution Acquisition Process • Solution components contribute to the long-term solution cost − Even an apparently packaged solution will have many components – see later details on Solution Topography • To understand the financial impact of the solution being acquired you need to have a good understanding of its constituent components and their impact on costs February 2, 2020 16
Solution Components Contribution To Lifetime Costs • Solution components contribute differently to the overall solution cost profile over time, depending on the characteristics of the solution • Cumulative solution lifetime costs can be very substantial February 2, 2020 17
Planned And Actual Cost Gap Due To Inaccurate Solution Cost Knowledge • Inaccurate solution cost knowledge can have a significant impact on unforeseen and unplanned costs over the lifetime of the solution February 2, 2020 18 Solution Knowledge Cost Gap
As A Service Solution Costs • As-a-service pricing models change the way solution costs are incurred • Large recurring costs with unforeseen volume-based costs can lead to very large solution lifetime costs • Even for as-a-service solutions, other components will be needed, such as: − Access infrastructure − Data migration − Integration with other solutions − Support − Organisation and process changes − External backup and recovery February 2, 2020 19
Objectives, Principles And Success Factors Of Effective Solution Acquisition • Objectives – what is important to the solution acquisition process • Underpinning Principles – what supports effective solution acquisition • Success Factors – what contributes to solution acquisition February 2, 2020 20
Objectives, Principles And Success Factors Of Effective Solution Acquisition February 2, 2020 21 Principles Underpinning Solution Acquisition Objectives of Solution Acquisition Process Solution Acquisition Success Factors Enable Implementation and Operation of Business and Supporting Processes Improve Efficiency and Capability Enable Business Growth and Development Provide Choices and Options Select the Most Suitable Overall Solution Support Evidence-Based and Accurate Decisions Select Solution Based on Achieving Business Objectives Use the Most Suitable Solution Acquisition Process Establish Implementation Centre of Excellence Rapid Implementation Through Prototyping, Business Process and Organisation Change Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification Practical Pragmatic Achievable Expectations Continuing Joint Working Across Solution Delivery Team The Right Team With Significant Business Involvement and Commitment Maintain Focus on the Underlying Business Needs Extract the Maximum Business Value from the Acquired Solution Understanding of the Capabilities and Functionality of the Core Solution Management of Underlying Business Change
Objectives of Solution Acquisition Process • Enable Implementation and Operation of Business and Supporting Processes – the solution is being acquired to support the operation of new or existing business processes and their supporting processes efficiently and effectively, improving productivity and throughput, accuracy and consistency and reducing cost • Improve Efficiency and Capability – the solution acquisition must introduce new capabilities or enhance and improve existing organisation capabilities • Enable Business Growth and Development – the solution acquisition must enable the business to grow by enabling the delivery of new products and services or to protect existing business operations • Provide Choices and Options – the solution acquisition process must assess all realistic and achievable options to present choices to the solution acquirer • Select the Most Suitable Overall Solution – the solution acquisition process must result in the selection of the optimum option that balances potentially conflicting needs across solution stakeholders • Support Evidence-Based and Accurate Decisions – the solution acquisition process must use evidence-based assessment and evaluation approaches to eliminate bias and to provide an audit trail of decisions made February 2, 2020 22
Principles Underpinning Solution Acquisition • Select Solution Based on Achieving Business Objectives – the solution exists to either directly or indirectly enable the business meet defined objectives and the solution and its supplier should meet this flexibly and with the minimum of change • Use the Most Suitable Solution Acquisition Process – the degree of formality of and the structure of and number of stages in the solution acquisition process should be appropriate to the scale of the solution • Establish Implementation Centre of Excellence – solution acquisition should be supported by appropriately skilled and experienced personnel who can work productively and effectively and who are supported and enabled in their work • Rapid Implementation Through Prototyping, Business Process and Organisation Change – the solution acquisition process may need to validate solution functionality through prototyping and to define the changes in business processes and organisation structures • Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification – the core functionality of the acquired solution should be retained with as little modification as possible and necessary and the implementation activities should be designed to occur in parallel to reduce elapsed time February 2, 2020 23
Solution Acquisition Success Factors • Extract the Maximum Business Value from the Acquired Solution – the solution acquisition process should seek to get the solution operational as soon as possible with as little modification as necessary and with the appropriate business change needed to maximise value • Maintain Focus on the Underlying Business Needs – the solution acquisition need to maintain focus at all times on the business needs that are driving the process • The Right Team With Significant Business Involvement and Commitment – the team allocated to the solution acquisition process needs to have the necessary skills and experience, be supported in their work and to have the necessary participation from the business functions that will use the solution and the team needs to be supported in its decision-making • Continuing Joint Working Across Solution Delivery Team – the solution delivery team, including the supplier, needs to work together for the duration of the solution acquisition process • Practical Pragmatic Achievable Expectations – realistic and achievable expectations have to be defined and agreed based on what the solution and the acquisition team can realistically achieve • Understanding of the Capabilities and Functionality of the Core Solution – the capabilities and limitations of the solution need to be understood from the outset • Management of Underlying Business Change – effective solution acquisition will require organisation change without which the solution will not operate optimally – this change needs to be understood, accepted, supported and sponsored February 2, 2020 24
Objectives, Principles And Success Factors Of Effective Solution Acquisition • Can be used as a checklist to assess the likely success of the solution acquisition project or to identify gaps that need to be filled to ensure successful outcomes • Recognise and focus on what is important February 2, 2020 25 Enable Implementation and Operation of Business and Supporting Processes Improve Efficiency and Capability Enable Business Growth and Development Provide Choices and Options Select the Most Suitable Overall Solution Support Evidence-Based and Accurate Decisions Select Solution Based on Achieving Business Objectives Use the Most Suitable Solution Acquisition Process Establish Implementation Centre of Excellence Rapid Implementation Through Prototyping, Business Process and Organisation Change Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification Extract the Maximum Business Value from the Acquired Solution Maintain Focus on the Underlying Business Needs The Right Team with Significant Business Involvement and Commitment Continuing Joint Working Across Solution Delivery Team Practical Pragmatic Achievable Expectations Understanding of the Capabilities and Functionality of the Core Solution Management of Underlying Business Change ObjectivesPrinciplesSuccessFactors
Solution Topography • The to-be-acquired solution will need to operate in and co- exist with an existing solution topography − Other existing solutions that it must interface with − Organisational processes, structures, standards and regulatory framework • The solution acquisition process needs to be aware of and take account of this wider solution topography • This is true even for as-a-service solutions February 2, 2020 26
Solution Topography February 2, 2020 27 Extended Solution Landscape With Integration With Other Solutions Individual Solution Landscape Business Process and Organisation Structure Common Data Architecture Common Security and Regulatory Compliance Architecture Common Enterprise Architecture Standards Common Financial Management Processes and Standards Common Service Management Processes and Standards
Solution Topography • Irrespective of whether the solution is hosted inside or outside the organisation, it will still need to operate in a solution topography consisting of a number of logical layers February 2, 2020 28 Common Service Management Processes and Standards – solution support, service level management Common Financial Management Processes and Standards – solution cost and asset management Common Enterprise Architecture Standards – compliance with organisation technology standards and principles Common Security and Regulatory Compliance Architecture – integration of solution into overall security standards and operations Common Data Architecture – integration of solution data into the organisation data model and access to solution data, compliance with data regulations and standards Business Process and Organisation Structure – business processes and organisation functions that use the solution Extended Solution Landscape With Integration With Other Solutions – solution support, service level management, integration, data exchange Individual Solution Landscape – set of components that comprise the overall solution
Solution Topography And Cloud/As-A-Service Based Solutions • Cloud-based or externally hosted and provided solutions do not eliminate the need for the solution to exist within the organisation solution topography − The profile of the solution topography may change but it does not go away − The acquired solution is never the scope of the actual solution that will be implemented, operated and used February 2, 2020 29
Solution Acquisition Process Options And Paths • There are various formal techniques that can be used to identify realistic and feasible solution options and supplier • The process needs to be tailored to the size and extent of the solution being acquired • Small, inexpensive, tactical solutions do not need a big process • PQQ (Pre-Qualification Questionnaire) – select short-list of solution suppliers based on formal technical evaluation and previous experience • RFI (Request for Information) – general request for information on suppliers and their solutions prior to a more detailed request to a short-list • RFP (Request for Proposal) – formal solution procurement specification looking for detailed and fully costed proposals to meet detailed solution requirements • RFS (Request for Solution) – less formal process looking for suppliers to propose solutions to resolve a business problem or meet a business need February 2, 2020 30 PQQ (Pre- Qualification Questionnaire) RFS (Request for Solution) RFP (Request for Proposal) RFI (Request for Information)
Solution Acquisition And Public Procurement • The acquisition process for solutions in public sector organisations is more controlled and restricted than that which applies in the private sector − (Lots of) formal specification documentation − Precise timelines − Organised interactions with suppliers − Auditable selection and decision process • However, the same principles relating to solution architecture involvement in solution acquisition can and should apply in the public sector February 2, 2020 31
Public Procurement Options High-Level Overview February 2, 2020 32 Open Open Procedure Single stage tendering with public competition and no prior short-listing or pre-qualification. There can be large numbers of proposals to evaluate. Restricted Procedure Two-stage process with pre-qualification based on technical and experience factors. Short-listed suppliers are invited to submit proposals. Specific Circumstances Competitive Dialogue No standard, readily available solutions available or the required solution is innovative or highly complex or the requirements cannot be specified exactly or previous tender responses were not acceptable. Publish requirements and enter into dialogue with selected suppliers. Competitive Procedure with Negotiation Two stage process with prequalification based on technical and experience factors. Second stage follows the Competitive Dialogue approach. Innovation Partnership No standard, readily available solutions available. Establish innovation partnerships to perform research and development to develop innovative solution. The solution developed is then bought. Negotiated Procedure Without Prior Publication Limited application such as urgency, uniqueness or exclusive intellectual property.
Solution Acquisition Process Has A Cost For All Participants • Be aware of the cost that are being imposed on suppliers by your solution acquisition process • Suppliers incur a cost in engaging in solution acquisition − Cost and associated long solution acquisition process frequently leads to smaller (possible more creative, flexible, cheaper) suppliers self-excluding themselves from the process − Larger (and implicitly more expensive suppliers) can bear the cost of sale associated with the solution acquisition process • It is rarely the case of Publish It And They Will Bid • Unless a very good supplier bids with a very good product, the outcome of the solution acquisition process is all too frequently that either a good product supplied by an average supplier or an average product supplied by a good supplier wins − It rarely leads to the best solution being supplied by the best supplier • Be aware of the need to encourage suppliers and to grow and nurture a supplier ecosystem − Competitive tension between suppliers is in your interest − There is a necessary management overhead associated with this • Solution acquisition is not a fire and forget process February 2, 2020 33
Ineffective Solution Acquisition Has A Cost • Direct Incurred Costs − Project cost overrun − Project benefits shortfall • Indirect and Hidden Costs − Late delivery of required business capabilities − Additional resources, effort and other costs required to manage, maintain, operate and support the solution − Missed revenue from new services − Poor customer experience leading to lost revenue − Organisation loses competitivity − Lost ability to gain access to new technologies − Additional cost and/or lost revenue means other opportunities are not explored − Shorter than expected solution lifespan and the need to replace it earlier February 2, 2020 34
Hidden Costs Of Poor Solutions Are Much Greater Than Direct Costs February 2, 2020 35 Project Cost Overrun Project Benefits Shortfall Late Delivery Of Required Business Capabilities Additional Resources, Effort And Other Costs Required To Manage, Maintain, Operate And Support The Solution Missed Revenue From New Services Poor Customer Experience Leading To Lost Revenue Organisation Loses Competitivity Lost Ability To Gain Access To New Technologies Additional Cost And/Or Lost Revenue Means Other Opportunities Are Not Explored Shorter Than Expected Solution Lifespan And The Need To Replace It Earlier
Ineffective Solution Acquisition Has A Cost • The long-term consequences of ineffective solution acquisition can be very substantial and can reverberate for a very long time February 2, 2020 36
Strategic Misrepresentation During Solution Procurement • Deliberate distortion or falsification of information relating to solution acquisition costs, complexity, required functionality, solution availability, resource availability, time to implement in order to get solution acquisition approval • Caused by distorted incentives and lack of control, due diligence and governance • Two dimensions of strategic misrepresentation for solution acquisition approval − Acquirer-side • Deliberately understating costs to gain acceptance with unspoken understanding that costs will increase • Actual scope not accepted or intentionally concealed • Not willing to face reality of high costs or hiding the real costs to make decision-making or obtaining approval easier • Inflating costs or selecting unnecessarily complex and expensive solution option for status and prestige reasons • Overstatement or understatement of requirements • Unnecessary and uncontrolled complexity • Contending for limited resources or striving for an improved position − Supplier-side • Under-costed opportunistic solution proposals with calculated intention to increase revenue subsequently through aggressive change control and scope management after delivery initiation February 2, 2020 37
Strategic Misrepresentation In Solution Acquisition • Strategic misrepresentation in the solution acquisition process means: − Solution acquisition costs are underestimated − Solution benefits are overestimated/losses underestimated − Solution delivery risks are underrated − Solution functionality required is deficient − Solution delivery time longer than stated • Strategic misrepresentation is very real and its impact should not be underestimated or ignored February 2, 2020 38
Overlap Of Strategic Misrepresentations February 2, 2020 39 Acquirer-Side Strategic Misrepresentation Supplier-Side Strategic Misrepresentation Overlap of Strategic Misrepresentations
Overlap And Multiplication Of Strategic Misrepresentations February 2, 2020 40 Acquirer-Side Strategic Misrepresentation Supplier-Side Strategic Misrepresentation I deliberately underestimate solution scope, cost, complexity, time to get solution acquisition approval I deliberately underestimate cost, complexity, time to be awarded the solution delivery work Overlap of Strategic Misrepresentations I do not question your underestimated cost, complexity, time to get solution acquisition approval
Overlap Of Strategic Misrepresentations • Where the two types of misrepresentations coincide, solution acquisition can become very problematic – the impacts will be multiplied • Where strategic misrepresentation occurs on both sides of the acquisition process the solution outcomes will most likely be very poor February 2, 2020 41
Supplier-Side Strategic Misrepresentation • Competitive tendering process can result in opportunistic behaviour where suppliers deliberately exclude necessary solution elements and activities to reduce apparent solution acquisition cost • Suppliers can also reduce their (initial) fees to win the business, reducing the initial profits • Gives rise to a solution delivery environment where the supplier is constantly generating changes to increase revenue and profits • This gives rise to an inevitable and unavoidable chain reaction of cost increases, delays and worsening relationship between supplier and customer February 2, 2020 42 Deliberate Exclusion of Necessary Components Low Initial Work Rates Quoted Undercosted, Underscoped and Unprofitable Solution Acquisition Proposal Change Control By Supplier to Generate Additional Revenue to Increase Profitability Changes Required to Increase Scope to Include Necessary Components Drive- up Costs Solution that Is Overbudget, Behind Schedule, Less Functional, Delivering Fewer Benefits and More Costly to Operate
The Paradox Of Strategic Misrepresentation • Paradoxically, solutions that appear to have lower costs and significant benefits tend to those selected for implementation • So solutions with the largest cost underestimates and the greatest benefit overestimates appear to offer the greatest value • These are the worst solutions to implement but the most likely to be selected for implementation • Strategic misrepresentation acts as a compelling anti- Darwinian force promoting the survival of the least fit and least suitable but most misrepresented solution February 2, 2020 43
Other Factors Related To Strategic Misrepresentation In Solution Acquisition • Optimism Bias – belief in the strong likelihood of success and underestimation of risks in solution acquisition without justification or positive action to ensure such outcomes • Planning Fallacy - unrealistically low estimates of the time and cost it will take to complete a task and n overestimate of the benefits that will be derived, despite previous experience February 2, 2020 44
Spectrum Of Outcomes Of Solution Acquisition Failure February 2, 2020 45 Complete Solution Success: On-time, On-budget, Being Used And Delivering Specified Benefits Solution Delivery Late Complete Solution Failure: Cancelled, Unused, Rejected More Expensive to Operate And Support Than Planned Or Expected Unstable and Unreliable Requiring Additional Support Cost and Effort Solution Has Reduced Functionality Requiring Workarounds Not What Is Wanted Or What Was Required/ Envisaged Functionality Delivered Does Not Meet Business Requirements Significant Rework Or Replacement Required Success FailureChallenged Solution Delivery Over Budget Performance And/Or Operational Problems Not All Specified Business Benefits And Savings Not Delivered Low Medium High Very High
Spectrum Of Outcomes Of Solution Acquisition Failure February 2, 2020 46 Solution Failure Type Likely Impact Range of Failure Description Significant Rework Or Replacement Required High to Very High Elements of the solution as delivered need to be replaced or significantly reworked to operate as planned or needed. Solution Delivery Late Low to Medium The solution exceeded its original budget. Solution Delivery Over Budget Low to Medium The solution exceeded its schedule. Unstable and Unreliable Requiring Additional Support Cost and Effort Medium to Very High The solution does not work as automatically and without intervention as expected or designed or is unstable or unreliable and requires a degree of manual support work. More Expensive to Operate And Support Than Planned Or Expected Low to High The solution works but the effort and cost to support and operate it is greater than planned. Performance And/Or Operational Problems Low to Medium The solution does not have the required throughput or response times as expected or designed. The span of this challenge is generally low to medium but in extreme circumstances, the impact can be high. Solution Has Reduced Functionality Requiring Workarounds Low to Medium Some of the initially designed functionality was omitted from the delivered solution requiring additional manual effort and work outside the core solution components. Not What Is Wanted Or What Was Required/ Envisaged High to Very High The delivered solution is not what the business wanted or expected or does not fulfil their needs. Not All Specified Business Benefits And Savings Not Delivered Low to Medium Some of the expected benefits have not been realised. Functionality Delivered Does Not Meet Business Requirements Medium to Very High Some of the functionality contained in the solution does not work exactly as the solution consumer expected or wanted.
Solution Acquisition Failure – Less For More • At its simplest, the solution failures includes solutions that are characterised by Less for More −More Cost– the original budget was exceeded or other unanticipated costs arose or the solution costs more to operate −More Time – the original schedule was exceeded which means the business were late in having access to the solution −Delivered Less – the original scope was reduced, making the solution less usable or requiring additional unplanned for effort or the solution takes longer or more effort to use or required manual workarounds or the solution does not meet the expectations of the target solution consumers −Achieved Less – the solution does not deliver the expected benefits and savings or the solution is less widely used that expected or planned February 2, 2020 47
Solution Acquisition Failure – Double Deficit February 2, 2020 48 Success – Required Functionality Delivered, Benefits Achieved, Solution Used Success – On Time, On Budget Degree of Failure - More Time, More Money Degree of Failure - Less Functionality, Fewer Benefits, Less Usage Solution Functionality and Benefits Deficit Solution Time and Money Deficit
Discrepancies Between Stated And Actual Solution Acquisition Characteristics February 2, 2020 49 Stated Costs Actual Benefits Stated Risks Stated Functionality Needed Actual Time Stated Benefits Actual Costs Stated Time Actual Risks Actual Functionality Needed
Solution Architecture Involvement In Solution Acquisition Avoids The Dangers Of Strategic Misrepresentation • Solution architecture has the skills and experience to define the real scope of the solution being acquired • Scope of the fully required solution is made fully visible • Cost estimates are more accurate • Attempts to bypass or ignore necessary solution components and their costs are trapped and stopped • Solution acquirers are made aware of the actual likely solution acquisition cost • Ensures that solution acquisition is rigorous February 2, 2020 50
Acquisition Capabilities Across The Acquisition Process • Identified capabilities are needed along the acquisition process to ensure good solution acquisition outcomes February 2, 2020 51 Solution Acquisition Project Planning and Management Solution Requirements Definition, Validation and Validation Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination
Solution Acquisition Interfaces With Other Organisation Functions And Processes February 2, 2020 52 Solution Acquisition Supplier ManagementIT Architecture (Enterprise, Data) Operations Support And Service Management Security Financial And Solution Investment Management Compliance, Regulation, Legal Business Strategy And Planning
Solution Acquisition Interfaces With Other Organisation Functions • The solution acquisition function and process needs operate with other organisation functions to work optimally − Business Strategy And Planning – the solutions being acquired should assist with the achievement of the business strategy and objectives. Depending on their scale their acquisition should be subject to strategic assessment and a business case − Financial And Solution Investment Management – the solution acquisition and operating costs should be subject to financial management and controls and to investment standards and processes − IT Architecture (Enterprise, Data) – the solution being acquired should comply with IT Architecture standards − Compliance, Regulation, Legal – irrespective of where the solution resides, it will be subject to the same compliance and regulatory standards and processes as other solutions. Externally hosted solutions may be subject to greater regulations − Operations Support And Service Management – the solution will have to be operable and supportable in order to be operated and supported − Supplier Management – solution acquisition should be subject to strategic supplier management standards − Security – the solution, access to it and the data its processes should be subject to organisation security standards and processes February 2, 2020 53
Solution Acquisition Capability Layers • Core solution acquisition − Pre-solution acquisition – preparation, planning, definition, mobilisation − Solution acquisition – the acquisition and decision process, the selection of the solution and supplier and the definition of the delivery contract • Expanded solution acquisition − Solution delivery and implementation – verify that what is supplied is what was agreed and monitor the operation of solution delivery − Solution validation – validate that the solution operates as intended and that it delivers the benefits stated − Solution acquisition operation – review the operation of the solution acquisition process, identify lessons that can be learned and update the process based on experience • Extended solution acquisition − Solution acquisition process definition and implementation – define and implement the solution acquisition process, train those involved and establish structure − Solution acquisition process measurement and improvement – measure the outcomes achieved and update and improve process • Solution acquisition does not stop after the acquisition decision made – it is not a fire-and-forget activity February 2, 2020 54
ExtendedSolutionAcquisition ExpandedSolutionAcquisition CoreSolutionAcquisition Core, Expanded And Extended Solution Acquisition Capabilities February 2, 2020 55 Solution Requirements Definition, Validation and Verification Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination Solution Acquisition Project Planning and Management Solution Acquisition Process Definition and Implementation Solution Acquisition Process Measurement and Improvement
Acquisition Capabilities Across The Acquisition Process • An effective process, well-implemented and consistently applied, means dependable and repeatable solution acquisition and successful outcomes February 2, 2020 56
Objectives Of Acquisition Process February 2, 2020 57 Solution Requirements Definition, Validation and Verification Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination Solution Acquisition Project Planning and Management Objective of Solution Acquisition is to Go From Here … … To Here, Having a Usable Solution Within The Agreed Costs, Within the Agreed Time, Providing the Required Functionality, Having the Agreed Operational Characteristics and Overheads and Achieving the Expected Benefits
Key Core and Expanded Solution Acquisition Capabilities • Core − Solution Acquisition Project Planning and Management • Use standard project process to create and manage the solution acquisition project • Manage stakeholders • Monitor project progress and take action to prevent performance problems − Solution Acquisition Risk Management • Identify potential problems in advance and plan risk handling and management actions to eliminate or reduce the impact of such problems − Solution Requirements Definition, Validation and Verification • Gather, define, document customer solution function and operational requirement and the solution delivery and use contractual requirements • Manage requirements through the duration of the solution acquisition project − Solution Design and Specification • Create an integrated description of the desired solution that links the individual requirements into a usable conceptual solution design, identifying the full solution scope and its likely components, including the wider solution topography and solution interfaces and infrastructure − Solicitation and Supplier Agreement Development • Prepare a set of material to be used to seek solution delivery proposals from supplier and to evaluate proposals and select a supplier − Solution Decision Analysis and Determination • Analyse solution proposals and alternatives using formal auditable evaluation and selection process and using agreed evaluation factors − Solution Acquisition Verification • Ensure that the selected solution will be usable, operable, supportable, maintainable that that it can meet the functional and operational requirements and fit into the wider solution landscape • Expanded − Supplier Agreement Management Determination • Ensure that the supplier performs the solution delivery work according to the agreed specification − Solution Acquisition Validation • Validate that the delivered and implemented solution operates as intended, achieves its intended objectives and the benefits identified are realised February 2, 2020 58
Overlap Of Core Capabilities Across Solution Architecture And Procurement Functions • The required capabilities and the delivery will be split or shared across the solution architecture and procurement functions February 2, 2020 59 Solution Architecture Procurement Solution Acquisition Project Planning and Management Solution Acquisition Risk Management Solution Requirements Definition, Validation and Verification Solution Design and Specification Solution Proposal and Supplier Agreement Definition Solution Decision Analysis and Determination Solution Acquisition Verification
Need To Involve Solution Architecture In Solution Procurement Process From The Start • Solution architecture needs to be involved is solution acquisition from the start • The solution architecture functions has the skills and experience to define the real scope of the solution being acquired • This maximises successful solution acquisition February 2, 2020 60
Structure Of Solution Acquisition Capabilities • Each capability has a number of objectives and purposes • To achieve each objective there are activities • This structure provides a generic framework to create customised plans for individual solution acquisition exercises • Allows skills to be identified, gaps remediated February 2, 2020 61 Capabilities Objectives Activities Tasks
Solution Acquisition Core Capabilities And Their Major Objectives Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Establish Project Manage Stakeholders and Communications Monitor Progress Against Plan Manage Issues Solution Acquisition Risk Management Establish Risk Management Framework Identify and Analyse Risks Handle Risks Solution Requirements Definition, Validation and Validation Gather Solution Requirements Gather Contractual Requirements Analyse and Validate Requirements Manage Requirements Solution Design and Specification Statement of Concept Of Need/ Goal/Objective Review Stakeholder Requirements Initial Architecture Review Gather Solution Requirements Create, Review and Agree Solution Architecture Design and Specification Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Identify Potential Suppliers Solicit Proposals Solution Decision Analysis and Determination Define Assessment Factors Evaluate and Review Solution Proposals Solution Acquisition Verification Define Validation Process Define Negotiation Process Perform Validation Select Supplier and Solution Negotiate With Selected Supplier February 2, 2020 62
Balance Between Detail And Precision And Speed And Flexibility Of Acquisition • The scope and detail of the solution design phase of the architecture process depends on factors such as: − The degree of certainty of the required solution functionality − The solution solicitation process – RFP or RFP − The likely amount of new technology that the solution may include − The likely size and scale of the solution being acquired − The time available to create a solution design − The complexity of the wider solution topography within which the acquired solution will reside and operate • There needs to be a balance between the detail of the solution design presented to potential suppliers and openness to allowing suppliers propose creative and innovative solutions using new technologies • Too detailed and prescriptive a solution specification may result in a locked-in solution design resulting in options and alternatives not be presented or not fully explored February 2, 2020 63
Conceptual Solution Architecture • A Conceptual Solution Architecture (CSA) focusses on the core functional and system components of the solution • The CSA provides a framework for identifying solution requirements across the solution landscape • It also assists with compiling business stakeholder requirements as requirements can be elicited within the context of the complete end-to-end solution concept framework • A CSA solution design might be sufficient for the solution acquisition process February 2, 2020 64
Solution Design As Part Of Solution Acquisition • Where the pace of technology change is fast or the need for new business solutions quickly is great, is there time to create lengthy detailed solution design documentation? • Is there time for a lengthy solution acquisition process? • Can potential suppliers bear the cost of a long solution acquisition process? • Complexity of solution acquisition means technical controls are needed • A good conceptual solution design eliminates the need for solution acquisition based on a long list of requirements • Reduces overall solution acquisition time February 2, 2020 65
Including Solution Architecture In Solution Acquisition Attempts To Solve The All Too Common Problems Of … • Lack of response to business needs • Slow and costly solution delivery • Unforeseen costs • High solution maintenance and operation costs • Fragile solutions with many manual workarounds • Excessive and duplicated implementation and operation effort • Duplicated and costly investments in many solutions • Siloed solutions with lack of integration • Poor return on investment • Too little, too late, not what is wanted or needed February 2, 2020 66
Solution Acquisition Capabilities And Activities • The next sections list the activities associated with each capability • This provides a detailed generalised structure for a solution acquisition exercise • This can be customised to suit the specific requirements of the exercise February 2, 2020 67 Capabilities Objectives Activities Tasks
February 2, 2020 68 Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Setup the Standard Solution Acquisition Project Process Setup the Specific Solution Acquisition Project Using the Standard Process Review and Reuse Previous Solution Acquisition Project Process Information for Project Planning Allocate Project Resources, Facilities, Library and Templates Create Extended Solution Acquisition Plan That Includes Quality Plan, Risk Plan and Verification Plan Assemble and Train Project Team and Sub- Teams Suggest Updates and Changes to Standard Solution Acquisition Project Process, if Appropriate Establish Project Establish And Agree the Solution Acquisition Approach for this Solution Agree Solution Acquisition Project Scope Define Project Dependencie s Create Solution Acquisition Project Work Breakdown and Product List Create Estimates for Solution Acquisition Project Define Major Project Stages Create Solution Acquisition Resource and Cost Estimates Allocate Project Budget Agree Project Resources and Schedule Define Skills Gaps and Knowledge and Skills Requirement s Finalise and Agree Solution Acquisition Project Plans Manage Stakeholders and Communicati ons Monitor Stakeholder Commitment s Manage Project Communicati ons Monitor Progress Against Plan Monitor Project Progress and Delivery Monitor Resource Work Quality Monitor Project Collateral Management Perform and Publish Project Reviews Manage Issues Analyse and Document Issues Agree and Take Corrective Action Manage Performance of Corrective Action Update Plan Based on Corrective Action Solution Acquisition Risk Management Establish Risk Management Framework Create and Agree Project Risk Framework and Risks Sources and Types Agree Approach to Analyse, Categorise and Prioritise Risks Agree Approach to Managing Risks Identify and Analyse Risks Identify Solution Acquisition Project Risks Analyse, Categorise and Prioritise Risks Publish Risks Analysis Handle Risks Create and Agree Risk Mitigation Approach Implement Agreed Risk Mitigation Approach Solution Requirements Definition, Validation and Validation Gather Solution Requirement s Define and Agree Approach to Solution Requirement s Gathering and Analysis Agree People to be Consulted in Gathering Solution Requirement s Gather Requirement s for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Solution Requirement s Gather Operational and Delivery Contractual Requirement s Gather Operational and Delivery Contractual Requirement s for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Operational and Delivery Contractual Requirement s Include Operational and Delivery Contractual Requirement s in Solution Acquisition Analyse and Validate Requirement s Consolidate and Analyse Solution and Operational and Delivery Contractual Requirement s Validate Deliverability, Usability and Utility of Requirement s Identify Impact of Requirement s Distribute and Discuss Requirement s Analysis Rationalise Requirement s Manage Requirement s Establish Requirement s Analysis Factors and Approach Including Requirement s Change Management Define and Agree Sources of Requirement s Evaluate Requirement s as They Arise Distribute Requirement Impact Assessments and Agree Requirement s Record and Manage Changes to Requirement s Maintain Project Tracking and Traceability Ensure Consistency of Requirement s Solution Design and Specification Statement of Concept Of Need/ Goal/ Objective Define Source of Solution Need and Objectives to be Achieved Agree and Refine Solution Statement Validate Solution Need Against Business Case Validate Solution Need Against Business Strategy and Objectives Review Stakeholder Requirement s Review Requirement s Against Solution Statement and Business Case Create Rationalised and Consolidated Set of Stakeholder Requirement s Initial Architecture Review Create Initial Inventory of Solution Components and Interfaces with Existing Solutions Create Initial Inventory of Solution Functions Create Initial Inventory of Solution Actors Create Initial Inventory of Solution New and Existing Business Process Create Initial Inventory of Solution Data Entities Create Initial Conceptual Solution Architecture Gather Solution Requirement s Define Overall Expected Solution Operation, Use and Constraints Define Solution Usage and Operation Scenarios /Use Cases for Requirement s Assessment Define the Solution Operational Environment and Boundaries Including Interactions with Other Operational Solutions Extend Conceptual Solution Architecture and Design Assess Previously Gathered Requirement s Against Solution Scenarios and Design and Identify Gaps Review and Fill Requirement s Gaps Create Overall Aggregated Solution Requirement s Specification Create, Review and Agree Solution Architecture Design and Specification Update Conceptual Solution Architecture Design Review and Agree Conceptual Solution Architecture Design Create Solution Acquisition Design Specification Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Agree Scope and Contents of Acquisition Solicitation Package Create Solution Acquisition Solicitation Package Review and Agree Solution Acquisition Solicitation Package Maintain and Update Solution Acquisition Solicitation Package Agree Publication Process and Targets Identify Potential Suppliers Research Solutions and Options Available Research Solution Advertiseme nt and Publication Options Available Create List of Potential Solutions and Suppliers Agree Supplier Contact Management Approach Solicit Proposals and Manage Proposal Process Publish and Distribute Solution Acquisition Solicitation Package to Agreed Target Suppliers Manage Questions and Communicati ons from Suppliers Solution Decision Analysis and Determination Define Assessment Factors Define and Agree Approach to Performing Solution Evaluation Including Shortlisting Define Delivery, Functional, Technical, Operational and Contractual Evaluation Information Sources Prepare Evaluation Scripts Prepare Demonstratio n Evaluation Scripts Prepare Reference Contact Scripts Prepare Lifetime Cost Financial Analysis Model Define Legal and Compliance Requirement s Define and Agree Solution Evaluation Factors and Weights Define Evaluation Work Products Evaluate and Review Solution Proposals Conduct Initial Solution Evaluation and Create Shortlist Conduct Detailed Delivery, Functional, Technical, Operational and Contractual Evaluation on Shortlisted Solutions Review Solution Demonstratio ns Contact References Perform Lifetime Cost Financial Analysis Agree Solutions to Select for Final Verification Solution Acquisition Verification Define Validation Process Define and Agree Scope of Solution Verification (Implementat ion, Technical, Functional, Operation, Interface, Financial, Contract) Define Verification Factors and Weights Define Verification Approach – Use Cases, Process Inventory Walkthrough, Requirement s Traceability, Data Flow Assemble the Verification Team Define Verification Work Products Create the Verification Environment Define Negotiation Process Define and Agree Supplier Negotiation Approach Define Solution Contractual, Delivery and Operation Requirement s Perform Validation Perform Solution Verification Agree and Document Solution Verification Results Select Supplier and Solution Agree Selected/ Preferred Solution and Supplier Negotiate With Selected/ Preferred Supplier Negotiate With Supplier
Solution Acquisition Project Planning and Management – Scope • Develop the solution acquisition project plan based on the acquisition strategy including identifying work products, creating estimates, identifying and acquiring resources and creating a schedule • Adopt the standard acquisition project process to the needs of the specific project • Manage the creation of standard acquisition project interim and final assets and deliverables • Get commitment to the plan • Maintain the plan • Allocate and manage acquisition project objectives, commitments and tasks • Handle and communicate with relevant stakeholders • Monitor project progress and take corrective action if progress varies from planned • Handle issues as they arise February 2, 2020 69
Solution Acquisition Project Planning and Management – Capabilities and Activities Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Setup the Standard Solution Acquisition Project Process Setup the Specific Solution Acquisition Project Using the Standard Process Review and Reuse Previous Solution Acquisition Project Process Information for Project Planning Allocate Project Resources, Facilities, Library and Templates Create Extended Solution Acquisition Plan That Includes Quality Plan, Risk Plan and Verification Plan Assemble and Train Project Team and Sub-Teams Suggest Updates and Changes to Standard Solution Acquisition Project Process, if Appropriate Establish Project Establish And Agree the Solution Acquisition Approach for this Solution Agree Solution Acquisition Project Scope Define Project Dependencies Create Solution Acquisition Project Work Breakdown and Product List Create Estimates for Solution Acquisition Project Define Major Project Stages Create Solution Acquisition Resource and Cost Estimates Allocate Project Budget Agree Project Resources and Schedule Define Skills Gaps and Knowledge and Skills Requirements Finalise and Agree Solution Acquisition Project Plans Manage Stakeholders and Communications Monitor Stakeholder Commitments Manage Project Communications Monitor Progress Against Plan Monitor Project Progress and Delivery Monitor Resource Work Quality Monitor Project Collateral Management Perform and Publish Project Reviews Manage Issues Analyse and Document Issues Agree and Take Corrective Action Manage Performance of Corrective Action Update Plan Based on Corrective Action February 2, 2020 70
Solution Acquisition Risk Management – Scope • Identify potential problems in solution acquisition before they happen so any negative impact can be lessened or avoided • Risk management is a constant process concerned with anticipating potential issues that might affect the solution acquisition process February 2, 2020 71
Solution Acquisition Risk Management – Capabilities And Activities February 2, 2020 72 Solution Acquisition Risk Management Establish Risk Management Framework Create and Agree Project Risk Framework and Risks Sources and Types Agree Approach to Analyse, Categorise and Prioritise Risks Agree Approach to Managing Risks Identify and Analyse Risks Identify Solution Acquisition Project Risks Analyse, Categorise and Prioritise Risks Publish Risks Analysis Handle Risks Create and Agree Risk Mitigation Approach Implement Agreed Risk Mitigation Approach
Solution Requirements Definition, Validation and Validation – Scope • Specify and communicate the approach to gathering requirements • Agree the set of business users to be involved in providing requirements • Gather, analyse, validate business user requirements, expectations, limitations and integration for the expected solution • Assign priorities to requirements • Collate and classify the requirements • Define the operational and quality requirements • Manage the requirements lifecycle February 2, 2020 73
Solution Requirements Definition, Validation and Validation – Capabilities and Activities February 2, 2020 74 Solution Requirements Definition, Validation and Validation Gather Solution Requirements Define and Agree Approach to Solution Requirements Gathering and Analysis Agree People to be Consulted in Gathering Solution Requirements Gather Requirements for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Solution Requirements Gather Operational and Delivery Contractual Requirements Gather Operational and Delivery Contractual Requirements for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Operational and Delivery Contractual Requirements Include Operational and Delivery Contractual Requirements in Solution Acquisition Analyse and Validate Requirements Consolidate and Analyse Solution and Operational and Delivery Contractual Requirements Validate Deliverability, Usability and Utility of Requirements Identify Impact of Requirements Distribute and Discuss Requirements Analysis Rationalise Requirements Manage Requirements Establish Requirements Analysis Factors and Approach Including Requirements Change Management Define and Agree Sources of Requirements Evaluate Requirements as They Arise Distribute Requirement Impact Assessments and Agree Requirements Record and Manage Changes to Requirements Maintain Project Tracking and Traceability Ensure Consistency of Requirements
Dangers Of Solution Requirements • Requirements gathered during solicitation sessions with business users tend to be: − Sparse and disconnected − Isolated and disintegrated statements − Inconsistent − Incomplete − Disjointed − Conflicting − Uncosted − Unprioritised − Representations of specific points of functionality that do not aggregate into a defined and integrated solution − Missing significant solution components (and therefore solution delivery costs) such as organisation changes, business processes, data migrations, integration with other solutions • Business user do not have and should not be expected to have this level of knowledge − A source of additional unstated and implied requirements February 2, 2020 75
Requirements • The reality is that what is gathered during requirements workshops, meetings, interviews, questionnaires and other activities are not solution requirements but business stakeholder requirements • Stakeholder requirements must be translated into solution requirements which is turn must be translated into a solution design • Requirements gathering is a means to an end and not an end in itself • Requirements gathering should never be part of the delivery project but be the subject of an analysis and architecture design exercise prior to any delivery project • You cannot know what the scope of the project is until the solution that needs to be delivered is known February 2, 2020 76
Sparse Requirements And Overall Solution Framework • Business stakeholder requirements never represent what the full solution needs in order to operate successfully • Business stakeholder requirements have to be passed through a solution design filter to create a complete solution design February 2, 2020 77 = Specific Requirement = Solution Factor Not Explicitly Listed As Requirement
Solution Design and Specification – Scope • Agree the purpose and objective of the intended solution • Review the initially gathered requirements • Create an initial conceptual architecture that identifies all the solution components • Complete solution gaps • Refine the solution design February 2, 2020 78
Solution Design and Specification – Capabilities and Activities February 2, 2020 79 Solution Design and Specification Statement of Concept Of Need/ Goal/Objective Define Source of Solution Need and Objectives to be Achieved Agree and Refine Solution Statement Validate Solution Need Against Business Case Validate Solution Need Against Business Strategy and Objectives Review Stakeholder Requirements Review Requirements Against Solution Statement and Business Case Create Rationalised and Consolidated Set of Stakeholder Requirements Initial Architecture Review Create Initial Inventory of Solution Components and Interfaces with Existing Solutions Create Initial Inventory of Solution Functions Create Initial Inventory of Solution Actors Create Initial Inventory of Solution New and Existing Business Process Create Initial Inventory of Solution Data Entities Create Initial Conceptual Solution Architecture Gather Solution Requirements Define Overall Expected Solution Operation, Use and Constraints Define Solution Usage and Operation Scenarios/Use Cases for Requirements Assessment Define the Solution Operational Environment and Boundaries Including Interactions with Other Operational Solutions Extend Conceptual Solution Architecture and Design Assess Previously Gathered Requirements Against Solution Scenarios and Design and Identify Gaps Review and Fill Requirements Gaps Create Overall Aggregated Solution Requirements Specification Create, Review and Agree Solution Architecture Design and Specification Update Conceptual Solution Architecture Design Review and Agree Conceptual Solution Architecture Design Create Solution Acquisition Design Specification
Solution Design Process February 2, 2020 80 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Elicit Stakeholder Requirements Formalise Stakeholder Requirements Define Solution Requirements Analyse Solution Requirements Define Solution Architecture and Design Analyse, Evaluate and Refine Solution Architecture Implementation Project Initial Architecture Review and Options
Solution Design Process Stage Scope Initial Concept Of Need/ Goal/ Objective The business have an idea for a solution based on an apparent need to solve a problem, to do what is currently not possible, to react or respond to an external demand or to be able to achieve a new objective. Formal Statement Of Need/ Goal/ Objective This formalises the initial concept to introduce greater consistency and detail. It serves to understand the business, objectives, purposes and potential organisational impacts. It describes what the ideal solution will do. It also identifies the high-level potential system impacts. Initial Architecture Review and Options This uses the formal statement of need to create an initial high-level view of the overall solution, its new and existing systems and applications components, the required functionality, their interfaces, the required processes and the business functions impacted. This provides a container for the requirements and a vision for the solution. Stakeholder Requirements Collection and Specification This uses this initial architectural review output in a structured way to elicit and formalise the set of stakeholder requirements across the dimensions of functionality and processes. Solution Requirements Collection and Specification The solution requirements specification is a fuller, more detailed and elaborated set of solution requirements encompassing all the solution components. This includes the requirements explicitly identified by stakeholders and the implied requirements. Solution Architecture Design and Specification This is the detailed solution specification derived from the stakeholder and solution requirements. Implementation Project This uses the detailed solution specification to act as an input to project definition and to create a realistic implementation plan, schedule, set of costs and required resources. February 2, 2020 81
Solution Design Process • There is a decision point after each stage where a decision is made if it is worthwhile to proceed to the next stage February 2, 2020 82 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options Decision Points
Solution Design Process • Not all concepts make it all the way to implementation • Process needs to accommodate this • Do as little as possible to achieve as much as possible to make an informed decision on whether and how to proceed to the next stage in the solution journey February 2, 2020 83 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
Solution Design Process - Iterations • Solution design process is not necessarily linear • Stages can be iterated a number of times to different levels of detail February 2, 2020 84 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
Solution Proposal and Supplier Agreement Definition – Scope • Create the set of information to be used as part of the solution acquisition process • Agree the approach and options to publishing the solution acquisition information package • Identify list of potential solutions and their suppliers • Publish the solution acquisition information package • Manage solution acquisition supplier communications and requests for information and clarifications February 2, 2020 85
Solution Proposal and Supplier Agreement Definition – Capabilities and Activities February 2, 2020 86 Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Agree Scope and Contents of Acquisition Solicitation Package Create Solution Acquisition Solicitation Package Review and Agree Solution Acquisition Solicitation Package Maintain and Update Solution Acquisition Solicitation Package Agree Publication Process and Targets Identify Potential Suppliers Research Solutions and Options Available Research Solution Advertisement and Publication Options Available Create List of Potential Solutions and Suppliers Agree Supplier Contact Management Approach Solicit Proposals and Manage Proposal Process Publish and Distribute Solution Acquisition Solicitation Package to Agreed Target Suppliers Manage Questions and Communications from Suppliers
Solution Decision Analysis and Determination – Scope • Apply agreed evaluation factors to the proposed solutions and their importance • Prepare set of supporting material to be used during evaluation including lifetime cost model • Create initial solution shortlist • Conduct detailed evaluation on shortlisted solutions • Agree set of solutions to be verified February 2, 2020 87
Solution Decision Analysis and Determination – Capabilities and Activities February 2, 2020 88 Solution Decision Analysis and Determination Define Assessment Factors Define and Agree Approach to Performing Solution Evaluation Including Shortlisting Define Delivery, Functional, Technical, Operational and Contractual Evaluation Information Sources Prepare Evaluation Scripts Prepare Demonstration Evaluation Scripts Prepare Reference Contact Scripts Prepare Lifetime Cost Financial Analysis Model Define Legal and Compliance Requirements Define and Agree Solution Evaluation Factors and Weights Define Evaluation Work Products Evaluate and Review Solution Proposals Conduct Initial Solution Evaluation and Create Shortlist Conduct Detailed Delivery, Functional, Technical, Operational and Contractual Evaluation on Shortlisted Solutions Review Solution Demonstrations Contact References Perform Lifetime Cost Financial Analysis Agree Solutions to Select for Final Verification
Solution Acquisition Verification – Scope • Perform detailed delivery, implementation, technical, functional, operation and interface/integration verification of the short-listed solutions to verify that they will work, can be delivered • Perform contractual and financial validation of the short- listed solutions • Select preferred supplier • Negotiate with the preferred supplier February 2, 2020 89
Solution Acquisition Verification – Capabilities and Activities February 2, 2020 90 Solution Acquisition Verification Define Validation Process Define and Agree Scope of Solution Verification (Implementation, Technical, Functional, Operation, Interface, Financial, Contract) Define Verification Factors and Weights Define Verification Approach – Use Cases, Process Inventory Walkthrough, Requirements Traceability, Data Flow Assemble the Verification Team Define Verification Work Products Create the Verification Environment Define Negotiation Process Define and Agree Supplier Negotiation Approach Define Solution Contractual, Delivery and Operation Requirements Perform Validation Perform Solution Verification Agree and Document Solution Verification Results Select Supplier and Solution Agree Selected/Preferred Solution and Supplier Negotiate With Selected/Preferred Supplier Negotiate With Supplier
Full Set of Solution Capabilities, Objectives And Activities • The full set of generalised solution acquisition capabilities, objectives and activities will allow a customised path to be defined through the solution acquisition exercise • A realistic delivery plan can be developed • Schedule, resources and effort can be identified in advance • Progress can be tracked February 2, 2020 91
Summary • There is more packaged/product/service-based solution acquisition activity • Increasing trend of solutions hosted outside the organisation • Solution acquisition outcomes are poor and getting worse • Poor solution acquisition has long-term consequences and costs • Solution architecture provides the structured approach to capturing all the cost contributors and knowing the true solution scope • The to-be-acquired solution needs to operate in and co-exist with an existing solution topography and the solution acquisition process needs to be aware of and take account of this wider solution topography • Cloud-based or externally hosted and provided solutions do not eliminate the need for the solution to exist within the organisation solution topography • Strategic misrepresentation in solution acquisition is the deliberate distortion or falsification of information relating to solution acquisition costs, complexity, required functionality, solution availability, resource availability, time to implement in order to get solution acquisition approval • Strategic misrepresentation is very real • Solution architecture has the skills and experience to define the real scope of the solution being acquired • An effective structured solution acquisition process, well-implemented and consistently applied, means dependable and repeatable solution acquisition and successful outcomes February 2, 2020 92
More Information Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616 02 February 2020 93

More Related Content

PDF
IT Architecture’s Role In Solving Technical Debt.pdf
byAlan McSweeney
 
PDF
Agile Solution Architecture and Design
byAlan McSweeney
 
PDF
Complexity and Solution Architecture
byAlan McSweeney
 
PDF
The Need For Effective Early Engagement In Solution Architecture And Design
byAlan McSweeney
 
PDF
Solution Architecture And Solution Security
byAlan McSweeney
 
PDF
We Need To Talk About IT Architecture
byAlan McSweeney
 
PDF
Solution Architecture And (Robotic) Process Automation Solutions
byAlan McSweeney
 
PDF
Solution Architecture And User And Customer Experience
byAlan McSweeney
 
IT Architecture’s Role In Solving Technical Debt.pdf
byAlan McSweeney
 
Agile Solution Architecture and Design
byAlan McSweeney
 
Complexity and Solution Architecture
byAlan McSweeney
 
The Need For Effective Early Engagement In Solution Architecture And Design
byAlan McSweeney
 
Solution Architecture And Solution Security
byAlan McSweeney
 
We Need To Talk About IT Architecture
byAlan McSweeney
 
Solution Architecture And (Robotic) Process Automation Solutions
byAlan McSweeney
 
Solution Architecture And User And Customer Experience
byAlan McSweeney
 

What's hot

PDF
Enterprise Architecture Implementation And The Open Group Architecture Framew...
byAlan McSweeney
 
PDF
Digital Transformation And Solution Architecture
byAlan McSweeney
 
PDF
Review of Information Technology Function Critical Capability Models
byAlan McSweeney
 
PDF
Introduction to Business Architecture - Part 2
byAlan McSweeney
 
PDF
From Business model to Capability Map
byCOMPETENSIS
 
PPTX
Togaf 9.2 Introduction
byMohamed Zakarya Abdelgawad
 
PPTX
IT4IT - The Full Story for Digital Transformation - Part 1
byMohamed Zakarya Abdelgawad
 
PDF
Structured Approach to Solution Architecture
byAlan McSweeney
 
PDF
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
byAlan McSweeney
 
PDF
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
byAlan McSweeney
 
PPS
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
PDF
Enterprise Architecture - TOGAF Overview
byMohamed Sami El-Tahawy
 
PDF
Integrated Project and Solution Delivery And Business Engagement Model
byAlan McSweeney
 
PDF
IT4IT real life examples & myths and rumors dispelled
byTony Price
 
PDF
IT4IT and DevOps Tools Landscape (2020).
byRob Akershoek
 
PPTX
Modeling TOGAF with ArchiMate
byIver Band
 
PDF
Future Proofing Your IT Operating Model for Digital
byDavid Favelle
 
PDF
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
byAlan McSweeney
 
PPT
Requirements Gathering And Management
byAlan McSweeney
 
PPTX
Solution architecture
byiasaglobal
 
Enterprise Architecture Implementation And The Open Group Architecture Framew...
byAlan McSweeney
 
Digital Transformation And Solution Architecture
byAlan McSweeney
 
Review of Information Technology Function Critical Capability Models
byAlan McSweeney
 
Introduction to Business Architecture - Part 2
byAlan McSweeney
 
From Business model to Capability Map
byCOMPETENSIS
 
Togaf 9.2 Introduction
byMohamed Zakarya Abdelgawad
 
IT4IT - The Full Story for Digital Transformation - Part 1
byMohamed Zakarya Abdelgawad
 
Structured Approach to Solution Architecture
byAlan McSweeney
 
Solution Architecture – Approach to Rapidly Scoping The Initial Solution Options
byAlan McSweeney
 
Integrating It Frameworks, Methodologies And Best Practices Into It Delivery ...
byAlan McSweeney
 
Understanding and Applying The Open Group Architecture Framework (TOGAF)
byNathaniel Palmer
 
Enterprise Architecture - TOGAF Overview
byMohamed Sami El-Tahawy
 
Integrated Project and Solution Delivery And Business Engagement Model
byAlan McSweeney
 
IT4IT real life examples & myths and rumors dispelled
byTony Price
 
IT4IT and DevOps Tools Landscape (2020).
byRob Akershoek
 
Modeling TOGAF with ArchiMate
byIver Band
 
Future Proofing Your IT Operating Model for Digital
byDavid Favelle
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
byAlan McSweeney
 
Requirements Gathering And Management
byAlan McSweeney
 
Solution architecture
byiasaglobal
 

Similar to Solution Architecture and Solution Acquisition

PDF
Stopping Analysis Paralysis And Decision Avoidance In Business Analysis And S...
byAlan McSweeney
 
PDF
Solution Architecture and Solution Estimation.pdf
byAlan McSweeney
 
PPT
Comprehensive And Integrated Approach To Project Management And Solution Deli...
byAlan McSweeney
 
PPT
Ch07-Moving into Design
byFajar Baskoro
 
PPTX
chapter07.pptx anaysis and design course
byAhmedHusseinElmi
 
PPTX
PROBLEMS OR FAILURES IN IT IMPLEMENTATION.pptx
byLILISSETYANINGRUM
 
PDF
Quality & Risk Management Challenges When Acquiring Enterprise Systems
byPacific Northwest Software Quality Conference
 
PDF
IT-AAC Defense IT Reform Report to the Sec 809 Panel
byJohn Weiler
 
PPTX
Balancing IT Options for Effectiveness, TCO and CapEx/OpEx in an Acquisition
byDCG Software Value
 
PDF
Roland berger managing-the-it-cost-challenge_20090522
byKarthik Arumugham
 
PDF
Incorporating A DesignOps Approach Into Solution Architecture
byAlan McSweeney
 
PPT
Unit b
byIceJudge
 
PPTX
Acquiring New Technologies with Decreasing IT Budgets
byInnoTech
 
PPTX
Practical approaches to address government contracting problems
byJohn Gilligan
 
PPT
It aac cloud-acquisition_roadmap2012
byJohn Weiler
 
PPT
IT-AAC Roadmap for Sustainable Defense IT Reforms
byJohn Weiler
 
PPT
Weiler slideshow
byvjairam
 
PDF
Sales Compensation Solution Acquisition Best Practices Report
byDemand Metric
 
PDF
SolutionTo know that the team has identified all of the significa.pdf
byanushasarees
 
PPT
Congressional it reform-roadmap_2011
byJohn Weiler
 
Stopping Analysis Paralysis And Decision Avoidance In Business Analysis And S...
byAlan McSweeney
 
Solution Architecture and Solution Estimation.pdf
byAlan McSweeney
 
Comprehensive And Integrated Approach To Project Management And Solution Deli...
byAlan McSweeney
 
Ch07-Moving into Design
byFajar Baskoro
 
chapter07.pptx anaysis and design course
byAhmedHusseinElmi
 
PROBLEMS OR FAILURES IN IT IMPLEMENTATION.pptx
byLILISSETYANINGRUM
 
Quality & Risk Management Challenges When Acquiring Enterprise Systems
byPacific Northwest Software Quality Conference
 
IT-AAC Defense IT Reform Report to the Sec 809 Panel
byJohn Weiler
 
Balancing IT Options for Effectiveness, TCO and CapEx/OpEx in an Acquisition
byDCG Software Value
 
Roland berger managing-the-it-cost-challenge_20090522
byKarthik Arumugham
 
Incorporating A DesignOps Approach Into Solution Architecture
byAlan McSweeney
 
Unit b
byIceJudge
 
Acquiring New Technologies with Decreasing IT Budgets
byInnoTech
 
Practical approaches to address government contracting problems
byJohn Gilligan
 
It aac cloud-acquisition_roadmap2012
byJohn Weiler
 
IT-AAC Roadmap for Sustainable Defense IT Reforms
byJohn Weiler
 
Weiler slideshow
byvjairam
 
Sales Compensation Solution Acquisition Best Practices Report
byDemand Metric
 
SolutionTo know that the team has identified all of the significa.pdf
byanushasarees
 
Congressional it reform-roadmap_2011
byJohn Weiler
 

More from Alan McSweeney

PDF
Shadow IT And The Failure Of IT Architecture
byAlan McSweeney
 
PDF
Critical Review of Open Group IT4IT Reference Architecture
byAlan McSweeney
 
PDF
Data Architecture for Solutions.pdf
byAlan McSweeney
 
PPTX
Operational Risk Management Data Validation Architecture
byAlan McSweeney
 
PDF
Data Profiling, Data Catalogs and Metadata Harmonisation
byAlan McSweeney
 
PDF
Solution Architecture Centre Of Excellence
byAlan McSweeney
 
PDF
Creating A Business Focussed Information Technology Strategy
byAlan McSweeney
 
PDF
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
PDF
Solution Security Architecture
byAlan McSweeney
 
PDF
Describing the Organisation Data Landscape
byAlan McSweeney
 
PDF
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
PDF
The Solution Architect As Product Manager.pdf
byAlan McSweeney
 
PDF
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
byAlan McSweeney
 
PDF
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
byAlan McSweeney
 
PDF
Analysis of Irish Mortality Using Public Data Sources 2014-2020
byAlan McSweeney
 
PDF
Ireland – 2019 And 2020 Compared In Data
byAlan McSweeney
 
PDF
Ireland 2019 and 2020 Compared - Individual Charts
byAlan McSweeney
 
PDF
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
byAlan McSweeney
 
PDF
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
byAlan McSweeney
 
PDF
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
byAlan McSweeney
 
Shadow IT And The Failure Of IT Architecture
byAlan McSweeney
 
Critical Review of Open Group IT4IT Reference Architecture
byAlan McSweeney
 
Data Architecture for Solutions.pdf
byAlan McSweeney
 
Operational Risk Management Data Validation Architecture
byAlan McSweeney
 
Data Profiling, Data Catalogs and Metadata Harmonisation
byAlan McSweeney
 
Solution Architecture Centre Of Excellence
byAlan McSweeney
 
Creating A Business Focussed Information Technology Strategy
byAlan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
Solution Security Architecture
byAlan McSweeney
 
Describing the Organisation Data Landscape
byAlan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
byAlan McSweeney
 
The Solution Architect As Product Manager.pdf
byAlan McSweeney
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
byAlan McSweeney
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
byAlan McSweeney
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
byAlan McSweeney
 
Ireland – 2019 And 2020 Compared In Data
byAlan McSweeney
 
Ireland 2019 and 2020 Compared - Individual Charts
byAlan McSweeney
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
byAlan McSweeney
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
byAlan McSweeney
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
byAlan McSweeney
 

Recently uploaded

PDF
DataLiva-LivaGRC- Business Software for Governance, Risk, and Compliance
byMustafa Kuğu
 
PDF
Top 10 Dedicated Server Providers in Stockholm (Updated Edition).pdf
byAtal Networks
 
PDF
Chapter 2 Computer Threat .pdf
byGetnet Tigabie Askale -(GM)
 
PDF
Best Bank Statement Converter Software - A Documentation-Based Meta-Analysis ...
bylewisconrada
 
PDF
Governing Agentic Enterprise - From Shadow AI to Autonomous Security.pdf
bysajjasridhar1990
 
PDF
The Cost of Missing Critical Connections in Data - Suspicious Behavior Detect...
byEnterprise Knowledge
 
PPTX
Oracle SCM Cloud Solutions for Smart Supply Chain Management
byChetu
 
PPTX
Full course that Prymehat uploads for you version 2
byOhenebaManu1
 
PDF
Master the FME Connector for ArcGIS: Streamlined Data Management & Robust Met...
bySafe Software
 
PPTX
02_Extended Warehouse Management Functions and Features.pptx
byUdayakumar218983
 
PPTX
Lecture 05. API Security for DevSecOps Eng.pptx
byvinocol222
 
PDF
Effective Ai powered mock interview .pdf
byamazingnishusingh766
 
PDF
Josh Chu Boston - An Innovative Technology Executive
byJosh Chu Boston
 
PDF
Early Signs of Constraint Loss in Modern System Design
byReality Drift Archive
 
PPTX
Flutter & Firebase Session Slides - GDG VESIT
bygdgcodecellcmpn
 
PDF
Purple Team - Active Directory and AzureAD v1
byVICTOR MAESTRE RAMIREZ
 
PPTX
Software Tools for penetration Testing (1).pptx
byAmosCheruiyot13
 
PPTX
Building Real-Time Voice AI — Udaiappa Ramachandran
byUdaiappa Ramachandran
 
PPTX
Unit 1 Introduction of Computer Networks
bySuvarnaSharma5
 
PPTX
IBM_NEXA_DAC2021 NEXA, a cloud-native platform for collaborative hardware log...
byArun Joseph
 
DataLiva-LivaGRC- Business Software for Governance, Risk, and Compliance
byMustafa Kuğu
 
Top 10 Dedicated Server Providers in Stockholm (Updated Edition).pdf
byAtal Networks
 
Chapter 2 Computer Threat .pdf
byGetnet Tigabie Askale -(GM)
 
Best Bank Statement Converter Software - A Documentation-Based Meta-Analysis ...
bylewisconrada
 
Governing Agentic Enterprise - From Shadow AI to Autonomous Security.pdf
bysajjasridhar1990
 
The Cost of Missing Critical Connections in Data - Suspicious Behavior Detect...
byEnterprise Knowledge
 
Oracle SCM Cloud Solutions for Smart Supply Chain Management
byChetu
 
Full course that Prymehat uploads for you version 2
byOhenebaManu1
 
Master the FME Connector for ArcGIS: Streamlined Data Management & Robust Met...
bySafe Software
 
02_Extended Warehouse Management Functions and Features.pptx
byUdayakumar218983
 
Lecture 05. API Security for DevSecOps Eng.pptx
byvinocol222
 
Effective Ai powered mock interview .pdf
byamazingnishusingh766
 
Josh Chu Boston - An Innovative Technology Executive
byJosh Chu Boston
 
Early Signs of Constraint Loss in Modern System Design
byReality Drift Archive
 
Flutter & Firebase Session Slides - GDG VESIT
bygdgcodecellcmpn
 
Purple Team - Active Directory and AzureAD v1
byVICTOR MAESTRE RAMIREZ
 
Software Tools for penetration Testing (1).pptx
byAmosCheruiyot13
 
Building Real-Time Voice AI — Udaiappa Ramachandran
byUdaiappa Ramachandran
 
Unit 1 Introduction of Computer Networks
bySuvarnaSharma5
 
IBM_NEXA_DAC2021 NEXA, a cloud-native platform for collaborative hardware log...
byArun Joseph
 

Solution Architecture and Solution Acquisition

  • 1.
    Solution Architecture and SolutionAcquisition Alan McSweeney http://ie.linkedin.com/in/alanmcsweeney https://www.amazon.com/dp/1797567616
  • 2.
    Introduction And Scope •This describes a systematised and structured approach to solution acquisition/procurement that involves solution architecture from the start • Involving solution architecture means that the true scope of both the required and subsequently acquired solution are therefore fully understood • By using such an approach poor solution acquisition outcomes are avoided February 2, 2020 2
  • 3.
    Solution Acquisition Demands,Trends And Outcomes February 2, 2020 3 More External Solution Acquisition and Less Solution Development More Hosted/Cloud Outsourced Solutions and Fewer On- premises Options Slow/ Unskilled/ Understaffed IT Solution Acquisition Informal/Dark/ Shadow IT Solution Acquisition Fragmented IT Solution Landscape Lack of Knowledge, Certainty and Control Over Solution Lifetime Costs Solution Scope Not Known or Defined at Acquisition Stage Digital Initiatives Extending IT Solutions to Outside the Organisation Greater Solution Complexity and Data Interoperability Needs More Complex Solutions Available Poor Overall Solution Acquisition Outcomes Solution Acquisition Not Aligned With Strategy Sourcing Objectives Increased Security and Data Integration Concerns Absence of Solution Architecture Involvement in Solution Acquisition Absence of Solution Architecture Involvement in Solution Acquisition
  • 4.
    Solution Acquisition DemandsAnd Trends • More External Solution Acquisition and Less Solution Development – greater tendency to buy rather than build • More Hosted/Cloud Outsourced Solutions and Fewer On-premises Options – solution suppliers are changing their delivery model resulting in more solutions are available in cloud/outsourced deployment model rather than being available to install on-premises • More Complex Solutions Available – more complex solutions are available from suppliers, especially in the areas of data and integration • Digital Initiatives Extending IT Solutions to Outside the Organisation – organisation digital transformation involves implementing solutions to a user population outside the organisation • Solution Scope Not Known or Defined at Acquisition Stage – solutions are acquired without their full scope being defined leading to lack of control over cost, resources and time • Absence of Solution Architecture Involvement in Solution Acquisition – solution acquisition proceeds without formal solution design with business users engaging directly with solution suppliers, leading to lack of control over cost, resources and time • Greater Solution Complexity and Data Interoperability Needs – solution complexity is increasing especially in the areas of data, integration and security • Slow/Unskilled/Understaffed IT Solution Acquisition – the solution acquisition skills of the organisation are not keeping pace with solution acquisition trends February 2, 2020 4
  • 5.
    Solution Acquisition Outcomes •Informal/Dark/Shadow IT Solution Acquisition – business functions bypass formal solution acquisition processes and go directly to solution suppliers without controls over cost, resources and time • Increased Security and Data Integration Concerns – multiple separate solution acquired without integration and security requirements being incorporated into solution design leads to additional work and risk • Poor Overall Solution Acquisition Outcomes – solution acquisition outcomes are poor in terms of solutions meeting business requirements and cost and delivery overruns occur • Fragmented IT Solution Landscape – solutions are acquired without an overall architectural context leading to a fragmented and poorly integrated solution landscape that is complex and costly to support and operate • Lack of Knowledge, Certainty and Control Over Solution Lifetime Costs – there is no real knowledge about the long-term solution costs • Solution Acquisition Not Aligned With Strategy Sourcing Objectives – solutions are acquired without adherence to any solution strategy or strategic supplier management leading to multiple February 2, 2020 5
  • 6.
    Solution Acquisition Demands,Trends And Outcomes • In summary: − More packaged/product/service-based solution acquisition activity − Increasing trend of solutions hosted outside the organisation − Increasing solution complexity − Increasing direct sourcing of solutions without formal acquisition process, including solution validation − Lack of knowledge of solution lifetime costs leading to increased solution acquisition and ownership costs − Poor solution acquisition outcomes and getting worse February 2, 2020 6
  • 7.
    Reasons For SolutionAcquisition • A need for a solution to a business problem, need or opportunity has been identified that is best met, for cost, time, flexibility and other reasons, by a solution acquired from a external supplier • Solution can be entirely packaged or customised and implemented on organisation infrastructure or delivered as a service • Axes of solution: − Degree to which solution is packaged or customised − Whether the solution is implemented on-premises or delivered as a hosted service − Whether the solution is supported in-house or by an external service provider February 2, 2020 7 Packaged Solution Customised Solution Outsourced/ Hosted Hosted In- House Externally Supported Internally Supported
  • 8.
    Solution Acquisition AndImplementation Failure Keeps Happening • Solution implementation failure keeps happening despite years of work on attempting to improve outcomes • For example, Standish Group figures on project outcomes from 1994 and 2015 • Most solution implementation projects still cost more, take longer and deliver fewer benefits than expected or planned • Other solution delivery statistics show higher rates of failure February 2, 2020 8 Survey Year Projects Succeeded Projects Challenged Projects Failed Projects Failed or Challenged 2015 36% 45% 19% 64% 2014 36% 47% 17% 64% 2013 41% 40% 19% 59% 2012 37% 46% 17% 63% 2011 39% 39% 22% 61% 2009 32% 44% 24% 68% 2006 35% 46% 19% 65% 2004 29% 53% 18% 71% 2000 28% 49% 23% 72% 1998 26% 24% 28% 52% 1996 27% 33% 40% 73% 1994 16% 53% 31% 84%
  • 9.
    The Contributing ElementsOf Poor IT Solution Acquisition 02 February 2020 9 Lack of IT Solution Procurement Skills and Experience Business Bypassing of Procurement Processes and Standards Slow Procurement Process Lack of Compliance with Strategic Sourcing Standards Inaccurate Information on Solution Requirements Unmanaged Solution Supplier Risk Poor Procurement Outcomes Poor Solution Outcomes Causes Delays in the Solution Procurement Leading to Results In Leads To Contributes To Adds To Causes Leeds To Causes
  • 10.
    Sources of SolutionAcquisition Challenges and Problems • If you know the sources of problems then you can mitigate their impact February 2, 2020 10 Sources of Acquisition Challenges and Problems Hidden, Unforeseen or Ignored Costs Ineffective Delivery Governance Contract Rigidity and Inflexibility Ineffective Contract Planning Required Solution Functionality Not Known or Defined Poor Solution Supplier Governance and Controls
  • 11.
    Sources of AcquisitionChallenges and Problems • Hidden, Unforeseen or Ignored Costs – actual costs that are incurred during solution delivery are not identified or are ignored during the solution acquisition process • Ineffective Delivery Governance – solution delivery controls are weak and not fit for purpose • Contract Rigidity and Inflexibility – solution delivery contract does not allow for change • Ineffective Contract Planning – the acquisition process does not plan for the contract to deliver a workable and usable solution • Required Solution Functionality Not Known or Defined – the required solution is not known during the acquisition process • Poor Solution Supplier Governance and Controls – the controls around the solution supplier, the management of the scope of the solution and negotiation with the supplier are poor and weak February 2, 2020 11
  • 12.
    The Scope OfThe Acquired Solution • The scope of the acquired solution and the (implied or actual) work required to get the solution operational and usable involves components of some or all the following types: • Complete IT solution view requires that the true extent of the solution being acquired be known • An acquired IT solution never consist of just software or a service – there are always other solution components that contribute to the real solution costs – see later details on Solution Topography • Solution architecture involvement in the solution acquisition process will ensure that the likely solution cost components are identified February 2, 2020 12 • Changes to Existing Systems • New Data Loads • New Custom Developed Applications • Training and Documentation • Information Storage Facilities • Central, Distributed and Communications Infrastructure • Acquired, Configured and Customised Software Products • Sets of Installation and Implementation Services • System Integrations/ Data Transfers/ Exchanges • Cutover/Transfer to Production And Support • Changes to Existing Business Processes • Operational Functions and Processes • New Business Processes • Parallel Runs • Organisational Changes • Enhanced Support/ Hypercare • Reporting and Analysis Facilities • Sets of Maintenance, Service Management and Support Services • Existing Data Conversions/Migrations • Application Hosting and Management Services
  • 13.
    Acquired Solution Components •The acquired solution will have many components of each of these types • The acquired solution may provide most of the required functionality but it will very rarely, if ever, deliver all • Knowing the likely solution components means the solution acquisition process is not proceeding blindly February 2, 2020 13
  • 14.
    Solution (Cost) ComponentsTypes Solution Components Changes to Existing Systems Component 1 Component 2 Component 3 Component 4 New Custom Developed Applications Component 1 Component 2 Component 3 Component 4 Information Storage Facilities Component 1 Component 2 Acquired, Configured and Customised Software Products Component 1 Component 2 Component 3 System Integrations/ Data Transfers/ Exchanges Component 1 Component 2 Component 3 Component 4 Changes to Existing Business Processes Component 1 Component 2 Component 3 Component 4 New Business Processes Component 1 Component 2 Component 3 Organisational Changes Component 1 Component 2 Component 3 Component 4 Reporting and Analysis Facilities Component 1 Component 2 Component 3 Existing Data Conversions/Migrations Component 1 Component 2 Component 3 Component 4 New Data Loads Component 1 Component 2 Component 3 Component 4 Training and Documentation Component 1 Component 2 Component 3 Central, Distributed and Communications Infrastructure Component 1 Component 2 Component 3 Sets of Installation and Implementation Services Component 1 Component 2 Cutover/Transfer to Production And Support Component 1 Component 2 Component 3 Operational Functions and Processes Component 1 Component 2 Component 3 Component 4 Parallel Runs Component 1 Component 2 Component 3 Component 4 Enhanced Support/ Hypercare Component 1 Component 2 Sets of Maintenance, Service Management and Support Services Component 1 Component 2 Application Hosting and Management Services Component 1 Component 2 Component 3 February 2, 2020 14
  • 15.
    Solution (Cost) Components •One of the key functions of an effective solution acquisition process and function is to know and be able to control solution lifetime costs • Knowledge of the solution cost profile is essential and necessary for successful cost control • You therefore need to know what will contribute to the solution lifetime costs • Solution architecture provides the structured approach to capturing all the cost contributors and knowing the true solution scope February 2, 2020 15
  • 16.
    Solution Acquisition Process •Solution components contribute to the long-term solution cost − Even an apparently packaged solution will have many components – see later details on Solution Topography • To understand the financial impact of the solution being acquired you need to have a good understanding of its constituent components and their impact on costs February 2, 2020 16
  • 17.
    Solution Components ContributionTo Lifetime Costs • Solution components contribute differently to the overall solution cost profile over time, depending on the characteristics of the solution • Cumulative solution lifetime costs can be very substantial February 2, 2020 17
  • 18.
    Planned And ActualCost Gap Due To Inaccurate Solution Cost Knowledge • Inaccurate solution cost knowledge can have a significant impact on unforeseen and unplanned costs over the lifetime of the solution February 2, 2020 18 Solution Knowledge Cost Gap
  • 19.
    As A ServiceSolution Costs • As-a-service pricing models change the way solution costs are incurred • Large recurring costs with unforeseen volume-based costs can lead to very large solution lifetime costs • Even for as-a-service solutions, other components will be needed, such as: − Access infrastructure − Data migration − Integration with other solutions − Support − Organisation and process changes − External backup and recovery February 2, 2020 19
  • 20.
    Objectives, Principles AndSuccess Factors Of Effective Solution Acquisition • Objectives – what is important to the solution acquisition process • Underpinning Principles – what supports effective solution acquisition • Success Factors – what contributes to solution acquisition February 2, 2020 20
  • 21.
    Objectives, Principles AndSuccess Factors Of Effective Solution Acquisition February 2, 2020 21 Principles Underpinning Solution Acquisition Objectives of Solution Acquisition Process Solution Acquisition Success Factors Enable Implementation and Operation of Business and Supporting Processes Improve Efficiency and Capability Enable Business Growth and Development Provide Choices and Options Select the Most Suitable Overall Solution Support Evidence-Based and Accurate Decisions Select Solution Based on Achieving Business Objectives Use the Most Suitable Solution Acquisition Process Establish Implementation Centre of Excellence Rapid Implementation Through Prototyping, Business Process and Organisation Change Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification Practical Pragmatic Achievable Expectations Continuing Joint Working Across Solution Delivery Team The Right Team With Significant Business Involvement and Commitment Maintain Focus on the Underlying Business Needs Extract the Maximum Business Value from the Acquired Solution Understanding of the Capabilities and Functionality of the Core Solution Management of Underlying Business Change
  • 22.
    Objectives of SolutionAcquisition Process • Enable Implementation and Operation of Business and Supporting Processes – the solution is being acquired to support the operation of new or existing business processes and their supporting processes efficiently and effectively, improving productivity and throughput, accuracy and consistency and reducing cost • Improve Efficiency and Capability – the solution acquisition must introduce new capabilities or enhance and improve existing organisation capabilities • Enable Business Growth and Development – the solution acquisition must enable the business to grow by enabling the delivery of new products and services or to protect existing business operations • Provide Choices and Options – the solution acquisition process must assess all realistic and achievable options to present choices to the solution acquirer • Select the Most Suitable Overall Solution – the solution acquisition process must result in the selection of the optimum option that balances potentially conflicting needs across solution stakeholders • Support Evidence-Based and Accurate Decisions – the solution acquisition process must use evidence-based assessment and evaluation approaches to eliminate bias and to provide an audit trail of decisions made February 2, 2020 22
  • 23.
    Principles Underpinning SolutionAcquisition • Select Solution Based on Achieving Business Objectives – the solution exists to either directly or indirectly enable the business meet defined objectives and the solution and its supplier should meet this flexibly and with the minimum of change • Use the Most Suitable Solution Acquisition Process – the degree of formality of and the structure of and number of stages in the solution acquisition process should be appropriate to the scale of the solution • Establish Implementation Centre of Excellence – solution acquisition should be supported by appropriately skilled and experienced personnel who can work productively and effectively and who are supported and enabled in their work • Rapid Implementation Through Prototyping, Business Process and Organisation Change – the solution acquisition process may need to validate solution functionality through prototyping and to define the changes in business processes and organisation structures • Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification – the core functionality of the acquired solution should be retained with as little modification as possible and necessary and the implementation activities should be designed to occur in parallel to reduce elapsed time February 2, 2020 23
  • 24.
    Solution Acquisition SuccessFactors • Extract the Maximum Business Value from the Acquired Solution – the solution acquisition process should seek to get the solution operational as soon as possible with as little modification as necessary and with the appropriate business change needed to maximise value • Maintain Focus on the Underlying Business Needs – the solution acquisition need to maintain focus at all times on the business needs that are driving the process • The Right Team With Significant Business Involvement and Commitment – the team allocated to the solution acquisition process needs to have the necessary skills and experience, be supported in their work and to have the necessary participation from the business functions that will use the solution and the team needs to be supported in its decision-making • Continuing Joint Working Across Solution Delivery Team – the solution delivery team, including the supplier, needs to work together for the duration of the solution acquisition process • Practical Pragmatic Achievable Expectations – realistic and achievable expectations have to be defined and agreed based on what the solution and the acquisition team can realistically achieve • Understanding of the Capabilities and Functionality of the Core Solution – the capabilities and limitations of the solution need to be understood from the outset • Management of Underlying Business Change – effective solution acquisition will require organisation change without which the solution will not operate optimally – this change needs to be understood, accepted, supported and sponsored February 2, 2020 24
  • 25.
    Objectives, Principles AndSuccess Factors Of Effective Solution Acquisition • Can be used as a checklist to assess the likely success of the solution acquisition project or to identify gaps that need to be filled to ensure successful outcomes • Recognise and focus on what is important February 2, 2020 25 Enable Implementation and Operation of Business and Supporting Processes Improve Efficiency and Capability Enable Business Growth and Development Provide Choices and Options Select the Most Suitable Overall Solution Support Evidence-Based and Accurate Decisions Select Solution Based on Achieving Business Objectives Use the Most Suitable Solution Acquisition Process Establish Implementation Centre of Excellence Rapid Implementation Through Prototyping, Business Process and Organisation Change Flexible Implementation Through Parallel Activities and Avoiding Unnecessary Core Solution Modification Extract the Maximum Business Value from the Acquired Solution Maintain Focus on the Underlying Business Needs The Right Team with Significant Business Involvement and Commitment Continuing Joint Working Across Solution Delivery Team Practical Pragmatic Achievable Expectations Understanding of the Capabilities and Functionality of the Core Solution Management of Underlying Business Change ObjectivesPrinciplesSuccessFactors
  • 26.
    Solution Topography • Theto-be-acquired solution will need to operate in and co- exist with an existing solution topography − Other existing solutions that it must interface with − Organisational processes, structures, standards and regulatory framework • The solution acquisition process needs to be aware of and take account of this wider solution topography • This is true even for as-a-service solutions February 2, 2020 26
  • 27.
    Solution Topography February 2,2020 27 Extended Solution Landscape With Integration With Other Solutions Individual Solution Landscape Business Process and Organisation Structure Common Data Architecture Common Security and Regulatory Compliance Architecture Common Enterprise Architecture Standards Common Financial Management Processes and Standards Common Service Management Processes and Standards
  • 28.
    Solution Topography • Irrespectiveof whether the solution is hosted inside or outside the organisation, it will still need to operate in a solution topography consisting of a number of logical layers February 2, 2020 28 Common Service Management Processes and Standards – solution support, service level management Common Financial Management Processes and Standards – solution cost and asset management Common Enterprise Architecture Standards – compliance with organisation technology standards and principles Common Security and Regulatory Compliance Architecture – integration of solution into overall security standards and operations Common Data Architecture – integration of solution data into the organisation data model and access to solution data, compliance with data regulations and standards Business Process and Organisation Structure – business processes and organisation functions that use the solution Extended Solution Landscape With Integration With Other Solutions – solution support, service level management, integration, data exchange Individual Solution Landscape – set of components that comprise the overall solution
  • 29.
    Solution Topography AndCloud/As-A-Service Based Solutions • Cloud-based or externally hosted and provided solutions do not eliminate the need for the solution to exist within the organisation solution topography − The profile of the solution topography may change but it does not go away − The acquired solution is never the scope of the actual solution that will be implemented, operated and used February 2, 2020 29
  • 30.
    Solution Acquisition ProcessOptions And Paths • There are various formal techniques that can be used to identify realistic and feasible solution options and supplier • The process needs to be tailored to the size and extent of the solution being acquired • Small, inexpensive, tactical solutions do not need a big process • PQQ (Pre-Qualification Questionnaire) – select short-list of solution suppliers based on formal technical evaluation and previous experience • RFI (Request for Information) – general request for information on suppliers and their solutions prior to a more detailed request to a short-list • RFP (Request for Proposal) – formal solution procurement specification looking for detailed and fully costed proposals to meet detailed solution requirements • RFS (Request for Solution) – less formal process looking for suppliers to propose solutions to resolve a business problem or meet a business need February 2, 2020 30 PQQ (Pre- Qualification Questionnaire) RFS (Request for Solution) RFP (Request for Proposal) RFI (Request for Information)
  • 31.
    Solution Acquisition AndPublic Procurement • The acquisition process for solutions in public sector organisations is more controlled and restricted than that which applies in the private sector − (Lots of) formal specification documentation − Precise timelines − Organised interactions with suppliers − Auditable selection and decision process • However, the same principles relating to solution architecture involvement in solution acquisition can and should apply in the public sector February 2, 2020 31
  • 32.
    Public Procurement OptionsHigh-Level Overview February 2, 2020 32 Open Open Procedure Single stage tendering with public competition and no prior short-listing or pre-qualification. There can be large numbers of proposals to evaluate. Restricted Procedure Two-stage process with pre-qualification based on technical and experience factors. Short-listed suppliers are invited to submit proposals. Specific Circumstances Competitive Dialogue No standard, readily available solutions available or the required solution is innovative or highly complex or the requirements cannot be specified exactly or previous tender responses were not acceptable. Publish requirements and enter into dialogue with selected suppliers. Competitive Procedure with Negotiation Two stage process with prequalification based on technical and experience factors. Second stage follows the Competitive Dialogue approach. Innovation Partnership No standard, readily available solutions available. Establish innovation partnerships to perform research and development to develop innovative solution. The solution developed is then bought. Negotiated Procedure Without Prior Publication Limited application such as urgency, uniqueness or exclusive intellectual property.
  • 33.
    Solution Acquisition ProcessHas A Cost For All Participants • Be aware of the cost that are being imposed on suppliers by your solution acquisition process • Suppliers incur a cost in engaging in solution acquisition − Cost and associated long solution acquisition process frequently leads to smaller (possible more creative, flexible, cheaper) suppliers self-excluding themselves from the process − Larger (and implicitly more expensive suppliers) can bear the cost of sale associated with the solution acquisition process • It is rarely the case of Publish It And They Will Bid • Unless a very good supplier bids with a very good product, the outcome of the solution acquisition process is all too frequently that either a good product supplied by an average supplier or an average product supplied by a good supplier wins − It rarely leads to the best solution being supplied by the best supplier • Be aware of the need to encourage suppliers and to grow and nurture a supplier ecosystem − Competitive tension between suppliers is in your interest − There is a necessary management overhead associated with this • Solution acquisition is not a fire and forget process February 2, 2020 33
  • 34.
    Ineffective Solution AcquisitionHas A Cost • Direct Incurred Costs − Project cost overrun − Project benefits shortfall • Indirect and Hidden Costs − Late delivery of required business capabilities − Additional resources, effort and other costs required to manage, maintain, operate and support the solution − Missed revenue from new services − Poor customer experience leading to lost revenue − Organisation loses competitivity − Lost ability to gain access to new technologies − Additional cost and/or lost revenue means other opportunities are not explored − Shorter than expected solution lifespan and the need to replace it earlier February 2, 2020 34
  • 35.
    Hidden Costs OfPoor Solutions Are Much Greater Than Direct Costs February 2, 2020 35 Project Cost Overrun Project Benefits Shortfall Late Delivery Of Required Business Capabilities Additional Resources, Effort And Other Costs Required To Manage, Maintain, Operate And Support The Solution Missed Revenue From New Services Poor Customer Experience Leading To Lost Revenue Organisation Loses Competitivity Lost Ability To Gain Access To New Technologies Additional Cost And/Or Lost Revenue Means Other Opportunities Are Not Explored Shorter Than Expected Solution Lifespan And The Need To Replace It Earlier
  • 36.
    Ineffective Solution AcquisitionHas A Cost • The long-term consequences of ineffective solution acquisition can be very substantial and can reverberate for a very long time February 2, 2020 36
  • 37.
    Strategic Misrepresentation DuringSolution Procurement • Deliberate distortion or falsification of information relating to solution acquisition costs, complexity, required functionality, solution availability, resource availability, time to implement in order to get solution acquisition approval • Caused by distorted incentives and lack of control, due diligence and governance • Two dimensions of strategic misrepresentation for solution acquisition approval − Acquirer-side • Deliberately understating costs to gain acceptance with unspoken understanding that costs will increase • Actual scope not accepted or intentionally concealed • Not willing to face reality of high costs or hiding the real costs to make decision-making or obtaining approval easier • Inflating costs or selecting unnecessarily complex and expensive solution option for status and prestige reasons • Overstatement or understatement of requirements • Unnecessary and uncontrolled complexity • Contending for limited resources or striving for an improved position − Supplier-side • Under-costed opportunistic solution proposals with calculated intention to increase revenue subsequently through aggressive change control and scope management after delivery initiation February 2, 2020 37
  • 38.
    Strategic Misrepresentation InSolution Acquisition • Strategic misrepresentation in the solution acquisition process means: − Solution acquisition costs are underestimated − Solution benefits are overestimated/losses underestimated − Solution delivery risks are underrated − Solution functionality required is deficient − Solution delivery time longer than stated • Strategic misrepresentation is very real and its impact should not be underestimated or ignored February 2, 2020 38
  • 39.
    Overlap Of StrategicMisrepresentations February 2, 2020 39 Acquirer-Side Strategic Misrepresentation Supplier-Side Strategic Misrepresentation Overlap of Strategic Misrepresentations
  • 40.
    Overlap And MultiplicationOf Strategic Misrepresentations February 2, 2020 40 Acquirer-Side Strategic Misrepresentation Supplier-Side Strategic Misrepresentation I deliberately underestimate solution scope, cost, complexity, time to get solution acquisition approval I deliberately underestimate cost, complexity, time to be awarded the solution delivery work Overlap of Strategic Misrepresentations I do not question your underestimated cost, complexity, time to get solution acquisition approval
  • 41.
    Overlap Of StrategicMisrepresentations • Where the two types of misrepresentations coincide, solution acquisition can become very problematic – the impacts will be multiplied • Where strategic misrepresentation occurs on both sides of the acquisition process the solution outcomes will most likely be very poor February 2, 2020 41
  • 42.
    Supplier-Side Strategic Misrepresentation •Competitive tendering process can result in opportunistic behaviour where suppliers deliberately exclude necessary solution elements and activities to reduce apparent solution acquisition cost • Suppliers can also reduce their (initial) fees to win the business, reducing the initial profits • Gives rise to a solution delivery environment where the supplier is constantly generating changes to increase revenue and profits • This gives rise to an inevitable and unavoidable chain reaction of cost increases, delays and worsening relationship between supplier and customer February 2, 2020 42 Deliberate Exclusion of Necessary Components Low Initial Work Rates Quoted Undercosted, Underscoped and Unprofitable Solution Acquisition Proposal Change Control By Supplier to Generate Additional Revenue to Increase Profitability Changes Required to Increase Scope to Include Necessary Components Drive- up Costs Solution that Is Overbudget, Behind Schedule, Less Functional, Delivering Fewer Benefits and More Costly to Operate
  • 43.
    The Paradox OfStrategic Misrepresentation • Paradoxically, solutions that appear to have lower costs and significant benefits tend to those selected for implementation • So solutions with the largest cost underestimates and the greatest benefit overestimates appear to offer the greatest value • These are the worst solutions to implement but the most likely to be selected for implementation • Strategic misrepresentation acts as a compelling anti- Darwinian force promoting the survival of the least fit and least suitable but most misrepresented solution February 2, 2020 43
  • 44.
    Other Factors RelatedTo Strategic Misrepresentation In Solution Acquisition • Optimism Bias – belief in the strong likelihood of success and underestimation of risks in solution acquisition without justification or positive action to ensure such outcomes • Planning Fallacy - unrealistically low estimates of the time and cost it will take to complete a task and n overestimate of the benefits that will be derived, despite previous experience February 2, 2020 44
  • 45.
    Spectrum Of OutcomesOf Solution Acquisition Failure February 2, 2020 45 Complete Solution Success: On-time, On-budget, Being Used And Delivering Specified Benefits Solution Delivery Late Complete Solution Failure: Cancelled, Unused, Rejected More Expensive to Operate And Support Than Planned Or Expected Unstable and Unreliable Requiring Additional Support Cost and Effort Solution Has Reduced Functionality Requiring Workarounds Not What Is Wanted Or What Was Required/ Envisaged Functionality Delivered Does Not Meet Business Requirements Significant Rework Or Replacement Required Success FailureChallenged Solution Delivery Over Budget Performance And/Or Operational Problems Not All Specified Business Benefits And Savings Not Delivered Low Medium High Very High
  • 46.
    Spectrum Of OutcomesOf Solution Acquisition Failure February 2, 2020 46 Solution Failure Type Likely Impact Range of Failure Description Significant Rework Or Replacement Required High to Very High Elements of the solution as delivered need to be replaced or significantly reworked to operate as planned or needed. Solution Delivery Late Low to Medium The solution exceeded its original budget. Solution Delivery Over Budget Low to Medium The solution exceeded its schedule. Unstable and Unreliable Requiring Additional Support Cost and Effort Medium to Very High The solution does not work as automatically and without intervention as expected or designed or is unstable or unreliable and requires a degree of manual support work. More Expensive to Operate And Support Than Planned Or Expected Low to High The solution works but the effort and cost to support and operate it is greater than planned. Performance And/Or Operational Problems Low to Medium The solution does not have the required throughput or response times as expected or designed. The span of this challenge is generally low to medium but in extreme circumstances, the impact can be high. Solution Has Reduced Functionality Requiring Workarounds Low to Medium Some of the initially designed functionality was omitted from the delivered solution requiring additional manual effort and work outside the core solution components. Not What Is Wanted Or What Was Required/ Envisaged High to Very High The delivered solution is not what the business wanted or expected or does not fulfil their needs. Not All Specified Business Benefits And Savings Not Delivered Low to Medium Some of the expected benefits have not been realised. Functionality Delivered Does Not Meet Business Requirements Medium to Very High Some of the functionality contained in the solution does not work exactly as the solution consumer expected or wanted.
  • 47.
    Solution Acquisition Failure– Less For More • At its simplest, the solution failures includes solutions that are characterised by Less for More −More Cost– the original budget was exceeded or other unanticipated costs arose or the solution costs more to operate −More Time – the original schedule was exceeded which means the business were late in having access to the solution −Delivered Less – the original scope was reduced, making the solution less usable or requiring additional unplanned for effort or the solution takes longer or more effort to use or required manual workarounds or the solution does not meet the expectations of the target solution consumers −Achieved Less – the solution does not deliver the expected benefits and savings or the solution is less widely used that expected or planned February 2, 2020 47
  • 48.
    Solution Acquisition Failure– Double Deficit February 2, 2020 48 Success – Required Functionality Delivered, Benefits Achieved, Solution Used Success – On Time, On Budget Degree of Failure - More Time, More Money Degree of Failure - Less Functionality, Fewer Benefits, Less Usage Solution Functionality and Benefits Deficit Solution Time and Money Deficit
  • 49.
    Discrepancies Between StatedAnd Actual Solution Acquisition Characteristics February 2, 2020 49 Stated Costs Actual Benefits Stated Risks Stated Functionality Needed Actual Time Stated Benefits Actual Costs Stated Time Actual Risks Actual Functionality Needed
  • 50.
    Solution Architecture InvolvementIn Solution Acquisition Avoids The Dangers Of Strategic Misrepresentation • Solution architecture has the skills and experience to define the real scope of the solution being acquired • Scope of the fully required solution is made fully visible • Cost estimates are more accurate • Attempts to bypass or ignore necessary solution components and their costs are trapped and stopped • Solution acquirers are made aware of the actual likely solution acquisition cost • Ensures that solution acquisition is rigorous February 2, 2020 50
  • 51.
    Acquisition Capabilities AcrossThe Acquisition Process • Identified capabilities are needed along the acquisition process to ensure good solution acquisition outcomes February 2, 2020 51 Solution Acquisition Project Planning and Management Solution Requirements Definition, Validation and Validation Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination
  • 52.
    Solution Acquisition InterfacesWith Other Organisation Functions And Processes February 2, 2020 52 Solution Acquisition Supplier ManagementIT Architecture (Enterprise, Data) Operations Support And Service Management Security Financial And Solution Investment Management Compliance, Regulation, Legal Business Strategy And Planning
  • 53.
    Solution Acquisition InterfacesWith Other Organisation Functions • The solution acquisition function and process needs operate with other organisation functions to work optimally − Business Strategy And Planning – the solutions being acquired should assist with the achievement of the business strategy and objectives. Depending on their scale their acquisition should be subject to strategic assessment and a business case − Financial And Solution Investment Management – the solution acquisition and operating costs should be subject to financial management and controls and to investment standards and processes − IT Architecture (Enterprise, Data) – the solution being acquired should comply with IT Architecture standards − Compliance, Regulation, Legal – irrespective of where the solution resides, it will be subject to the same compliance and regulatory standards and processes as other solutions. Externally hosted solutions may be subject to greater regulations − Operations Support And Service Management – the solution will have to be operable and supportable in order to be operated and supported − Supplier Management – solution acquisition should be subject to strategic supplier management standards − Security – the solution, access to it and the data its processes should be subject to organisation security standards and processes February 2, 2020 53
  • 54.
    Solution Acquisition CapabilityLayers • Core solution acquisition − Pre-solution acquisition – preparation, planning, definition, mobilisation − Solution acquisition – the acquisition and decision process, the selection of the solution and supplier and the definition of the delivery contract • Expanded solution acquisition − Solution delivery and implementation – verify that what is supplied is what was agreed and monitor the operation of solution delivery − Solution validation – validate that the solution operates as intended and that it delivers the benefits stated − Solution acquisition operation – review the operation of the solution acquisition process, identify lessons that can be learned and update the process based on experience • Extended solution acquisition − Solution acquisition process definition and implementation – define and implement the solution acquisition process, train those involved and establish structure − Solution acquisition process measurement and improvement – measure the outcomes achieved and update and improve process • Solution acquisition does not stop after the acquisition decision made – it is not a fire-and-forget activity February 2, 2020 54
  • 55.
    ExtendedSolutionAcquisition ExpandedSolutionAcquisition CoreSolutionAcquisition Core, Expanded AndExtended Solution Acquisition Capabilities February 2, 2020 55 Solution Requirements Definition, Validation and Verification Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination Solution Acquisition Project Planning and Management Solution Acquisition Process Definition and Implementation Solution Acquisition Process Measurement and Improvement
  • 56.
    Acquisition Capabilities AcrossThe Acquisition Process • An effective process, well-implemented and consistently applied, means dependable and repeatable solution acquisition and successful outcomes February 2, 2020 56
  • 57.
    Objectives Of AcquisitionProcess February 2, 2020 57 Solution Requirements Definition, Validation and Verification Solution Design and Specification Supplier Agreement Management Development Solution Acquisition Risk Management Solicitation and Supplier Agreement Definition Solution Acquisition Verification Solution Acquisition Validation Solution Decision Analysis and Determination Solution Acquisition Project Planning and Management Objective of Solution Acquisition is to Go From Here … … To Here, Having a Usable Solution Within The Agreed Costs, Within the Agreed Time, Providing the Required Functionality, Having the Agreed Operational Characteristics and Overheads and Achieving the Expected Benefits
  • 58.
    Key Core andExpanded Solution Acquisition Capabilities • Core − Solution Acquisition Project Planning and Management • Use standard project process to create and manage the solution acquisition project • Manage stakeholders • Monitor project progress and take action to prevent performance problems − Solution Acquisition Risk Management • Identify potential problems in advance and plan risk handling and management actions to eliminate or reduce the impact of such problems − Solution Requirements Definition, Validation and Verification • Gather, define, document customer solution function and operational requirement and the solution delivery and use contractual requirements • Manage requirements through the duration of the solution acquisition project − Solution Design and Specification • Create an integrated description of the desired solution that links the individual requirements into a usable conceptual solution design, identifying the full solution scope and its likely components, including the wider solution topography and solution interfaces and infrastructure − Solicitation and Supplier Agreement Development • Prepare a set of material to be used to seek solution delivery proposals from supplier and to evaluate proposals and select a supplier − Solution Decision Analysis and Determination • Analyse solution proposals and alternatives using formal auditable evaluation and selection process and using agreed evaluation factors − Solution Acquisition Verification • Ensure that the selected solution will be usable, operable, supportable, maintainable that that it can meet the functional and operational requirements and fit into the wider solution landscape • Expanded − Supplier Agreement Management Determination • Ensure that the supplier performs the solution delivery work according to the agreed specification − Solution Acquisition Validation • Validate that the delivered and implemented solution operates as intended, achieves its intended objectives and the benefits identified are realised February 2, 2020 58
  • 59.
    Overlap Of CoreCapabilities Across Solution Architecture And Procurement Functions • The required capabilities and the delivery will be split or shared across the solution architecture and procurement functions February 2, 2020 59 Solution Architecture Procurement Solution Acquisition Project Planning and Management Solution Acquisition Risk Management Solution Requirements Definition, Validation and Verification Solution Design and Specification Solution Proposal and Supplier Agreement Definition Solution Decision Analysis and Determination Solution Acquisition Verification
  • 60.
    Need To InvolveSolution Architecture In Solution Procurement Process From The Start • Solution architecture needs to be involved is solution acquisition from the start • The solution architecture functions has the skills and experience to define the real scope of the solution being acquired • This maximises successful solution acquisition February 2, 2020 60
  • 61.
    Structure Of SolutionAcquisition Capabilities • Each capability has a number of objectives and purposes • To achieve each objective there are activities • This structure provides a generic framework to create customised plans for individual solution acquisition exercises • Allows skills to be identified, gaps remediated February 2, 2020 61 Capabilities Objectives Activities Tasks
  • 62.
    Solution Acquisition CoreCapabilities And Their Major Objectives Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Establish Project Manage Stakeholders and Communications Monitor Progress Against Plan Manage Issues Solution Acquisition Risk Management Establish Risk Management Framework Identify and Analyse Risks Handle Risks Solution Requirements Definition, Validation and Validation Gather Solution Requirements Gather Contractual Requirements Analyse and Validate Requirements Manage Requirements Solution Design and Specification Statement of Concept Of Need/ Goal/Objective Review Stakeholder Requirements Initial Architecture Review Gather Solution Requirements Create, Review and Agree Solution Architecture Design and Specification Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Identify Potential Suppliers Solicit Proposals Solution Decision Analysis and Determination Define Assessment Factors Evaluate and Review Solution Proposals Solution Acquisition Verification Define Validation Process Define Negotiation Process Perform Validation Select Supplier and Solution Negotiate With Selected Supplier February 2, 2020 62
  • 63.
    Balance Between DetailAnd Precision And Speed And Flexibility Of Acquisition • The scope and detail of the solution design phase of the architecture process depends on factors such as: − The degree of certainty of the required solution functionality − The solution solicitation process – RFP or RFP − The likely amount of new technology that the solution may include − The likely size and scale of the solution being acquired − The time available to create a solution design − The complexity of the wider solution topography within which the acquired solution will reside and operate • There needs to be a balance between the detail of the solution design presented to potential suppliers and openness to allowing suppliers propose creative and innovative solutions using new technologies • Too detailed and prescriptive a solution specification may result in a locked-in solution design resulting in options and alternatives not be presented or not fully explored February 2, 2020 63
  • 64.
    Conceptual Solution Architecture •A Conceptual Solution Architecture (CSA) focusses on the core functional and system components of the solution • The CSA provides a framework for identifying solution requirements across the solution landscape • It also assists with compiling business stakeholder requirements as requirements can be elicited within the context of the complete end-to-end solution concept framework • A CSA solution design might be sufficient for the solution acquisition process February 2, 2020 64
  • 65.
    Solution Design AsPart Of Solution Acquisition • Where the pace of technology change is fast or the need for new business solutions quickly is great, is there time to create lengthy detailed solution design documentation? • Is there time for a lengthy solution acquisition process? • Can potential suppliers bear the cost of a long solution acquisition process? • Complexity of solution acquisition means technical controls are needed • A good conceptual solution design eliminates the need for solution acquisition based on a long list of requirements • Reduces overall solution acquisition time February 2, 2020 65
  • 66.
    Including Solution ArchitectureIn Solution Acquisition Attempts To Solve The All Too Common Problems Of … • Lack of response to business needs • Slow and costly solution delivery • Unforeseen costs • High solution maintenance and operation costs • Fragile solutions with many manual workarounds • Excessive and duplicated implementation and operation effort • Duplicated and costly investments in many solutions • Siloed solutions with lack of integration • Poor return on investment • Too little, too late, not what is wanted or needed February 2, 2020 66
  • 67.
    Solution Acquisition CapabilitiesAnd Activities • The next sections list the activities associated with each capability • This provides a detailed generalised structure for a solution acquisition exercise • This can be customised to suit the specific requirements of the exercise February 2, 2020 67 Capabilities Objectives Activities Tasks
  • 68.
    February 2, 202068 Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Setup the Standard Solution Acquisition Project Process Setup the Specific Solution Acquisition Project Using the Standard Process Review and Reuse Previous Solution Acquisition Project Process Information for Project Planning Allocate Project Resources, Facilities, Library and Templates Create Extended Solution Acquisition Plan That Includes Quality Plan, Risk Plan and Verification Plan Assemble and Train Project Team and Sub- Teams Suggest Updates and Changes to Standard Solution Acquisition Project Process, if Appropriate Establish Project Establish And Agree the Solution Acquisition Approach for this Solution Agree Solution Acquisition Project Scope Define Project Dependencie s Create Solution Acquisition Project Work Breakdown and Product List Create Estimates for Solution Acquisition Project Define Major Project Stages Create Solution Acquisition Resource and Cost Estimates Allocate Project Budget Agree Project Resources and Schedule Define Skills Gaps and Knowledge and Skills Requirement s Finalise and Agree Solution Acquisition Project Plans Manage Stakeholders and Communicati ons Monitor Stakeholder Commitment s Manage Project Communicati ons Monitor Progress Against Plan Monitor Project Progress and Delivery Monitor Resource Work Quality Monitor Project Collateral Management Perform and Publish Project Reviews Manage Issues Analyse and Document Issues Agree and Take Corrective Action Manage Performance of Corrective Action Update Plan Based on Corrective Action Solution Acquisition Risk Management Establish Risk Management Framework Create and Agree Project Risk Framework and Risks Sources and Types Agree Approach to Analyse, Categorise and Prioritise Risks Agree Approach to Managing Risks Identify and Analyse Risks Identify Solution Acquisition Project Risks Analyse, Categorise and Prioritise Risks Publish Risks Analysis Handle Risks Create and Agree Risk Mitigation Approach Implement Agreed Risk Mitigation Approach Solution Requirements Definition, Validation and Validation Gather Solution Requirement s Define and Agree Approach to Solution Requirement s Gathering and Analysis Agree People to be Consulted in Gathering Solution Requirement s Gather Requirement s for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Solution Requirement s Gather Operational and Delivery Contractual Requirement s Gather Operational and Delivery Contractual Requirement s for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Operational and Delivery Contractual Requirement s Include Operational and Delivery Contractual Requirement s in Solution Acquisition Analyse and Validate Requirement s Consolidate and Analyse Solution and Operational and Delivery Contractual Requirement s Validate Deliverability, Usability and Utility of Requirement s Identify Impact of Requirement s Distribute and Discuss Requirement s Analysis Rationalise Requirement s Manage Requirement s Establish Requirement s Analysis Factors and Approach Including Requirement s Change Management Define and Agree Sources of Requirement s Evaluate Requirement s as They Arise Distribute Requirement Impact Assessments and Agree Requirement s Record and Manage Changes to Requirement s Maintain Project Tracking and Traceability Ensure Consistency of Requirement s Solution Design and Specification Statement of Concept Of Need/ Goal/ Objective Define Source of Solution Need and Objectives to be Achieved Agree and Refine Solution Statement Validate Solution Need Against Business Case Validate Solution Need Against Business Strategy and Objectives Review Stakeholder Requirement s Review Requirement s Against Solution Statement and Business Case Create Rationalised and Consolidated Set of Stakeholder Requirement s Initial Architecture Review Create Initial Inventory of Solution Components and Interfaces with Existing Solutions Create Initial Inventory of Solution Functions Create Initial Inventory of Solution Actors Create Initial Inventory of Solution New and Existing Business Process Create Initial Inventory of Solution Data Entities Create Initial Conceptual Solution Architecture Gather Solution Requirement s Define Overall Expected Solution Operation, Use and Constraints Define Solution Usage and Operation Scenarios /Use Cases for Requirement s Assessment Define the Solution Operational Environment and Boundaries Including Interactions with Other Operational Solutions Extend Conceptual Solution Architecture and Design Assess Previously Gathered Requirement s Against Solution Scenarios and Design and Identify Gaps Review and Fill Requirement s Gaps Create Overall Aggregated Solution Requirement s Specification Create, Review and Agree Solution Architecture Design and Specification Update Conceptual Solution Architecture Design Review and Agree Conceptual Solution Architecture Design Create Solution Acquisition Design Specification Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Agree Scope and Contents of Acquisition Solicitation Package Create Solution Acquisition Solicitation Package Review and Agree Solution Acquisition Solicitation Package Maintain and Update Solution Acquisition Solicitation Package Agree Publication Process and Targets Identify Potential Suppliers Research Solutions and Options Available Research Solution Advertiseme nt and Publication Options Available Create List of Potential Solutions and Suppliers Agree Supplier Contact Management Approach Solicit Proposals and Manage Proposal Process Publish and Distribute Solution Acquisition Solicitation Package to Agreed Target Suppliers Manage Questions and Communicati ons from Suppliers Solution Decision Analysis and Determination Define Assessment Factors Define and Agree Approach to Performing Solution Evaluation Including Shortlisting Define Delivery, Functional, Technical, Operational and Contractual Evaluation Information Sources Prepare Evaluation Scripts Prepare Demonstratio n Evaluation Scripts Prepare Reference Contact Scripts Prepare Lifetime Cost Financial Analysis Model Define Legal and Compliance Requirement s Define and Agree Solution Evaluation Factors and Weights Define Evaluation Work Products Evaluate and Review Solution Proposals Conduct Initial Solution Evaluation and Create Shortlist Conduct Detailed Delivery, Functional, Technical, Operational and Contractual Evaluation on Shortlisted Solutions Review Solution Demonstratio ns Contact References Perform Lifetime Cost Financial Analysis Agree Solutions to Select for Final Verification Solution Acquisition Verification Define Validation Process Define and Agree Scope of Solution Verification (Implementat ion, Technical, Functional, Operation, Interface, Financial, Contract) Define Verification Factors and Weights Define Verification Approach – Use Cases, Process Inventory Walkthrough, Requirement s Traceability, Data Flow Assemble the Verification Team Define Verification Work Products Create the Verification Environment Define Negotiation Process Define and Agree Supplier Negotiation Approach Define Solution Contractual, Delivery and Operation Requirement s Perform Validation Perform Solution Verification Agree and Document Solution Verification Results Select Supplier and Solution Agree Selected/ Preferred Solution and Supplier Negotiate With Selected/ Preferred Supplier Negotiate With Supplier
  • 69.
    Solution Acquisition ProjectPlanning and Management – Scope • Develop the solution acquisition project plan based on the acquisition strategy including identifying work products, creating estimates, identifying and acquiring resources and creating a schedule • Adopt the standard acquisition project process to the needs of the specific project • Manage the creation of standard acquisition project interim and final assets and deliverables • Get commitment to the plan • Maintain the plan • Allocate and manage acquisition project objectives, commitments and tasks • Handle and communicate with relevant stakeholders • Monitor project progress and take corrective action if progress varies from planned • Handle issues as they arise February 2, 2020 69
  • 70.
    Solution Acquisition ProjectPlanning and Management – Capabilities and Activities Solution Acquisition Project Planning and Management Use Standard Solution Acquisition Project Process Setup the Standard Solution Acquisition Project Process Setup the Specific Solution Acquisition Project Using the Standard Process Review and Reuse Previous Solution Acquisition Project Process Information for Project Planning Allocate Project Resources, Facilities, Library and Templates Create Extended Solution Acquisition Plan That Includes Quality Plan, Risk Plan and Verification Plan Assemble and Train Project Team and Sub-Teams Suggest Updates and Changes to Standard Solution Acquisition Project Process, if Appropriate Establish Project Establish And Agree the Solution Acquisition Approach for this Solution Agree Solution Acquisition Project Scope Define Project Dependencies Create Solution Acquisition Project Work Breakdown and Product List Create Estimates for Solution Acquisition Project Define Major Project Stages Create Solution Acquisition Resource and Cost Estimates Allocate Project Budget Agree Project Resources and Schedule Define Skills Gaps and Knowledge and Skills Requirements Finalise and Agree Solution Acquisition Project Plans Manage Stakeholders and Communications Monitor Stakeholder Commitments Manage Project Communications Monitor Progress Against Plan Monitor Project Progress and Delivery Monitor Resource Work Quality Monitor Project Collateral Management Perform and Publish Project Reviews Manage Issues Analyse and Document Issues Agree and Take Corrective Action Manage Performance of Corrective Action Update Plan Based on Corrective Action February 2, 2020 70
  • 71.
    Solution Acquisition RiskManagement – Scope • Identify potential problems in solution acquisition before they happen so any negative impact can be lessened or avoided • Risk management is a constant process concerned with anticipating potential issues that might affect the solution acquisition process February 2, 2020 71
  • 72.
    Solution Acquisition RiskManagement – Capabilities And Activities February 2, 2020 72 Solution Acquisition Risk Management Establish Risk Management Framework Create and Agree Project Risk Framework and Risks Sources and Types Agree Approach to Analyse, Categorise and Prioritise Risks Agree Approach to Managing Risks Identify and Analyse Risks Identify Solution Acquisition Project Risks Analyse, Categorise and Prioritise Risks Publish Risks Analysis Handle Risks Create and Agree Risk Mitigation Approach Implement Agreed Risk Mitigation Approach
  • 73.
    Solution Requirements Definition,Validation and Validation – Scope • Specify and communicate the approach to gathering requirements • Agree the set of business users to be involved in providing requirements • Gather, analyse, validate business user requirements, expectations, limitations and integration for the expected solution • Assign priorities to requirements • Collate and classify the requirements • Define the operational and quality requirements • Manage the requirements lifecycle February 2, 2020 73
  • 74.
    Solution Requirements Definition,Validation and Validation – Capabilities and Activities February 2, 2020 74 Solution Requirements Definition, Validation and Validation Gather Solution Requirements Define and Agree Approach to Solution Requirements Gathering and Analysis Agree People to be Consulted in Gathering Solution Requirements Gather Requirements for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Solution Requirements Gather Operational and Delivery Contractual Requirements Gather Operational and Delivery Contractual Requirements for Solution to be Acquired Analyse, Rationalise, Consolidate and Prioritise Operational and Delivery Contractual Requirements Include Operational and Delivery Contractual Requirements in Solution Acquisition Analyse and Validate Requirements Consolidate and Analyse Solution and Operational and Delivery Contractual Requirements Validate Deliverability, Usability and Utility of Requirements Identify Impact of Requirements Distribute and Discuss Requirements Analysis Rationalise Requirements Manage Requirements Establish Requirements Analysis Factors and Approach Including Requirements Change Management Define and Agree Sources of Requirements Evaluate Requirements as They Arise Distribute Requirement Impact Assessments and Agree Requirements Record and Manage Changes to Requirements Maintain Project Tracking and Traceability Ensure Consistency of Requirements
  • 75.
    Dangers Of SolutionRequirements • Requirements gathered during solicitation sessions with business users tend to be: − Sparse and disconnected − Isolated and disintegrated statements − Inconsistent − Incomplete − Disjointed − Conflicting − Uncosted − Unprioritised − Representations of specific points of functionality that do not aggregate into a defined and integrated solution − Missing significant solution components (and therefore solution delivery costs) such as organisation changes, business processes, data migrations, integration with other solutions • Business user do not have and should not be expected to have this level of knowledge − A source of additional unstated and implied requirements February 2, 2020 75
  • 76.
    Requirements • The realityis that what is gathered during requirements workshops, meetings, interviews, questionnaires and other activities are not solution requirements but business stakeholder requirements • Stakeholder requirements must be translated into solution requirements which is turn must be translated into a solution design • Requirements gathering is a means to an end and not an end in itself • Requirements gathering should never be part of the delivery project but be the subject of an analysis and architecture design exercise prior to any delivery project • You cannot know what the scope of the project is until the solution that needs to be delivered is known February 2, 2020 76
  • 77.
    Sparse Requirements AndOverall Solution Framework • Business stakeholder requirements never represent what the full solution needs in order to operate successfully • Business stakeholder requirements have to be passed through a solution design filter to create a complete solution design February 2, 2020 77 = Specific Requirement = Solution Factor Not Explicitly Listed As Requirement
  • 78.
    Solution Design andSpecification – Scope • Agree the purpose and objective of the intended solution • Review the initially gathered requirements • Create an initial conceptual architecture that identifies all the solution components • Complete solution gaps • Refine the solution design February 2, 2020 78
  • 79.
    Solution Design andSpecification – Capabilities and Activities February 2, 2020 79 Solution Design and Specification Statement of Concept Of Need/ Goal/Objective Define Source of Solution Need and Objectives to be Achieved Agree and Refine Solution Statement Validate Solution Need Against Business Case Validate Solution Need Against Business Strategy and Objectives Review Stakeholder Requirements Review Requirements Against Solution Statement and Business Case Create Rationalised and Consolidated Set of Stakeholder Requirements Initial Architecture Review Create Initial Inventory of Solution Components and Interfaces with Existing Solutions Create Initial Inventory of Solution Functions Create Initial Inventory of Solution Actors Create Initial Inventory of Solution New and Existing Business Process Create Initial Inventory of Solution Data Entities Create Initial Conceptual Solution Architecture Gather Solution Requirements Define Overall Expected Solution Operation, Use and Constraints Define Solution Usage and Operation Scenarios/Use Cases for Requirements Assessment Define the Solution Operational Environment and Boundaries Including Interactions with Other Operational Solutions Extend Conceptual Solution Architecture and Design Assess Previously Gathered Requirements Against Solution Scenarios and Design and Identify Gaps Review and Fill Requirements Gaps Create Overall Aggregated Solution Requirements Specification Create, Review and Agree Solution Architecture Design and Specification Update Conceptual Solution Architecture Design Review and Agree Conceptual Solution Architecture Design Create Solution Acquisition Design Specification
  • 80.
    Solution Design Process February2, 2020 80 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Elicit Stakeholder Requirements Formalise Stakeholder Requirements Define Solution Requirements Analyse Solution Requirements Define Solution Architecture and Design Analyse, Evaluate and Refine Solution Architecture Implementation Project Initial Architecture Review and Options
  • 81.
    Solution Design Process StageScope Initial Concept Of Need/ Goal/ Objective The business have an idea for a solution based on an apparent need to solve a problem, to do what is currently not possible, to react or respond to an external demand or to be able to achieve a new objective. Formal Statement Of Need/ Goal/ Objective This formalises the initial concept to introduce greater consistency and detail. It serves to understand the business, objectives, purposes and potential organisational impacts. It describes what the ideal solution will do. It also identifies the high-level potential system impacts. Initial Architecture Review and Options This uses the formal statement of need to create an initial high-level view of the overall solution, its new and existing systems and applications components, the required functionality, their interfaces, the required processes and the business functions impacted. This provides a container for the requirements and a vision for the solution. Stakeholder Requirements Collection and Specification This uses this initial architectural review output in a structured way to elicit and formalise the set of stakeholder requirements across the dimensions of functionality and processes. Solution Requirements Collection and Specification The solution requirements specification is a fuller, more detailed and elaborated set of solution requirements encompassing all the solution components. This includes the requirements explicitly identified by stakeholders and the implied requirements. Solution Architecture Design and Specification This is the detailed solution specification derived from the stakeholder and solution requirements. Implementation Project This uses the detailed solution specification to act as an input to project definition and to create a realistic implementation plan, schedule, set of costs and required resources. February 2, 2020 81
  • 82.
    Solution Design Process •There is a decision point after each stage where a decision is made if it is worthwhile to proceed to the next stage February 2, 2020 82 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options Decision Points
  • 83.
    Solution Design Process •Not all concepts make it all the way to implementation • Process needs to accommodate this • Do as little as possible to achieve as much as possible to make an informed decision on whether and how to proceed to the next stage in the solution journey February 2, 2020 83 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
  • 84.
    Solution Design Process- Iterations • Solution design process is not necessarily linear • Stages can be iterated a number of times to different levels of detail February 2, 2020 84 Initial Concept Of Need/ Goal/ Objective Formal Statement Of Need/ Goal/ Objective Stakeholder Requirements Collection and Specification Solution Requirements Collection and Specification Solution Architecture Design and Specification Implementation Project Initial Architecture Review and Options
  • 85.
    Solution Proposal andSupplier Agreement Definition – Scope • Create the set of information to be used as part of the solution acquisition process • Agree the approach and options to publishing the solution acquisition information package • Identify list of potential solutions and their suppliers • Publish the solution acquisition information package • Manage solution acquisition supplier communications and requests for information and clarifications February 2, 2020 85
  • 86.
    Solution Proposal andSupplier Agreement Definition – Capabilities and Activities February 2, 2020 86 Solution Proposal and Supplier Agreement Definition Prepare Proposal Package Agree Scope and Contents of Acquisition Solicitation Package Create Solution Acquisition Solicitation Package Review and Agree Solution Acquisition Solicitation Package Maintain and Update Solution Acquisition Solicitation Package Agree Publication Process and Targets Identify Potential Suppliers Research Solutions and Options Available Research Solution Advertisement and Publication Options Available Create List of Potential Solutions and Suppliers Agree Supplier Contact Management Approach Solicit Proposals and Manage Proposal Process Publish and Distribute Solution Acquisition Solicitation Package to Agreed Target Suppliers Manage Questions and Communications from Suppliers
  • 87.
    Solution Decision Analysisand Determination – Scope • Apply agreed evaluation factors to the proposed solutions and their importance • Prepare set of supporting material to be used during evaluation including lifetime cost model • Create initial solution shortlist • Conduct detailed evaluation on shortlisted solutions • Agree set of solutions to be verified February 2, 2020 87
  • 88.
    Solution Decision Analysisand Determination – Capabilities and Activities February 2, 2020 88 Solution Decision Analysis and Determination Define Assessment Factors Define and Agree Approach to Performing Solution Evaluation Including Shortlisting Define Delivery, Functional, Technical, Operational and Contractual Evaluation Information Sources Prepare Evaluation Scripts Prepare Demonstration Evaluation Scripts Prepare Reference Contact Scripts Prepare Lifetime Cost Financial Analysis Model Define Legal and Compliance Requirements Define and Agree Solution Evaluation Factors and Weights Define Evaluation Work Products Evaluate and Review Solution Proposals Conduct Initial Solution Evaluation and Create Shortlist Conduct Detailed Delivery, Functional, Technical, Operational and Contractual Evaluation on Shortlisted Solutions Review Solution Demonstrations Contact References Perform Lifetime Cost Financial Analysis Agree Solutions to Select for Final Verification
  • 89.
    Solution Acquisition Verification– Scope • Perform detailed delivery, implementation, technical, functional, operation and interface/integration verification of the short-listed solutions to verify that they will work, can be delivered • Perform contractual and financial validation of the short- listed solutions • Select preferred supplier • Negotiate with the preferred supplier February 2, 2020 89
  • 90.
    Solution Acquisition Verification– Capabilities and Activities February 2, 2020 90 Solution Acquisition Verification Define Validation Process Define and Agree Scope of Solution Verification (Implementation, Technical, Functional, Operation, Interface, Financial, Contract) Define Verification Factors and Weights Define Verification Approach – Use Cases, Process Inventory Walkthrough, Requirements Traceability, Data Flow Assemble the Verification Team Define Verification Work Products Create the Verification Environment Define Negotiation Process Define and Agree Supplier Negotiation Approach Define Solution Contractual, Delivery and Operation Requirements Perform Validation Perform Solution Verification Agree and Document Solution Verification Results Select Supplier and Solution Agree Selected/Preferred Solution and Supplier Negotiate With Selected/Preferred Supplier Negotiate With Supplier
  • 91.
    Full Set ofSolution Capabilities, Objectives And Activities • The full set of generalised solution acquisition capabilities, objectives and activities will allow a customised path to be defined through the solution acquisition exercise • A realistic delivery plan can be developed • Schedule, resources and effort can be identified in advance • Progress can be tracked February 2, 2020 91
  • 92.
    Summary • There ismore packaged/product/service-based solution acquisition activity • Increasing trend of solutions hosted outside the organisation • Solution acquisition outcomes are poor and getting worse • Poor solution acquisition has long-term consequences and costs • Solution architecture provides the structured approach to capturing all the cost contributors and knowing the true solution scope • The to-be-acquired solution needs to operate in and co-exist with an existing solution topography and the solution acquisition process needs to be aware of and take account of this wider solution topography • Cloud-based or externally hosted and provided solutions do not eliminate the need for the solution to exist within the organisation solution topography • Strategic misrepresentation in solution acquisition is the deliberate distortion or falsification of information relating to solution acquisition costs, complexity, required functionality, solution availability, resource availability, time to implement in order to get solution acquisition approval • Strategic misrepresentation is very real • Solution architecture has the skills and experience to define the real scope of the solution being acquired • An effective structured solution acquisition process, well-implemented and consistently applied, means dependable and repeatable solution acquisition and successful outcomes February 2, 2020 92
  • 93.