Tag Archives: Technical Debt

General IT, Small Business Purchase, Technical Debt

5 Simple Ways to Boost Technology Value Before Sale

Leave a comment

This article first published at the Axial Forum here: 5 Simple Ways to Boost Technology Value Before Sale and is reposted here with permission.

During M&A, seemingly small technology concerns can have material impacts on the ultimate valuation of your business. When selling your business, how can you improve your technology’s value and speed up the due diligence process?

Here are 5 simple tips.

(Note that these tips don’t address more significant technology issues like embedded technical debt, un-found software defects, or key security risks. Those types of issues need to be discussed and evaluated separately.)

1. Clean the garage

Ask any realtor: a clean and orderly house is easier to sell and will do so at a higher price than one that is disorganized or in disrepair.

Every company accumulates old technology that is no longer needed or used. Clean it up. Take a Friday, buy pizza and sodas for the technology teams, and have a spruce up day.

Sell or dispose of old printers, laptops, phones, computers, or servers that are no longer being used. Get rid of the accumulated boxes, old manuals, broken mice, computer monitors that only show green, and outdated cables and connectors.

Eliminate everything but what you know you have definite need and direct use for. Resist, with great aggression, the notion that “this may have value someday.” It won’t, especially not for your business’ new owners.

2. Take inventory of the technical assets

Know what you have and what the new owner will be taking over. You should already have an inventory of your technical assets, but if you don’t, create one now. This can be as simple as a Word or Google Doc, or an Excel spreadsheet that lists servers, software systems, infrastructure elements, employee devices, etc.

The inventory list also needs to show the purpose of the asset. If the server called “acmeacct” is the host server for the corporate accounting database then say that. If you have a Cisco router that interfaces with the WAN circuit to the remote office in Columbus, OH, then put that as the purpose. I recommend having hardware and key software systems listed on the inventory sheet.

An up-to-date inventory list will speed the work of the technical due diligence and improve the perception of the acquiring team.

3. Draw pictures

They say a picture is worth a thousand words. If you don’t already have them, create a few high-level drawings of the overall technical layout and architecture of the technology in the business. Those drawings will communicate, far better than any other medium, the technical relationships and dependencies for your acquiring team. Include the names of the assets, physical locations, and other pertinent high-level details on the drawings. Be sure and use the same names on your drawings as you do in your inventory lists.

The drawings don’t have to be professional CAD drawings. Simple PowerPoint block diagrams or even hand drawn pictures, as long as they are legible and accurate, will suffice for most businesses.

4. Police your policies

The state of your technology policies and procedures will communicate volumes about your operational condition to the acquiring team. Clearly written, accessible, and organized policies increase compliance and will improve the buyer’s perception of the value and capability of your organization. Password and security policies, backup policies, and software deployment procedures should all be documented. Especially if your business engages in regular credit transactions, the lack of security will increase perceived risk in the minds of the acquiring M&A team.

Before due diligence starts, review and update any policies or procedures that are out of date. Document missing procedures and communicate them to the organization.

Organize the policies and procedures and title them appropriately in a common place – this could be a shared folder on a company server, a list of Google documents, or a defined location on the corporate intranet. Every employee should know where these live and how they are accessed.

5. Rectify the roles and responsibilities

Acquirers will view your company’s employee base as a key asset during M&A. Certainly any good HR department will have a list of employees and job titles. But that list does not communicate responsibility or system expertise from a technical perspective.

The technology teams should have their own roles and responsibilities list that communicates what each team member is responsible for and expert in. When possible, the list should include the names of systems used in the other documents to facilitate better overall understanding by the acquiring entity.

Development, Software Development, Technical Debt

4 ways every business is increasing technical debt and how to change that

Leave a comment

We all like to think what we do helps move our business and products forward.

But………

Sometimes subtle, embedded habits and tendencies we have actually increase the rate at which a business accumulates technical dead. Which of these does your business have?

Short Sighted Executive Decisions

You have been in those meetings.

You know the meeting, where the executive in charge slams their hand on the table to get everyone’s attention after an extended debate.

And then, with red face of anger and the decibel level of a 747 on takeoff, bellows “this product will ship on time“. 

This display is usually accompanied by promises of some sort of employee  retribution if the fantasy date is not met. It is at that point the meeting is really over and no one will dare raise any additional points no matter how real and urgent they are. 

Using emotional outbursts to attempt to motivate a team doesn’t create technical debt per se. However, it is the short-sighted executive decision making that results in this environment will create technical debt.

There may be valid reasons why the product can ship on time. However, there may be serious issues, just under the surface, that could cause the company big problems if the ship date is met.

Astute executives ask penetrating questions, validate assumptions and create productive dialog. Click To Tweet

Astute executives ask penetrating questions, validate assumptions and force the analysis and discussion that create productive dialog. It is only in an environment where subordinates and colleagues feel safe in disagreeing or bringing bad news that all issues can be on the table and then dealt with appropriately. Otherwise, things that could be real issues get covered up, hidden, or ignored. And when issues and technical debt builds, are you can rest assured they will pop up later at the most inconvenient time.

Management Short Cuts

Typically managers take short cuts that build in technical debt for two reasons: 1)because they are incompetent or 2)because they are trying to make points with the boss by finishing earlier, cheaper etc.

Incompetent managers yield all kinds of pernicious evil in software or IT implementations. They can hire the wrong employees, force inadequate or inappropriate implementations, misunderstand technical requirements, force the use of the wrong tools or rewarding the wrong behaviors. The results of these managers will always cost more, take longer, disappoint, and need large corrective actions.

The brownie points gang are those managers that always want to have the right answer.

“Yes we are on schedule”

“The project is coming in under budget”

“Yes we can add those all those new features” 

“No, that change won’t affect our delivery capability”

Looking good is more important than reality and truth. These types of managers are skilled at making themselves look good and figuring out some other person, group or division to take the fall when things hit the fan.

Adroit managers work to always increase their competence through training, assignments, asking questions, checking assumptions and working closely with their teams. They understand that by continual growth and disciplined execution they will impress their bosses and it will be real.

Developer  Laziness

I was recently working on some software and came across a whole section of code that had been copied identically and only a couple of  lines changed to accommodate the different situation. This is a perfect example of developer laziness. Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place,

This is a perfect example of developer laziness.

Instead of taking the extra mental effort and time to create a method to do the work so that it was encapsulated in one place, technical debt was created by copying a bunch of code unnecessarily. It may have allowed the developer to quickly get work committed but built in a headache for someone else to deal with later.

Skilled developers understand when small refactoring can save huge time later. Click To Tweet

Skilled developers understand when small refactoring can save huge time later. They know when it is worth it to make additional small investments to avoid bigger problems later.  Invest in resources to train developers on your systems, standard coding best practices, and effective coding refactoring processes.

Team capability

What’s your team training plan look like?

Do you cross train?

Are you encouraging them to learn better methods of coding or testing or implementation?

Are you giving them tools to improve code, deployments, or testing?

Is continual learning part of your culture?

If you don’t have answers for these questions for your team or yourself then you could be inadvertently building technical debt in future implementation.

The technology software and IT is advancing at an ever increasing pace.  Your organization has to adopt an adaptive, learning mindset to stay up with advancements. And incorporate them to give your business advantage.

Improving teams create and execute training plans for the tech they are involved with. They set expectations for learning, growing and utilizing what they learn to improve products, productivity, and performance.

 

General IT, Technical Debt, Uncategorized

7 Areas of Hidden Technical Debt That Increase M&A Costs

2 Comments

This article first published at the Axial Forum here: 7 Areas of Hidden Technical Debt That Increase M&A Costs and is reposted here with permission.

Effective buy-side deal teams are well-versed at issues during due diligence that might impact a deal. But even the most astute deal teams can miss te­­chnical and IT aspects of the target company that can significantly impact the cost of the integration and the return on the investment.

Here are seven often overlooked areas of potential hidden technical debt that acquirers should investigate prior to close.

Employee Devices

Desktops, laptops, mobile phones, and tablets are the tools of the modern office worker. In most businesses each employee has at least one of these and in many cases 2 or 3.

The acquiring business will assume responsibility for the condition and upgrade/replacement policies for these devices. Even in a small company acquisition, there can be hundreds of devices to track, maintain, update, replace, or discontinue. A well-run business should have an inventory of employee devices.

During due diligence use this inventory to determine if excessive technical debt exists in the device fleet. If the business does not have a device inventory, further due diligence investigation will be needed to determine hidden costs.

Backend Server Hardware

Most businesses still use physical servers. These could exist in a rented data center or be stacked up in the closet down the hall.

As an acquirer, you need an accurate list of these assets and the purpose they serve. The actual server hardware needs to be checked for age, serviceability life, warranty, general condition and need. A server upgrade can be a non-trivial task, especially on a mission critical application. Factor in the costs of migration, updates, and maintenance of these physical assets in due diligence planning.

Server Operating System Patches and updates

In addition to physical hardware inventory, the operating systems of the servers need to be checked. Operating system vendors like Microsoft, Apple, or Linux issue updates to correct software defects and security vulnerabilities. It is up to the system administrators to keep up with the installation of patches and updates. Systems that have not been patched are more vulnerable to penetration and disruption.

Spend time during due diligence inventorying the operating systems’ patch level and the security vulnerabilities of the servers. Then plan for additional time and effort post-integration to mitigate.

Unsupported/Obsolete Software Applications

Some businesses rely on older software applications, sometimes custom-built. Old or obsolete software is a significant cost factor when planning mergers of technical assets.

During due diligence, inventory all software in use by the business. Licenses, support contracts, warranties, and necessary upgrades also should be documented. Software applications that are no longer supported by the vendor or creator need to be factored into the cost of the merger. Knowing the landscape of the business software and planning for changes during due diligence can save significant amounts of time and money during the execution phase.

Paper Dependent Processes

Many businesses still use paper. Make sure you understand which processes are dependent on paper, how its stored, whether it needs to be converted to electronic format and the like.

Paper can generate storage, security, and accessibility issues for the acquiring business.

Integrating paper processes with electronic processes of the acquiring business can add time, expense, and potential errors, as well as require additional equipment. Investigate this liability up front to appropriately plan for it during integration.

Duplication of Data

Almost all businesses have databases to hold corporate, product, or customer data. Careful examination of the database architecture yields important facts regarding duplicate data that will impact future integrations.  Duplicate data leads to misreporting, inefficiencies, and security risks. It’s not a deal-killer but does need to be examined and understood to determine its ongoing need, security risk, and cost impact to the merger.

Custom Software

Custom software can be a competitive advantage, and help make a target attractive. However, custom software can also hide all kinds of scary things. On the outside things may look shiny and new, but on the inside there may be loads of technical debt.

During due diligence, consider the software’s architecture, dependencies, and implementation. Look at the quality of the code and what tools and languages were used. All these factors impact the cost of the business and its ability to grow and integrate in the future.