Mergers and acquisitions, management buyouts and even simple
changes in senior management all require a measure of due diligence
in assessing software assets.
- Purchased software
- In-house developed software
- Software assets brought to the table as part of a merger
- Software to be the foundation of a new business venture
Investors quite rightly insist on independent due diligence
when investigating legal and financial issues, yet are surprisingly
willing to take the word of in-house staff at face value. When
a merger is intended to save money by rationalisation, these
are precisely the people who should not be believed without
independent advice.
- Is the software as complete as people say?
- Is the software a suitable platform for extension; or
should a replacement plan be put in place?
- Is the use of up-to-the-minute software technology an
advantage or disadvantage in this case?
Prices
for Diligence
Our rates for this work start at £1,100 for a first day's
assessment. Large diligence contracts can be priced more cheaply.
Expertise in some specific areas attracts additional costs.
Contact
or call 07884 355096 for a quick conversation.
Typical
Diligence Assessments
When
Klebos systematised its process for performing software asset
diligence, we were surprised at the amount and variety of
this work that we had done already.
It is the nature of this procedure that our assessments
are confidential, but these are typical of the work that we
have done:
- Diligently assess the software detritus left behind by
a dot-bomb crash with a view to purchase; where no original
software staff are available and only the code is available.
Technologies: VRML, order-entry eCommerce, payment system,
massive web-server architecture. The question: "It cost
millions, but what's it worth to us now?"
- Assess an Intranet/Extranet website written by an external
contractor. Technologies: IIS4, ASP, JavaScript. Industry:
biomedical device manufacturing. The question: "How much
would it cost to migrate to a commercial content-management
system or are we stuck with this contractor/supplier?"
- Assess an in-house developed salesman's laptop presentation
system; with order-entry at the customer site and data replication/synchronisation
by modem in the evenings. Technologies: Access, Visual Basic,
SQL-Server. Industry: insurance. The question: "Is this
software a suitable basis for extension and enhancement?"
- Assess a hardware and software test-suite, purchased by
previous management, for suitability in a new joint venture
of somewhat different focus. Technologies: Netscape (iPlanet)
web servers and http-stress tools, fault database and reporting
tools. Industry: location-based web-mapping services. The
question: "Did we waste our money?".
- Assess an in-house developed document/drawing management
system. Technologies: Solaris, C, curses (!). Industry:
mechanical engineering design. The question: "Can this really
do what we need - for just the immediate future?"
Process
and Methodology
Klebos has observed that both the software itself and the
process used to develop it require diligent examination. Interviews
with software development staff are extremely helpful when
assessing in-house software. Off-the-shelf software requires
a different approach; often we have to assess whether it would
work even though it is currently not yet installed and configured.
Klebos does not attempt an exhaustive examination - that
would be expensive and also usually prohibitively time-consuming.
Our skill is in producing a quick, sound professional judgement.
We also pride ourselves on explaining ourselves in terms of
the immediate financial and tactical decisions facing the
senior management.
Our process typically takes the following form, where the
whole sequence should take only a few days:
- Meet the financial decision makers and discover the tactical
options that need to be decided.
- Get as many parts of the software source code, database
schemata and documentation as can be conveniently and quickly
obtained.
- Discuss the objective of the software with the chief
designer or substitute. This will involve technical discussions
of the architecture.
- Determine how the objective partly matches the needs
articulated by the financial decision makers, i.e. does
it attempt to do the right thing?
- Assess how far the objective is realised in the software
as it exists, i.e. does it work?
- Assess the software's scope for extension and modification
(and maintenance). This involves some study of the historical
and current software development process.
- Frame interim conclusions and present in a short meeting.
In our experience, a first, quick pass through the entire process
is immensely valuable but also rarely sufficient. We then repeat
the process more completely. Typically, the first pass shows
that a vital, large and significant software module has been
entirely overlooked by the staff providing the information to
Klebos. The results of the interim conclusions meeting are
invariably that this overlooked module now needs to be investigated
in depth.
It is not unknown that the result of step 3 is that there
is a fundamental mismatch between what the development team
have produced and what is required by the business, e.g. the
functions may be accurately constructed, but the architecture
is entirely wrong for the intended commercial deployment.
