Category 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

Keep – Buy – Steal or Build – The 4 mechanisms of software system replacement

Leave a comment

So your business has a software system or software project that needs some attention.

Maybe there is pressure or need to replace the software system  altogether.

The reasons for replacement or update can be varied. Maybe it’s scalability, security, usability, or features. It could even be due to maintenance issues or a business need to change the architecture.

Whatever the reasons behind it, you have a decision to make about how to move a software system to a better place.

How do you decide what level of investment / work to do?

1. You can keep the software you have

Remodel or refactor the software

Refactoring is a way to make incremental changes or add iterative improvements to a body of software over time without replacing what you have.

Refactoring software is like repairing a boat as you sail across the lake. You make small changes so as to keep the boat afloat and not sink it.

By refactoring you keep the usage, benefits and revenue of the existing system but iteratively improve what you have. In most cases, it’s lower risk and can be less disruptive and lower cost.

An adroit team of developers can identify and iteratively improve an existing system surprisingly quickly. This mechanism can breathe new life into existing code in less time, with lower risk and a far more predictable schedule that the full replacement options listed below.

Depending on the level of need and the root issues this may be a viable option. However, you the situation warrants it, you may have to replace.

2. You have to replace the software you have

At one large company I was at years ago, our VP was known for responding to requests for software development resources for new projects with the following paraphrased response: “First we steal, then we buy, then we build”.

By his response, he was showing the truism regarding internal software development economics.

Reuse is cheaper than buying.

Buying is usually cheaper than building and maintaining.

If for business or functional or support reasons you have to completely replace what you have, there are essentially three options.

Steal

This is a metaphor for reusing software from another project or system within your company. It’s also called creative re-use.

If you have multiple projects or programs, one may have the software foundations already in place for what you need. Reusing or repurposing that can take less total effort and risk than standard replacement methods.

Buy

At this time in software development history, there are commercial options for almost every business need. It is worth it to look at your requirements and scan the existing universe of commercial software to see if there is an existing fit. This method can reduce time to market or reduce time to reap the benefits of having the system.

Build

Nothing exists that you can use for the need you have.  Or maybe what exists so prohibitively expensive or not a fit for your needs. If you don’t have anything laying around to reuse and you can’t use what is available on the 3rd party market, you must build it.

If you have to build it there are a lot of considerations to make.

  • Internal vs external team
  • Tech Stack to use
  • Specific external libraries or 3rd party services to use
  • Architecture
  • Development Environment
  • Deployment Environment
  • Non-Development Resources

If you decide to build the software internally also consider the ongoing maintenance costs after initial release that will be associated with hosting, updates, training, security patches, environment, and feature improvements.

So What

By considering all the available options a business has regarding software replacement, including re-factoring, an owner or sponsor improves the odds of the best decision for the company.

 

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.

Software Development, Technical Debt

Hey software developers 6 simple ways to help the developer that will clean up after your parade

2 Comments

I never write bad code. My code is always readable, perfectly modular, standard following, understandable, completely commented and idiomatic with 100% code coverage unit tests.

Ok. You can stop laughing now. Really, stop laughing.

As software folks, we will always bias that our code  easier to understand than that written by someone else.

Of course it is. You wrote it.

We get used to our own style, habits and ways of thinking about software implementation. It’s natural.

However, when it’s crunch time and the the deadline is now or our motivation is less than stellar, we have all written code, that, upon later reflection, is not much better than rotten barnyard material. Sometimes we write code that way during times of less stress and pressure too.

When you write code like that for a business, realize that someone will come after you. And the person who comes after you will have to fix bugs, add features, migrate to new environments and any other number of interactions with your code.

What will that person find?

If you want to pay it forward as a developer (and I am requesting you do), here are six simple ways to be kind to those who will work on your code after you are long gone.

0. Document block your files, classes, and methods

State your assumptions, purposes, reasons, pre-conditions, dependencies. Tell those coming after you what will help them understand not just what you did but why you did it.

Sometimes it can seem redundant (especially if your code is as good as mine) but a good doc block can clarify a class’ purpose or the reason a method is implemented the way it is. Plus a good doc block can be the high level overview that makes reading and understanding the actual code go much faster.

Doc blocks are a super help to the software archeologists that come after you and try to add features or refactor your code for some other reason.

1. Comment your code inline

Really? Are you kidding me?

I am astounded that with all the “software education” and common best practices we have access to, professional (?) developers still neglect to add relevant comments to their code.

I recently went through a file that was several thousand lines (yeah, I know) and there were no comments. We were trying to re-factor a bit of old code to perform correctly in PHP7. In a particularly obfuscated section of code I found myself asking “why did you do that?”, over and over again.

A simple line or 2 of comment in a method or variable definition can  prevent the person coming after looking at the commit log and cursing your name and yelling “What were you thinking?” And, if by chance, you happen to come after yourself a year or two later, a comment will help you remember why you set:

$Contibulator_Fudge_Factor_Ratio = 4.26;

2. Mind the coding style

You will annoy those who follow you by randomly changing coding styles. Tabs or Spaces? Braces on the line or under the line? Camel case or underscore separated names? Whatever you choose, do it the same way.

Consistency means those after you only have to figure out something once. This is especially true if you are adding code to a system that you didn’t write either.

3. Maintain architectural intent

When you code, have consistency in your implementation. There are few things more disorienting than trying to figure out why a previous developer had 3 ways of doing things.

When you need to talk to the database, do it the same way each time.

If you are coding an MVC app, be consistent on your division of work. If you use a template in one view, use them in all your views. If you start with ‘thin’ controllers, keep it going.

If the data representation is JSON, use it consistently. Don’t throw in some XML here or there just to mix it up.

If you have a ‘js’ folder with your site javascript files, don’t all of a sudden start creating template files with 400 lines of embedded javascript (without a comment).

Finally, if, for some reason, you have to do something that is a deviation of the architectural direction – add a comment!!!! Tell us why.

Consistency in your implementation will also help speed any future re-factoring efforts that you or some other developer may be tasked with.

4. Communicate with variable names

Variable names like $x, ‘res’, ‘m1’, ‘ary’ and similar communicate nothing to a reader about intent or purpose. Outside of idiomatic usage, say, as a loop counter in a C language for loop (for i=0; i< 10; i++), these types of variable names scattered throughout a code base only serve to obscure and confuse.

If you have a display mode setting string variable don’t call it $dm. Call it $display_mode_setting. If you have a post count variable don’t call it ‘pc’. Call it ‘post_count’. If you have an array of customers that are expiring their trial usage call it $customers_with_trial_expiring_list[].

You get the idea.

Simply use the context of the variable usage to name it accordingly. Think about telling the developer after you something by virtue of the name of the variable. In this manner, any later developer who sees these can more immediately grasp its purpose.

5. Guide with commit comments

So you’re assigned a bug to correct a situation where a NULL file pointer is accessed causing an exception. You realize there were several commits to this file and check the previous commits against that code. You notice that there used to be a NULL check but it was removed in a commit 4 months ago by a developer who is no longer working at your company, and they didn’t put a comment in the commit. Now you are left wondering if that guy a compete moron or was there some other unknown reason the change was made. Maybe it was unintentional but maybe not. Without the comment you have no idea why. You simply soldier on wondering.

This situation can be improved with a simple commit comment.

Something like “Remove the NULL check here, the IO library group will handle it”.  This communicates a whole new level of information regarding the change. It gives you a clue on where else to investigate to make sure your solution is correct and complete and it only takes 15 seconds. Yeah it’s a bit contrived but it illustrates my point.

Good commit logs help those after you unravel the history of the code changes more effectively. Log those commits.

Conclusion

I know, these are coding 101 items. The sum total of time it takes to code this way is only slightly longer that without it. Even so, it is disappointing to see how often these simple actions are ignored.

And, as someone with the responsibility to maintain a fair amount of previously developed code, the lack of these 6 things makes me want to pull my hair out. I know you feel that way too.

I like the way Brandon Savage says it in his book “Mastering Object Oriented PHP“. He was admonished by a previous manager to:

“write code as though the developer coming after me would be a psychotic murderous maniac who had my address”

Humorous, yes. But it contains a great truth about helping those who come after you.

Let’s face it, without a Vulcan mind meld, it is impossible to be on the same wavelength as the original author of code you might be  working on. But with a small amount of effort you can lessen the frustration those who follow after you and even become a code hero in their eyes. And who knows, the frustration level you lessen may be your own.

 

 

 

 

 

 

General IT, Technical Debt

Why your small business IT is like a Johnny Cash song and what to do about it

Leave a comment

In 1976, Johnny Cash released a song called “One Piece at a time“. The song chronicles a GM assembly line worker who builds a Cadillac by taking one piece of a car home each day. Then one day, with enough accumulated parts, the car is put together. When asked what model the car is the reply in the song is:

“Well, It’s a ’49, ’50, ’51, ’52, ’53, ’54, ’55, ’56
’57, ’58’ 59′ automobile
It’s a ’60, ’61, ’62, ’63, ’64, ’65, ’66, ’67
’68, ’69, ’70 automobile.”

You may be wondering what does this have do to with IT and small business?

Well, a lot. Small businesses typically builds out their IT systems the same way as the assembly line worker in Johnny Cash’s song, one piece at a time.

A growing small business is on a treadmill of changing technical needs. The owner has to buy what’s needed when its absolutely necessary and usually can’t afford a gold-plated build out up front. This, after several years of growth and internal system iterations, results in an IT system that resembles the car in “One piece at a time”.

The small business ends up with a whole collection of equipment, software, web service subscriptions, printers, phones, cables that are not labeled, hard drives, switches, WiFi routers and all kinds of other techno-detritus. Some of which may be business critical and some of which no-one can remember why they bought it in the first place.

As the mass of the IT systems grows the resistance to change increases. Things are harder to find, troubleshoot and replace. And, mistakes are more likely.

So what do you do?

Inventory what you have

I can hear the collective groan. Yeah, if you have no idea what you have, you really don’t have much hope for what needs to be done. Get a list of what you have and what it’s function is. It is as simple as creating a spreadsheet or just folder (in a safe location) that details what you have and what it’s for.

Get rid of what you don’t need

Schedule a Friday afternoon with pizza and sodas and get the team to get rid of what you don’t need or no longer use. Recycle, turn it in to Staples or other outlets for responsible disposal of electronic scrap. If you haven’t used it in a year, chances are you won’t. You will reap the benefits of addition free space, better knowledge of what you do have, and the power of tidying up.

Label what you keep

Having cables, switches, servers and any other hardware you use labeled correctly is a big improvement. It will save you a lot of time (which is money). It helps with on-boarding, and when third parties come in for maintenance. Makes it quicker to locate items and helps with replacement planning or dealing with an outage.

Identify priorities for future replacement

Everything has a life. Old servers or user computers may need to be replaced. Network switches lose fans and develop port faults. Everything electronic will fail at some time. So decide what is the most important items of what you have left. Make a list and decide the plan for replacement. Put it on the calendar. Add it to the budget. Do a little at a time, be consistent.

Check and update your warranties

Warranties can be a big help in planning replacement. Some companies like Dell offer onsite replacement. It may be advantageous for your company to extend warranties on eligible equipment. If you can tolerate the replacement window the warranty offers, this can extend the life of your installed equipment.

 

These are just a few simple steps that help a small business deal with the fragmented environment that can emerge with years of growth. With small but consistent steps, a small business can improve their IT situation without massive, disruptive efforts.

 

Small Business Growth, Technical Debt, Workplace Automation

Five simple steps to approach workplace automation

Leave a comment

The impact of workplace automation can be dramatic. Small business owners can improve their bottom line, improve employee morale and increase competativeness by implementing automation projects.

The real question is how do you start?

Here are 5 steps to approach implementation of automation projects in your business.

1. Look for pain points

To find good candidates for automation in your business, look for the pain points in your business processes and systems. Look for bottlenecks, repetition, manual tasks, data that doesn’t flow or reports that are manual in nature. Analyze your systems, find those that don’t integrate, where data has to be re-entered. These pain points are opportunities to automate.

On one project we had employees manually re-entering shipping information because two systems didn’t communicate the data. We were able to spend a little software development time and automate the whole process saving hours each day and improving quality.

Ask the employees for their input. You will be surprised at the insight they have to where the candidates for automation are.

2. Start small

Rome wasn’t built in a day. Analyze your business and pick small, tactical implementations you can afford. Choose projects that give your organization easy wins to build implementation skill and momentum. Projects as simple as the automation of a simple excel report, or a web site plugin to eliminate redundant data entry are excellent candidates to start with.

As the organization improves their skill at automation projects you can plan to tackle future larger, more impactful situations.

3. Involve employees

Automation projects can worry employees. It can cause fear and doubt about their future. They need to know the plan beyond what they do now. They need to see the future purpose of their position and the types for work that they will migrate to.

No one likes change when it removes tasks they measure their value to the company with. Owners and project managers need to navigate automation implementations with open and consistent communication to re-assure employees.

When I  discuss automation changes with employees,  I  stress that we should be continually trying to elevate our tasks to the highest value possible. This means delegating menial, repetitive  automate-able tasks to the machines. Automating those tasks frees up the employee to provide  higher value to the business.

One additional way to help  employees is to  provide  strengths finders, how to fascinate or similar assessments.  Assessments like these help identify strengths and latent skills. This self-knowledge  can help motivate a transition to higher value proposition tasks and assignments that align with their profiles.

4. Iterate

Many types of automation changes, especially with software based processes, can be incrementally implemented. Iteration allows organizations to try, learn and improve their processes and systems in small engagements.

Incremental implementations lessen the  organization disruption and allow employees time to learn and adapt to new processes, tools and responsibilities. When the employees see the benefit of small iterations they are motivated to continue the automation improvements.

5. Track results

Keep track of the savings your organization gains from the changes you make. Calculate the ROI. Communicate the results to the employees. Discuss ways the process of automation can be improved. Feedback this newly gained information to the next interactions of improvements. This helps  gain momentum and provides input for future decisions.

Follow these five steps and your business efficiency can improve substantially over time.

 

General IT, Small Business Purchase, Technical Debt

9 key areas of technical due diligence for a small business purchase

Leave a comment

If you are considering the purchase of a small business, a key to evaluating the business, and its potential risk, is to understand the condition of its IT related systems and equipment.

As small businesses use more IT software, equipment and services it is more crucial than ever to thoroughly investigate the IT environment to help make a prudent decision and to help ensure a successful outcome.

The IT environment for a small business can be a competitive advantage or a complete disaster. The buyer needs to do appropriate discovery and due diligence to understand just what type of IT setup they are getting with a potential purchase.

Here are 9 areas of a small business IT setup that should be well understood as part of valuation and due diligence.

1. IT Vendors and 3rd Party suppliers

You need to know what vendors are providing what services in the IT arena. This could include things like cloud services such as salesforce.com, Hubspot, Mailchimp, Atlassian, Office360 or even Google apps or similar. Some software providers have yearly license fees that would also be included in this list. A well documented list of service providers, what service or package they provide, the department using the service  and the current rate/package and term of agreement will help you see what things are pending and what your expected spend will be each year.

2. Employee Computer Environment Inventory

Most employees of a business have some type of computer for their work. A good due diligence practice is to get an inventory of what types computers are used, what operating systems are used (like MAC or Windows) and what other programs are installed in this environment. Are the computers leased our purchased? When does the lease expire? How old are the employee office computers? Will they have to be replaced soon? Are they reliable and have been maintained? Are they sized appropriate to the work being done? Are basic safeguards such as virus scanning and operating system updates in place? These are all questions that need to be answered to get a better idea regarding what you may have to invest  (or discount on sale price).

3. Internal Computer Servers and network setup

What internal computer servers does the company use, if any? Who maintains them? How old are they and what applications and operating systems do they use? Where are they located and what type of environment are they in? Does the company run windows servers or MACs? Are there other servers running internal software like accounting programs, databases, legacy applications or other types of software?

You will need to have a network diagram and understand how the office computers network together. Are there network switches or routers used? Are there multiple locations that share network capability? What about internet firewalls and wireless access? What are the security procedures regarding access to these machines and resources? All of these are required discussion points in order to make an informed purchase decision.

4. Office Equipment

Things like printers, copiers/scanners and phone systems, though seemingly old school, are still used in most offices. Your due diligence needs to investigate these items as well. Many times copiers/printers are leased from a third party and lease transfer or termination may need to be arranged depending on what you do with them after the purchase. Additionally many copiers also have document scanning capability which could be integrated with the server computers. This dependency would need to be understood and planned for if change is warranted.  Similarly regarding phones. Is the a local PBX or is the system hosted? What type of plan does the phone provider agreement specify? Is the phone system  integrated with a Customer Relationship Management systems to track calls? What about off-premises call answer and follow-me forwarding?  If the acquirer wants to terminate these and roll the use to their existing systems there may be early termination fees that need to be accounted for.

5. Employee BYOD Policies

BYOD is an acronym that stands for Bring Your Own Device. It is a practice where employees can use their personal electronic devices like mobile phones or tablets to access company resources like wireless networks, email, shared databases and other company services and software applications. You will need to understand current company practice regarding BYOD and what risks this brings to the transaction. A liberal BYOD policy could allow employees to have copies of databases and other proprietary information on their devices. The extent of this, and potential impact to the acquirers polices needs to be clearly understood.

6. System Administration Practices

Every IT system has a special administrative account and password. And usually each cloud software service you subscribe to has special account owners and passwords. You need to understand who manages these, how they are secured and how they are changed and monitored. In transition planning, this account information would need to be documented, validated and all transferred to the new new owner. Password updates would then need to be made in accordance with new guidelines. Also, you need to understand how company data is backed up. Where is it stored? Is it off-site? How are restore requests handled? How and who sets up new user accounts? There are many areas of investigation that need to be reviewed in this area to insure a smooth transition.

7. Email and Web Site

In some cases small businesses host their email and web services together. Companies such as 1&1, GoDaddy and others provide packages bundling these services together. You will need to investigate where email (and spam filtering and virus scanning) are done as well as web hosting. Other companies use email hosting providers like outlook.com or google gmail. The setup and documentation of where these critical services are hosted, how they are maintained and who handles the work is critical. Email and website are key links in the chain of customer interaction and must be thoroughly reviewed and the migration to the acquirer accounted for.

8. Point of Sale, Payment Processing and eCommerce

If the business is retail or has online shopping capability  you will also need to understand what systems are in place for these capabilities. Are they on-premise, hosted or leased? What systems and communications capabilities are needed? What providers are used for payment processing and how are they integrated into the customer sales cycle? Does the system use tables driven sales tax, or an online tax nexus service like Avalara? Are credit card numbers or other personally identifiable information stored anywhere and if so what are the security procedures and practices regarding that data? How are the services configured to operate, including API keys, passwords and other key operational parameters? These are absolutely crucial to the new owner to understand and have accurately and thoroughly documented.

9. Custom or Proprietary Software

If the business uses custom programming or has proprietary software applications you need to know more about it. What does it do? Who maintains it, where it is located, how is it managed and updated? What languages, tools or environments are required to use it? Are there large updates planned or needed? Are there security risks? These are just a few of a number of questions that need to be answered regarding customer software. If the business has employees that develop and maintain the software then additional questions regarding the development environment, source code control, testing and release management need to be investigated and understood as well. The answers to these questions will help you understand pending needed investment, risk and potential additional opportunities for synergy and integration gains.

 

These are some of the standard areas of technical due diligence when investigating a potential small business purchase. An appropriate technical due diligence checklist and process can reveal technical debt which will impact the decision making and negotiation process.

Depending on the type of business there may be many other areas to consider. High tech businesses, manufacturing and other types of businesses requiring specialty equipment or software applications will also need additional due diligence in other areas besides those mentioned. Further, mid market businesses due to their size and additional complexity will also require much more effort to fully investigate and understand all aspect of the IT related impact to the transaction.

If you are unsure of these areas it is best to enlist the services of an IT professional to help with a technical assessment. In this way you can get a 3rd party opinion on these areas.

Improving your knowledge in this key area can give you leverage in price and terms negotiation as well as making you better informed of areas that may need to be addressed post sale. And the knowledge can save you lots of headaches later after the purchase.

General IT, Technical Debt

3 Ways Small Businesses Can Begin to Eliminate Technical Debt

Leave a comment

We all see the update reminders. We know they are one sign of technical debt.

Microsoft has updates for Windows or Word.

Apple has updates for OSx.

Our mobile phones show those little indicators telling us how many apps need to be updated.

Your business may have servers that need replacing and software that needs refactoring. You may have  entire systems that need to be replaced due to end of like for functionality issues.

How do you get to all of that and still do the new work?

Here are three methods that, I have found that can help eliminate some of the burden.

Method 1: Schedule regular time  for the easy updates

For simple updates, like app updates, browser updates and vetted updates say from Apple or Microsoft  I recommend scheduling time each week to spend a few minuets applying the updates. Make it part of your routine. This makes it such that it usually only takes a few minutes and the changes between versions in the updates are minor. Some phones and tables allow for auto app update. So that can be a help as well. For me, I do this each Monday morning. I apply any security patches that windows says are needed. I also update browsers and key apps I use on my computers and phones.  Because I do this every week, it usually only takes a few minutes. So while my updates are applying  I can get a cup of coffee and then I am usually ready to roll.

Note: For real migrations, like moving from Windows 8.1 to Windows 10 on your laptop, or from Yosemite to El Capitan on your Macbook, you will need more time. I usually do these on weekends or on days when I have a lot more time available for my devices to be down.

Method 2: Migrate to hosted versions of server apps you run in-house

If you have your own hardware servers that run your accounting application or exchange server or other key software for your business check into moving those to the cloud. Many software vendors such as Quicken, Microsoft and others  who sell installable software are now also offering cloud versions of the same applications. By migrating to cloud versions you lose the headache, cost, space and risk of having to deal with hardware in your location or co-location facility. And you can usually benefit from the cloud versions of software being updated very regularly and always having the most recent security patches. This method can take a decent amount of effort depending on the system but there is a nice long term payoff.

Method 2a: If you have physical servers running that you cannot migrate to the cloud, consider extending warranties on them.

Many vendors like Dell or HP will extend onsite-parts replacement warranties for not too much money. Of course this assumes that your situation can be without a server for a day while you wait on the tech to arrive and make the repairs. Note: If you sign up for these with a vendor, make sure they have parts they keep in stock for your server or computer model. We had a warrantied system at one job I had where they didn’t immediately know if they had a replacement for our model when we needed it. If your server has been classified as “end of life” then you won’t be able to get extended warranty and you will have to migrate to other hardware if you want support.

Method 3: Initiate off-site automated backups of your data

One insidious form of technical debt is in-adequate system backups. Losing company data can be catastrophic for a small business. Luckily, there are many services that offer automated and secure file backup for your business servers and user devices such as laptops, desktops and even phones and tablets that are affordable and easy to use. Services such as Crashplan,  Carbonite, and if you are an Apple user, there is iCloud. There are plenty of others as well. Most of these services offer client programs that you install and run that will automatically backup and encrypt your files and store them securely in the cloud.  That way, if something happens locally you can recover your data usually via a pretty easy to use web site that allows you to login and select the files you need to restore. The prices for these services have come down tremendously in the last couple of years.  If you are not doing offsite backup  these services make it pretty painless to get started.

Technical debt can affect your company in many ways. These methods offer ways to begin to take small steps to alleviate some of that debt.

 

Technical Debt

Signs your business has technical debt

Leave a comment

You might be thinking I don’t have any technical debt. Oh yeah? see if any of the signs below apply to you.

Signs of technical debt

Your corporate PC’s are running Windows XP.

You or your employees are still running Internet Explorer.

You are hosting a web site on an ancient version of WordPress.

You are updating your web pages with Front Page.

Your office computers use Office 2003.

You keep clicking “Remind me later” to the prompt to install your software updates.

If your software development team dreads touching one of your legacy products for fear that fixing one bug is introducing others, then you have technical debt.

Is the key web site app you use is based on a framework that stopped being developed and maintained 7 years ago?

Do you maintain systems that use libraries or other tools that were discontinued long ago?

Are you still making use of that open source project that the maintainer closed down 5 years ago?

Do you have unapplied patches, security updates, or  incomplete backups?

What about the server that has been running for 5 years you have been meaning to upgrade? Somehow you can’t seem to find the time to schedule the downtime and migration of the systems that is serves.

Are you still running the Snow Leopard on your MacBook?

Yep, all of these examples are technical debt.

But wait, there’s more.

What about your procedure and processes regarding your IT systems?

Is your documentation behind?

Business continuity plans and disaster recovery?

Customer data protection?

That too is all technical debt.

Does your website still say “Best if viewed with Netscape”? Oh man thats technical debt.

There are so many more.

No business not matter how large or small is immune from the problem of technical debt.

Step 1 of any 12 step program is admitting you have a problem  and if you have these signs in your business then you are a victim of technical debt. Maybe is it not causing you great pain now. But at some point it will.

The question is what do you do about it?