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

93.
More Information
Alan McSweeney
http://ie.linkedin.com/in/alanmcsweeney
https://www.amazon.com/dp/1797567616
02 February 2020 93