SlideShare a Scribd company logo
1 of 93
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

What's hot

Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
Alan McSweeney
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security Architecture
Alan McSweeney
 
Review of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability ModelsReview of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability Models
Alan McSweeney
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT Architecture
Alan McSweeney
 
IT4IT real life examples & myths and rumors dispelled
IT4IT real life examples & myths and rumors dispelledIT4IT real life examples & myths and rumors dispelled
IT4IT real life examples & myths and rumors dispelled
Tony Price
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Alan McSweeney
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference Architecture
Alan McSweeney
 

What's hot (20)

Digital Transformation And Solution Architecture
Digital Transformation And Solution ArchitectureDigital Transformation And Solution Architecture
Digital Transformation And Solution Architecture
 
Solution Security Architecture
Solution Security ArchitectureSolution Security Architecture
Solution Security Architecture
 
Review of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability ModelsReview of Information Technology Function Critical Capability Models
Review of Information Technology Function Critical Capability Models
 
A Brief Introduction to Enterprise Architecture
A Brief Introduction to  Enterprise Architecture A Brief Introduction to  Enterprise Architecture
A Brief Introduction to Enterprise Architecture
 
Solution Architecture Framework
Solution Architecture FrameworkSolution Architecture Framework
Solution Architecture Framework
 
So You Think You Need A Digital Strategy
So You Think You Need A Digital StrategySo You Think You Need A Digital Strategy
So You Think You Need A Digital Strategy
 
IT4IT - The Full Story for Digital Transformation - Part 1
IT4IT - The Full Story for Digital Transformation - Part 1IT4IT - The Full Story for Digital Transformation - Part 1
IT4IT - The Full Story for Digital Transformation - Part 1
 
Design Science and Solution Architecture
Design Science and Solution ArchitectureDesign Science and Solution Architecture
Design Science and Solution Architecture
 
Shadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT ArchitectureShadow IT And The Failure Of IT Architecture
Shadow IT And The Failure Of IT Architecture
 
IT4IT real life examples & myths and rumors dispelled
IT4IT real life examples & myths and rumors dispelledIT4IT real life examples & myths and rumors dispelled
IT4IT real life examples & myths and rumors dispelled
 
The Myth Of Requirements
The Myth Of RequirementsThe Myth Of Requirements
The Myth Of Requirements
 
Modeling TOGAF with ArchiMate
Modeling TOGAF with ArchiMateModeling TOGAF with ArchiMate
Modeling TOGAF with ArchiMate
 
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
Data Integration, Access, Flow, Exchange, Transfer, Load And Extract Architec...
 
Critical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference ArchitectureCritical Review of Open Group IT4IT Reference Architecture
Critical Review of Open Group IT4IT Reference Architecture
 
Business Focused IT Strategy
Business Focused IT StrategyBusiness Focused IT Strategy
Business Focused IT Strategy
 
TOGAF 9.2 - Transforming Business
TOGAF 9.2  -  Transforming BusinessTOGAF 9.2  -  Transforming Business
TOGAF 9.2 - Transforming Business
 
EA foundations (Views, Repository, Artifacts and Metamodel)
EA foundations (Views, Repository, Artifacts and Metamodel)EA foundations (Views, Repository, Artifacts and Metamodel)
EA foundations (Views, Repository, Artifacts and Metamodel)
 
Digital Operating Model & IT4IT
Digital Operating Model & IT4ITDigital Operating Model & IT4IT
Digital Operating Model & IT4IT
 
Introducing The Open Group IT4IT™ Standard
Introducing The Open Group IT4IT™ StandardIntroducing The Open Group IT4IT™ Standard
Introducing The Open Group IT4IT™ Standard
 
IT4IT™ - Managing the Business of IT
IT4IT™ - Managing the Business of ITIT4IT™ - Managing the Business of IT
IT4IT™ - Managing the Business of IT
 

Similar to Solution Architecture and Solution Acquisition

Solution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdfSolution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdf
Alan McSweeney
 
Solution Design Overview - HelpSystems RJS
Solution Design Overview - HelpSystems RJSSolution Design Overview - HelpSystems RJS
Solution Design Overview - HelpSystems RJS
Bill Whalen, CDIA+
 
FinalPresentation-Verizon Internship 2006
FinalPresentation-Verizon Internship 2006FinalPresentation-Verizon Internship 2006
FinalPresentation-Verizon Internship 2006
Yanice Jackson
 
Make or buy, insourcingoutsourcing
Make or buy, insourcingoutsourcingMake or buy, insourcingoutsourcing
Make or buy, insourcingoutsourcing
Ankit
 
15. Brian Bailey presentation 2 DQ Asia Pacific 2010
15. Brian Bailey presentation 2 DQ Asia Pacific 201015. Brian Bailey presentation 2 DQ Asia Pacific 2010
15. Brian Bailey presentation 2 DQ Asia Pacific 2010
Brian Bailey
 
Agile Method requirement engineering.ppt
Agile Method requirement engineering.pptAgile Method requirement engineering.ppt
Agile Method requirement engineering.ppt
ubaidullah75790
 
Successfully Implementing an Aggregate Spend Solution
Successfully Implementing an Aggregate Spend SolutionSuccessfully Implementing an Aggregate Spend Solution
Successfully Implementing an Aggregate Spend Solution
Huron Consulting Group
 
Transform your IT into a Strategic Asset
Transform your IT into a Strategic AssetTransform your IT into a Strategic Asset
Transform your IT into a Strategic Asset
YJT Solutions
 

Similar to Solution Architecture and Solution Acquisition (20)

Solution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdfSolution Architecture and Solution Estimation.pdf
Solution Architecture and Solution Estimation.pdf
 
Solution Design Overview - HelpSystems RJS
Solution Design Overview - HelpSystems RJSSolution Design Overview - HelpSystems RJS
Solution Design Overview - HelpSystems RJS
 
FinalPresentation-Verizon Internship 2006
FinalPresentation-Verizon Internship 2006FinalPresentation-Verizon Internship 2006
FinalPresentation-Verizon Internship 2006
 
Bi and strategic decision making
Bi and strategic decision makingBi and strategic decision making
Bi and strategic decision making
 
Extending Business Architecture with Regulatory Architecture using Decisions ...
Extending Business Architecture with Regulatory Architecture using Decisions ...Extending Business Architecture with Regulatory Architecture using Decisions ...
Extending Business Architecture with Regulatory Architecture using Decisions ...
 
DSS Case on Planpower
DSS Case on PlanpowerDSS Case on Planpower
DSS Case on Planpower
 
Improve Analytic Results with Decision Modeling
Improve Analytic Results with Decision ModelingImprove Analytic Results with Decision Modeling
Improve Analytic Results with Decision Modeling
 
Make or buy, insourcingoutsourcing
Make or buy, insourcingoutsourcingMake or buy, insourcingoutsourcing
Make or buy, insourcingoutsourcing
 
Key Elements of a Successful Data Governance Program
Key Elements of a Successful Data Governance ProgramKey Elements of a Successful Data Governance Program
Key Elements of a Successful Data Governance Program
 
How To Use PMO Intake Processes To Manage Your Project Portfolio
How To Use PMO Intake Processes To Manage Your Project PortfolioHow To Use PMO Intake Processes To Manage Your Project Portfolio
How To Use PMO Intake Processes To Manage Your Project Portfolio
 
Uncovering the Business Value of Managed IT Services
Uncovering the Business Value of Managed IT ServicesUncovering the Business Value of Managed IT Services
Uncovering the Business Value of Managed IT Services
 
Decision Management & Cloud as a Platform for Predictive Analytics
Decision Management & Cloud as a Platform for Predictive AnalyticsDecision Management & Cloud as a Platform for Predictive Analytics
Decision Management & Cloud as a Platform for Predictive Analytics
 
Business intelligence for manufacturing
Business intelligence for manufacturingBusiness intelligence for manufacturing
Business intelligence for manufacturing
 
15. Brian Bailey presentation 2 DQ Asia Pacific 2010
15. Brian Bailey presentation 2 DQ Asia Pacific 201015. Brian Bailey presentation 2 DQ Asia Pacific 2010
15. Brian Bailey presentation 2 DQ Asia Pacific 2010
 
Info System 2
Info System 2Info System 2
Info System 2
 
Agile Method requirement engineering.ppt
Agile Method requirement engineering.pptAgile Method requirement engineering.ppt
Agile Method requirement engineering.ppt
 
Successfully Implementing an Aggregate Spend Solution
Successfully Implementing an Aggregate Spend SolutionSuccessfully Implementing an Aggregate Spend Solution
Successfully Implementing an Aggregate Spend Solution
 
Spend Analysis Identified as Key to CPO Success
Spend Analysis Identified as Key to CPO SuccessSpend Analysis Identified as Key to CPO Success
Spend Analysis Identified as Key to CPO Success
 
Transform your IT into a Strategic Asset
Transform your IT into a Strategic AssetTransform your IT into a Strategic Asset
Transform your IT into a Strategic Asset
 
Day 1: ICT Strategic Planning, Mr. Soufiane Ben Moussa, CTO, House of Commons...
Day 1: ICT Strategic Planning, Mr. Soufiane Ben Moussa, CTO, House of Commons...Day 1: ICT Strategic Planning, Mr. Soufiane Ben Moussa, CTO, House of Commons...
Day 1: ICT Strategic Planning, Mr. Soufiane Ben Moussa, CTO, House of Commons...
 

More from Alan McSweeney

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdf
Alan McSweeney
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Alan McSweeney
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation Solutions
Alan McSweeney
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Alan McSweeney
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Alan McSweeney
 

More from Alan McSweeney (20)

Data Architecture for Solutions.pdf
Data Architecture for Solutions.pdfData Architecture for Solutions.pdf
Data Architecture for Solutions.pdf
 
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
Validating COVID-19 Mortality Data and Deaths for Ireland March 2020 – March ...
 
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
Analysis of the Numbers of Catholic Clergy and Members of Religious in Irelan...
 
Solution Architecture And Solution Security
Solution Architecture And Solution SecuritySolution Architecture And Solution Security
Solution Architecture And Solution Security
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
Data Privatisation, Data Anonymisation, Data Pseudonymisation and Differentia...
 
Solution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation SolutionsSolution Architecture And (Robotic) Process Automation Solutions
Solution Architecture And (Robotic) Process Automation Solutions
 
Data Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata HarmonisationData Profiling, Data Catalogs and Metadata Harmonisation
Data Profiling, Data Catalogs and Metadata Harmonisation
 
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
Comparison of COVID-19 Mortality Data and Deaths for Ireland March 2020 – Mar...
 
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
Analysis of Decentralised, Distributed Decision-Making For Optimising Domesti...
 
Operational Risk Management Data Validation Architecture
Operational Risk Management Data Validation ArchitectureOperational Risk Management Data Validation Architecture
Operational Risk Management Data Validation Architecture
 
Ireland 2019 and 2020 Compared - Individual Charts
Ireland   2019 and 2020 Compared - Individual ChartsIreland   2019 and 2020 Compared - Individual Charts
Ireland 2019 and 2020 Compared - Individual Charts
 
Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020Analysis of Irish Mortality Using Public Data Sources 2014-2020
Analysis of Irish Mortality Using Public Data Sources 2014-2020
 
Ireland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In DataIreland – 2019 And 2020 Compared In Data
Ireland – 2019 And 2020 Compared In Data
 
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
Analysis of Possible Excess COVID-19 Deaths in Ireland From Jan 2020 to Jun 2020
 
Creating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology StrategyCreating A Business Focussed Information Technology Strategy
Creating A Business Focussed Information Technology Strategy
 
Describing the Organisation Data Landscape
Describing the Organisation Data LandscapeDescribing the Organisation Data Landscape
Describing the Organisation Data Landscape
 
Solution Architecture Centre Of Excellence
Solution Architecture Centre Of ExcellenceSolution Architecture Centre Of Excellence
Solution Architecture Centre Of Excellence
 
Solution Architecture and Solution Complexity
Solution Architecture and Solution ComplexitySolution Architecture and Solution Complexity
Solution Architecture and Solution Complexity
 
Why Solutions Fail and the Business Value of Solution Architecture
Why Solutions Fail and the Business Value of Solution ArchitectureWhy Solutions Fail and the Business Value of Solution Architecture
Why Solutions Fail and the Business Value of Solution Architecture
 

Recently uploaded

Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
FIDO Alliance
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
FIDO Alliance
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc
 

Recently uploaded (20)

Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
Choosing the Right FDO Deployment Model for Your Application _ Geoffrey at In...
 
Top 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development CompaniesTop 10 CodeIgniter Development Companies
Top 10 CodeIgniter Development Companies
 
ERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage IntacctERP Contender Series: Acumatica vs. Sage Intacct
ERP Contender Series: Acumatica vs. Sage Intacct
 
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptxHarnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
Harnessing Passkeys in the Battle Against AI-Powered Cyber Threats.pptx
 
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...Hyatt driving innovation and exceptional customer experiences with FIDO passw...
Hyatt driving innovation and exceptional customer experiences with FIDO passw...
 
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
Observability Concepts EVERY Developer Should Know (DevOpsDays Seattle)
 
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
TrustArc Webinar - Unified Trust Center for Privacy, Security, Compliance, an...
 
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
ASRock Industrial FDO Solutions in Action for Industrial Edge AI _ Kenny at A...
 
Working together SRE & Platform Engineering
Working together SRE & Platform EngineeringWorking together SRE & Platform Engineering
Working together SRE & Platform Engineering
 
Overview of Hyperledger Foundation
Overview of Hyperledger FoundationOverview of Hyperledger Foundation
Overview of Hyperledger Foundation
 
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on ThanabotsContinuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
Continuing Bonds Through AI: A Hermeneutic Reflection on Thanabots
 
Using IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & IrelandUsing IESVE for Room Loads Analysis - UK & Ireland
Using IESVE for Room Loads Analysis - UK & Ireland
 
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdfSimplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
Simplified FDO Manufacturing Flow with TPMs _ Liam at Infineon.pdf
 
State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!State of the Smart Building Startup Landscape 2024!
State of the Smart Building Startup Landscape 2024!
 
Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024Extensible Python: Robustness through Addition - PyCon 2024
Extensible Python: Robustness through Addition - PyCon 2024
 
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The InsideCollecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
Collecting & Temporal Analysis of Behavioral Web Data - Tales From The Inside
 
Design and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data ScienceDesign and Development of a Provenance Capture Platform for Data Science
Design and Development of a Provenance Capture Platform for Data Science
 
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
Event-Driven Architecture Masterclass: Integrating Distributed Data Stores Ac...
 
The Metaverse: Are We There Yet?
The  Metaverse:    Are   We  There  Yet?The  Metaverse:    Are   We  There  Yet?
The Metaverse: Are We There Yet?
 
Event-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream ProcessingEvent-Driven Architecture Masterclass: Challenges in Stream Processing
Event-Driven Architecture Masterclass: Challenges in Stream Processing
 

Solution Architecture and Solution Acquisition

  • 1. Solution Architecture and Solution Acquisition 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 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
  • 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 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
  • 8. 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%
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 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) 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
  • 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 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. 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
  • 22. 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. 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
  • 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 • 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
  • 29. 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
  • 30. 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)
  • 31. 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
  • 32. 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.
  • 33. 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
  • 34. 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
  • 35. 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
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. Overlap Of Strategic Misrepresentations February 2, 2020 39 Acquirer-Side Strategic Misrepresentation Supplier-Side Strategic Misrepresentation Overlap of Strategic Misrepresentations
  • 40. 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
  • 41. 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
  • 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 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
  • 44. 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
  • 45. 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
  • 46. 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.
  • 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 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
  • 50. 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
  • 51. 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
  • 52. 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
  • 53. 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
  • 54. 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
  • 55. 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
  • 56. 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
  • 57. 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
  • 58. 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
  • 59. 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
  • 60. 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
  • 61. 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
  • 62. 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
  • 63. 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
  • 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 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
  • 66. 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
  • 67. 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
  • 68. 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
  • 69. 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
  • 70. 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
  • 71. 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
  • 72. 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
  • 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 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
  • 76. 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
  • 77. 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
  • 78. 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
  • 79. 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
  • 80. 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
  • 81. 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
  • 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 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
  • 86. 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
  • 87. 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
  • 88. 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
  • 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 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
  • 92. 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