Technology Due Diligence

I have been thinking for the last 2 weeks about the idea of open-sourcing the due-diligence process, and wondering
- If VC get a unique advange based on the unique (secret) features of they own due-diligence process
- If the Due-Diligence process can be improve though blog-based group thinking

I think it's usefull to have transparent, open-sourced due-diligence processes so that
- CEO understand the VC perspective and be prepared for the VC process
- CEO can use the same process when performing a M&A due-diligence

Any feedback / comment (so we can improve it...) is welcome on this description of our high-level Technology due-diligence process:

Investment executive will meet a company before a complete technical screening has been performed, and will perform a high level technology assessment. This assessment will always be followed by a more thorough technical due diligence.

The focus of the technology questions should be the following one:
• If the investment is focused on technology: does the technology work, support the business model, have unique defendable value, have the ability to create a platform, and is development/engineering managed effectively?
• If the investment is focus on business: does the technology work, and is it produced in a controlled, predictable, managed way (inside or outside the company)?

The Ten Qs
1. Demonstration (can it work)
• Go through a demonstration of the product, does it work?
• Can you clearly identify the potential users ?
• Can you link the features of the demonstration with the business model?
• Get an explanation of the use case (usage scenario) first, and then try and relate to it.

2. Context (what environment does the system assumes)
• What hardware, connectivity, software & services to perform the demonstration?
• In the case of web-based applications, what kind of component downloads are required ?

3. Trends (what technology trends does the system ride?)
• What key technology trends does the systems leverage (Java or Microsoft camp) ?
• In the case of multiple vendors providing the same technology, does the product work across vendors (e.g. Internet Explorer and Netscape, or BEA WebLogic and IBM WebSphere)?

4. Innovation (what is new from a technology perspective)
• If this is a technology play, what is new?
• Who does it compete against or complement?
• Which existing standards does it follow/leverage?
• What new standards does it try to define?
• What kind of API will be published (to whom, when, get a copy of any documentation that exists today) ?
• Which languages will be supported by the interface (Java, C++, XML,…) ?

5. Defendability (what is defendable from a technology perspective?)
• If this a technology-play, what is legally protected? If patents have not been granted yet, ask for a copy of any patent application.
• If no patent applications have been filed, have they searched for potential patent breach?

6. Architecture (is it explicit and documented):
• Can the company share with you an architecture description of the product (solution), for example in the form of a White Paper?
• Have them describe the main elements of the architecture, and which standards it adheres to (J2EE, .Net, standard 3-tier,…).

7. COTS (is it build on existing technology)
• What commercially available off the self technology or product are used inside the system, or within the company development group?
• Have any bespoke developments being implemented by COTS vendors, and if yes, who supports them?
• What is the licensing model being used for COTS components? Is there a revenue share element?
• Try and assess the relative value of the COTS components vs. the offering of the company, assess whether it is simply a re-packaging targeted towards a specific vertical.

8. Performance (how well does the development team meet objectives)
• What is the track record of the development team in meeting release dates and content?
• How much challenge does the current plan pose for them? What is their comfort factor and the planned margin for the current release.
• Is speed and TTM the main driver of the technology group? Or is it functional completeness and quality?
• Does each team member have well defined goals? Are those goals enforced by the organisation through a thorough project management process? Ask for a copy of Pert and Gantt charts.

9. Development Process (how does this organisation develop software)
• If the development team is internal: understand the size, and various roles inside the group, what process is used for developing the software?
• Are all team members aware of process guidelines? Does the organisation enforce compliance with its process? Is efficiency measured and rewarded as one of the key drivers of success?
• Does the organization have a systematic approach to process, through a dedicated team or function? Is quality measured and rewarded as one of the key drivers of success? Ask for the quality plan, and any quality-related metrics.
• If the development team is external: what SLAs and contracts have been defined with the external R&D group? Get reference of similar systems developed by the external group.

10. Portfolio (does it compete and are there synergies?)
• Does the company compete with any existing technology offering of any portfolio company? If this is the case, could this technology be considered second generation compared to the investment we have?
• Can we leverage other portfolio investment within the new investment? Can this company leverage existing portfolio technology or services?
• If the company is already working with someone in the portfolio get all available details.

Comments

[Stephane]

Just two comments for the "Demonstration" part :

How they evaluate the “Number of potential users” (often, this criteria should be an efficient way to detect fuzzy project (based on my recent return of experience ... three last company I’ve met with non realistic figures and finally non well established concept/ system)
How fast are they able to switch from demo perspective to proof of concept implementation ? (if relevant / Allow to figure out how they make it work in the real world...) In that case, what i call “proof of concept” is a basic integration of the product in the ecosystem. (I've some examples in case you disagree)

[Chris Powell]

WRT Demonstrations: You can fool (nearly) all of the (non-specialist) people (nearly) all of the time.

WRT Innovation: "...languages will be supported by the interface (Java, C++..."? The point behind interfaces is that they hide the implementation. Unless you are referring to APIs and even then, most can be called from other languages.

WRT Architecture: Standards are what you make them. Is my system adhering to J2EE, J2SE or J2ME? In some cases, adhering to a standard can hit performance/innovation. Are my practises ISO900x/CMM Level x compliant? Unless you have an in-depth, independent check, how would you know? I've interviewed software candidates from CMM Level 5 companies who had no clue whatsoever about good development practise. That standard was just a name.

WRT Development process: Software metrics are one of the most misused, badly understood and poorly utilised measurement techniques ever. How is quality of software measured? Number of outstanding bugs? But what's a bug? Is it a bug, or is it a required 'late feature'?. Are we talking bugs/line, bugs/method, bugs/component, bugs/package, user expectations, conformance to (a moving) spec.? What level of bug? One man's serious bug is another's trivial bug. Perhaps it's ease of use (who measures this)? Performance? Functionality? Portability (which might affect performance)? There's coding styles, documentation, uninyended (internal) dependencies etc.etc.etc... I measure many, many factors in determining the quality of a piece of software ending up with a multi-dimensional set of figures from which decision makers will make a move (or not). And then I add in development processes (which can be fixed) and other peripheral observations which might affect development (eg: how often are developers interrupted to fix the bosses' email or whatever?).

[Gregg Davey]

I’ve seen a lot companies miss their projected synergies over the years because they didn’t properly conduct IT due diligence or factor in the critical role technology has on post merger business consolidations. Generally speaking, you can’t consolidate a business until without first integrating the technology, and thus any assumptions made around time lines to integrate the business that aren’t taking technology integration into account are simply pure speculation.

A good resource for IT Due Diligence: http://www.beaconintegration.com/resources/merger-blog/category/due-diligence