nomadic_audio: technical due diligence (part 4)

in my last post I went through the infrastructure and architecture aspects of the technical due diligence process, so in today’s post I’ll be finishing off this four part post with the final areas I focus on, the workflow and governance processes that the intended company might utilize. Again, I like to go back to my favorite conversation starter “take me through concept to production” as a way to dig into the details of how the intended company gets work done. Some of these processes are completely foreign to startup technology teams but again that’s ok, its useful to hear the reactions to these areas if they aren’t in practice and if they are utilized even better. I do not expect startups to have well defined workflow process but I do like to understand how the other cto envisions workflow and effects prioritized change which is always one of the most important things a technology team will need to undertake as they scale their environment and augment product functionality. For workflow I like to start with an understanding of how project management is handled as well as how the approval process and task allocation works. Most startups do not have dedicated pm’s so understanding how those who wear multiple hats handle insuring that proper process is followed to insure tasks are managed and prioritized correctly and that estimates of time to complete are as accurate as possible is critical. Many times I’ve heard “we don’t have time to do project management, we just like to get stuff done” so much so that I’ve gotten pretty good at not laughing anymore. Being able to explain to me how getting things done in an organized fashion is usually a good place to start, sometimes the team is actually using pm practices they just aren’t doing it in a formalized fashion, which is fine and again just going through the conversation is very useful in assessing how things get done and if the process is grounded and sustainable. Next I get into even more formal areas of workflow, how are the business requirements of new initiatives or projects documented and signed off on, which for startups is often driven by founders or senior management and rarely formalized but its important to understand what happens and who drives it. I like to see proactive approaches in this area that tie into some form of a roadmap that can be well understood by the technology team.

Most companies I analyse are web delivered software related but everything I ask related to development could apply to hardware or service related companies as well. For software development workflow, I pretty much like to go through every aspect of how work gets done starting w/ what formalized process (if any) is utilized, how new functionality is added and how change control is effected so that risk is minimized when anything new is introduced. This is where bug fix management is touched on as well. In today’s online world, how rich media, graphics and general user interface is handled is critical so i ask to go through this as well. If the company relies heavily on a database, and it wasn’t covered in the architecture discussion, which is the right place to go through it, then I make sure to dig deeper at this point. I don’t like to get into say the table design level, but rather just as w/ any layered approach to web application developments understand what’s being used, why and how is it managed. Next is an often-overlooked aspect of the startup development process, quality assurance. How is anything introduced into the environment tested and assurance provided that whatever it is functions as intended and does not break anything when introduced. Some startups utilize their own developers to perform this qa function, which is a very bad practice but if staff or funds are limited it might be the best that can be done. If this is the case I like to at least see some method to insure proper unbiased and thorough testing has occurred. Next is the always telling build vs buy conversation, which is one of the most important philosophical parts of the due diligence process. I believe that in today’s technology environment, commodity mundane technologies are readily available and as such most basic functions such as network, hosting, storage, advertising services, credit card transactions, site monitoring etc… can be outsourced to specialists at a very low cost compared to building these functions in-house. What can then be focused on by the development team is building the core product that will used to go to market, that which differentiates the company from its competitors. I know this sounds overly simplified but I tend to see a wide variety of product offerings so I need to keep things pretty generic, and that’s why the conversation that is generated by this process is the real goal and not just static answers to a list of questions. Finally, as mentioned before the roadmap for the company and how the cto envisions proceeding towards meeting it needs to be covered. This is usually an overview of what the funding will be used against and where the company wants to go w/in the next year or two depending on their maturity. I also like to cover how research is accomplished along w/ the roadmap since they are so closely aligned. This includes competitive landscape & potential beneficial acquisition topics. I like to get into infrastructure management practices at this point unless its been covered earlier in the conversation, just to make sure the workflow aspect of it is understood. Same w/ how integration and partnerships are dealt w/ and then I always offer up whether there are any other topics to allow the cto to cover anything I’ve missed but that they think is an important part of their value add. I usually incorporate whatever it is they bring up into my process for future due diligence if I think its generic enough. That way my process matures as I evaluate more and more companies, to date my guess is I’ve probably done this over 500 times in my career, but I always tend to learn something new as I go through it w/ thoughtful cto’s.

The final area of focus that primarily relates to acquisitions is a complete picture of all technology related costs. I ask for this for the previous 3 years (or since the company started), current year and an estimate of cost expectations to meet roadmap goals. This needs to include both capital and expense related costs, including amortization assumptions, buy vs lease philosophy and a complete overview of their governance process. How are budget and cost assumptions created, how are they prioritized and what is the process utilized to get approval. Along with all of this I ask for all technology related contracts, to include what they’re used for, how it relates to deliverable of the company, duration and statement of relationship, for example whether it’s a strategic or commodity relationship.

I end by asking for the names and contact info of all subject matter experts involved in case further explanation or follow-up is needed.

Here are my workflow and governance sections of the outline that i tend to follow:

3. Workflows & Processes

3.1. Please describe your product/project workflow (or provide diagrams). For example, how are the following capabilities or functions handled:

3.1.1. Project management & approvals

3.1.2. Business requirements documents

3.1.3. Software development & enhancements

3.1.3.1. New features & functionality

3.1.3.2. Change mgmt & bug fix

3.1.3.3. Graphics & UI design

3.1.3.4. Database overview (unless handled section 2)

3.1.3.5. Testing & Quality Assurance

3.1.3.6. Build vs buy decision making

3.1.3.7. Roadmap and Research

3.1.4. Infrastructure Management
3.1.4.1. Monitoring & alerting

3.1.4.2. Upgrades
3.1.5. Integration & Partnerships

3.1.6. List any others specific to your offering

4. Expense & Capital budgets with depreciation for previous 3 full years and anticipated for current year

4.1. Provide an overview of Technology Plan, as implemented to-date

4.2. Provide an overview of Technology Roadmap, especially any major initiatives outstanding or desired

4.3. Describe how Technology initiative priorities and funding decisions occur (state your governance process)

5. List of all 3rd party contracts with all relevant terms, including:

5.1. Data center contracts

5.2. Hardware and software maintenance contracts

5.3. ASPs & outsourced services

5.4. Software licensing agreements

5.5. Outside software development

5.6. Any other technology services under contract

6. Please provide contact information of responder in case follow-up is needed

so that’s my technical due diligence process; most of what i've covered would be applicable to an investment but some of the more detailed areas would only apply to an acquistion or merger. as i’ve stated throughout these posts, i try to keep it conversational and generic enough in nature to handle a wide variety of company types and scenarios, going into depth via additional questioning as needed.

anything you think i missed in these posts? Feel free to contact me if you have any suggestions or questions, be glad to address them…