Klebos in Cambridge: web-hosting for photographers, illustrators and small-businesses
   The Company | Product Portfolio | Consultancy Services | Business Model | Collaborations
Board & Management | Press Releases | Investor Relations | Contact | Career Opportunities

Software Asset Diligence:  
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?"
  • Maintain and suggest future options for an annual conference even management system combined with two overlapping international membership organisations home websites, both implemented in different versions of a PHP framework. These were hosted on a virtual server in another continent running a operating system so old that none of the current operating system management tools (such as yam) were compatible with it.
  • Examine a Windows-based web and PC application fast-food ordering system for a company expecting a take-over offer, where the chief programmer had "heard of" version conrol systems.
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:

  1. Meet the financial decision makers and discover the tactical options that need to be decided.
  2. Get as many parts of the software source code, database schemata and documentation as can be conveniently and quickly obtained.
  3. Discuss the objective of the software with the chief designer or substitute. This will involve technical discussions of the architecture.
  4. Determine how the objective partly matches the needs articulated by the financial decision makers, i.e. does it attempt to do the right thing?
  5. Assess how far the objective is realised in the software as it exists, i.e. does it work?
  6. Assess the software's scope for extension and modification (and maintenance). This involves some study of the historical and current software development process.
  7. 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.


focus - search - retrieve
Copyright © Klebos.com 2001 -