4 common mistakes in rolling out purchased business software

If your job is to make software, and you're not living under a rock, you've probably heard dozens of stories of software projects that never made it to market because of uncontrolled scope creep, poor software quality, blown budgets, and the list goes on. In theory, purchased software should be safer, but I've witnessed more failures of rolling out purchased software than I have of custom software, despite the fact that I've been involved in roughly the same percentage of each type of project. What can go wrong? Here are four problems I have either witnessed or was brought in to fix.

Solving all problems at once

When companies first get their hands on new software, their instinct is to try to solve all of their problems at once. They'll jump head first into the new system but get lost in all of the possibilities of how to use it. After taking much longer to start than expected, they'll discover that their elaborate designs are invalid because of some basic understandings of how the system works. Instead, companies should focus on starting slow and simple, building on successes and learning from failures.

One time I saw this first hand was at a company that wished to use Team Foundation Server (TFS) from Microsoft as its project/work tracking software. In most companies, this would not be a big deal. This one, though, was going to try to customize TFS so that it could replace two custom-built work tracking software systems, custom-built time tracking software, and dozens of spreadsheets. When the company tried to tackle everything at once, they got overwhelmed with all of the problems that come with such an overhaul. After we reduced the scope for phase 1, the project started moving more quickly for the organization and allowed us to make continuous progress towards fixing all of the problems.

Choosing the wrong place to start

When companies purchase software to solve multiple problems, they typically jump in trying to solve the wrong problem. They'll either try to solve the business' most pressing need, or they use the software to fix an issue for a particularly assertive stakeholder. Even the best-designed software has a learning curve, and companies have to learn when it is appropriate to use the software and when another solution should be found. Instead, companies should focus on solving a non-trivial problem that the software is particularly well-suited to fix. This allows the company to build on positive experiences and provides a foundation to solve more difficult problems in the future.

Perhaps the most glaring example of this I've run across in my career dealt with a SharePoint implementation. My company was called in to help a client get started with SharePoint, since they had a great need for simplifying internal website creation and getting a handle on their document management. SharePoint is great at both of these things. But instead of starting on one of these projects, they tried to shoehorn a workflow system into SharePoint that stretched the abilities of the system. The implementation was so bad that the company almost abandoned the system entirely. 

Trying to customize the system too much

Purchased software can only do so much. In order to make the software appeal to as wide an audience as possible, the software makers will generally make the product as generic as possible. This means that businesses are faced with the choice of either customizing the system or living with a less-than-ideal solution. Most businesses will lean towards the former when they should really be focusing on the latter. Customizing third-party systems should be done as sparingly as possible, since any customization makes supporting the system more difficult in the long run.

This situation is actually quite common, especially with software whose main selling points are flexibility and configurability. You could pretty easily use the previous example as an example of why customizing the system too much is not a good thing. Instead, I will focus on some customizations I did as a consultant for a company trying to implement a Content Management System (CMS). Our client had products, but worked with distributors and so didn't want to post prices on their site, otherwise an e-Commerce system would have been appropriate. We had two choices - use the CMS as-is and ask our client to manually create pages for each product, or modify the CMS to make it easier to load and update multiple products at a time. We chose the latter approach. We did the best we could, but we never were able to get the system to work reliably, and the user interface was hard to use. We would have been much better off building an add-on that merely looked like it was a part of the system.

Not monitoring usage/progress

If you put new software in front of users, they will usually happily continue what they were doing before. They want to get their work done, and learning new software doesn't do that, at least not in the short term. If you make it impossible to carry on as before, they will try to use the new system, but in ways that you never would have expected. If either of these are allowed to continue, your new system won't be used very well if at all. Here the maxim "trust but verify" should be remembered if you want your new software to succeed.

An example I witnessed of this was a particularly difficult implementation of a Microsoft Dynamics CRM (Customer Relationship Management) solution. The project champion pushed for adoption of this system and customized several areas within CRM specifically for this company, but not only failed to follow up to ensure the users were using the system properly, but also neglected to train managers on how to use the system or why it is important to the company. When the project champion left the company, the software predictably fell into disuse to the point where no one understood why the company continued using it.

And you'll notice that documentation didn't make the list...

Many managers place a heavy emphasis on creating usable and complete documentation, yet I've never had a project succeed or fail because of the presence or absence of documentation. Motivated people will do the right thing regardless of documentation and unmotivated people won't check the documentation regardless of circumstances. Documentation is important, but it's a highly overrated component of software project success or failure.

Conclusion

If you want your software customization project to succeed, start by implementing a small and simple part of the system first whenever possible. Find a good fit for both your company and the software to help people understand how to work within the system. Have a roadmap for where you want to go, and communicate it clearly and consistently so people stay on track. Finally, monitor everyone so you stay on track to both ensure that people are using the system but also that the usage appropriately solves the problem at hand. If you don't do these things, your software either won't be used or won't be used well, so you won't get much out of your investment.