1. The value of your ‘software and IT’-quality:
what about the investor’s point of view
Geert Janssen
29/4/2016
26/04/16
1
2. Today’s question: what about the quality of
your software and your IT organization?
26/04/16
2
Does it affect the
value of your
company/
investment?
Should you worry
about it?
3. We will cover the following aspects ...
the need for a consistent approach and tooling to assess the
maturity of the company from an IT perspective
the added value of quality assurance throughout the investment
lifecycle
IT risk assurance dimensions and approach
expressing risk responses in terms of IT objectives
the use of software quality assurance in practice (examples).
26/04/16
3
11. IT Risk & Assurance - Approach
11
What price should we pay? > focus: value for money
Should we invest? > focus: value assessment, risk mitigation
Assure IT is managed well! > focus: continuous
improvement / quality control, value augmentation
Provide transparancy!
> focus: safeguard value
Similar process across the investment
lifecycle however focus differs!
Dealflow phase
(1) IT Quick Scan
Due Diligence phase
(2) IT Due Diligence
Nurturing phase
(3) IT Risk Assessments
Divestment (Exit) phase
(4) IT Vendor Due Diligence
12. IT Risk & Assurance – 4-Step Process
Scoping
Preparation &
Identification
Research &
Analysis
Report
&
Remedy
26/04/16
12
- Lifecycle status
- Investor focus
- Assess IT Resources
& gather evidence
- Perform a scenario
analysis
- Assess IT Control
Areas
- Generate health
factors
- Identify threats / risks
- Analyze frequency &
impact in terms of Risk
Appetite/Tolerance
- Analyze technical
metrics
- Express Risk
Responses in terms of
IT Objectives
(business terms)
- Define remediation
plan
14. IT Risk & Assurance - Dimensions
26 April 2016
14
Value
Maturity
Risk
• Balance IT risks versus
risk tolerance (continuity,
compliance, …)
• Value to the Company
• Technical Debt
• Organization
• Process
• Product
• Which risks are
acceptable?
• To what extend does IT
contribute to the overall
business objectives?
• What hidden costs are
present?
• Where are we today
and where should
we be?
22. THE USE OF SOFTWARE QUALITY
ASSURANCE IN PRACTICE
Examples
26/04/16
22
23. Software Quality Audit Process
26/04/16
23
We follow a 4-step process.
Continuous improvement is key.
A typical exercise requires between 5
and 10 man days of work.
Maximum 2 à 3 iterations per year,
mostly only 1 per year!
24. Opening IT assurance discussions
26/04/16
24
Developers
– Most developers have limited
ideas on the quality of their code.
– Hence, a typical eye-opener.
Management
– Easy to interpret quality
dashboard, also for IT illiterate
resources.
– Sound basis for enabling
discussions on the value of IT
assurance, which are typically
neglected as focus is on creating
marketshare.
25. Linking payment milestones to
improvements
26/04/16
25
A basis for the
investment manager
to manage the
investment based on
facts & figures.
A means to agree
upon improvement
actions and
potentially linking
those to payment
milestones.
26. Mitigating Investment Risk
26/04/16
26
One should typically run the
application audit on a dedicated
machine forcing the development
team to handover all required source
code items (dll’s, certificates, …).
In most cases compilation is an issue
in terms of missing components,
hardcoding, …
In one case it took us 2 weeks to get
the platform compiled correctly!
27. Assuring minimum level of documentation
26/04/16
27
Code documentation is important as change of ownership during startup years is
likely to happen more often than within mature/stable environments.
Additionally, lack of documentation ‘outside’ the code (e.g. functional design) is
typically higher in startups than in more mature organizations.
28. Assuring minimum level of documentation
26/04/16
28
Our focus on improving code documentation is especially important for the complex
(McCabe Cyclomatic Complexity) code areas.
29. Identifying organization weaknesses
26/04/16
29
Code audits often identify weaknesses in the organization.
As a consequence we agree with the organization to focus on improving their
weaknesses through hiring/training.
30. Assuring continuous improvement
26/04/16
30
Health factor ‘scores’ as such are relative and often result in discussions.
More important is to agree upon continued positive evolution and link commitment of
continued evolution into a contractual agreement.
!
31. Being transparent is key
26/04/16
31
Having ‘red’ scores is not a
shame.
Knowing where to focus on and
having insight into areas for
improvement is more important.
Being transparent on weak spots
during exit discussions is more
important than not knowing where
you stand.
!
=> Any weak spot identified during due diligence will jeopardize your negotiation position.
32. A trigger for re-engineering
Assessing application quality – as opposed to code quality only –
allows to discover a potential ‘spaghetti’ architecture.
Resulting in revising the entire architecture and identifying modules /
components for renewal.
26/04/16
32
33. Agreeing upon corrective actions
Added value of having end-to-end view in limited
time compared to manual audits.
Limited involvement required from development
team.
Final presentation to present / discuss the results
during a half / one day workshop.
Goal is to confirm / agree upon corrective actions.
26/04/16
33
34. IS SOFTWARE AND IT QUALITY
IMPORTANT FOR AN INVESTOR?
In Synopsis
26/04/16
34
35. ... Yes, it is!
If you don’t measure you don’t know
One reaps what one sows
Moving in the right direction as of day 1 is key
A means to professionalize the organization
‘Conditio sine qua non’ during exit discussions
26/04/16
35
