If you're buying in software, technology or tools, you should assess all the alternatives properly. Here's how
During a recent due diligence effort for the possible acquisition of a small tech company, the client specifically asked my team, "What are the key elements in a technical assessment of a vendor product?"
The goal was to analyse the organisation's technology infrastructure for the purpose of commenting on its products' current and future viability. The client also wanted to understand the feasibility of integrating the organisation's products with the current technical infrastructure.
There are many overt techniques that you can use to gather intelligence regarding an organisation's technical environment, including direct interviews, surveys and document research. My preference is to start with an organisational survey, followed by direct interviews and possible demonstrations proving capability.
The survey serves two purposes. It allows an organisation to submit an initial response to many of the elements listed below, thereby creating an initial understanding of each element. Then, you can use this information to help frame the direct interviews with organisational subject-matter experts for the purpose of gaining a deeper understanding.
Here's a list of some of the key elements you'll want to include in your survey:
- The business and technical organisation's mission, culture, and structure
- Key employees' identification, education, experience, and skills
- Current and past operational budget for: hardware and software maintenance, licences and fees, equipment rental, supplies, data and voice communications fees and contractors
- Current and past capital budget, depreciation schedules, short/long term needs
- Past, current, and planned projects
- The organisation's technical infrastructure, including hardware and software to support operations
- The organisation's development infrastructure, including hardware and software that supports product development
- Development architecture, tools, environments, standards, operating systems, development language(s), database(s)
- Software architecture methodologies, code reuse, modeled approach, OOD, application/data integration(s), services, stability, open systems, centralised vs. distributed
- Infrastructure/architecture scalability, reliability
- Database methodologies for confidentiality, integrity and availability
- Backup procedures, disaster recovery, data assurance, emergency procedures
- Development methodologies, processes and models
- Physical/network/application/other security, ownership, methodologies and processes
- Privacy, regulatory, legislative, industry issues and concerns
- Product portfolio, install portfolio
- Product capabilities
- Release management
- Documentation architecture, data, software, product, user manuals, papers, marketing brochures, etc. Business, technical and operational processes
- Help desk, issue management/tracking/reporting
- Staffing/management approach
You should analyse each area from the point of view of capability, maturity, completeness and appropriateness. When you complete the analysis, it will identify areas that you may deem weaknesses and others that you consider strengths for the organisation's continued success.
In my team's aforementioned assignment, we completed an exhaustive analysis of the organisation's software products, technical infrastructure, development processes and methodologies, human capital and other associated elements. Then, we summarised this analysis into a formal technical assessment, which I presented to the client and the vendor. We also provided the client with a detailed risk assessment and a summary recommendation.
Once you present your client with all the facts, they can use this information to make serious business decisions regarding the value and future of the organisation and its products and services.
Scott Withrow has more than 20 years of IT experience, including IT management, Web development management and internal consulting application analysis.