Mark Porter is the UX Lead on the HighGear dev team – he was instrumental in developing HighGear’s visual workflow, and is currently leading a major overhaul of our UI.
The decision to build or buy a software solution when solving business problems can be a challenging one. Your IT team says they can write a custom solution in a fraction of the cost of the off-the-shelf solutions available on the open market. It can be tempting to just go with the in-house solution. You figure you know exactly what you’re going to get, the in-house solution will solve your business’ needs and nothing more. However, there are often hidden costs when implementing a custom solution that can cause the project to take much longer, and cost significantly more, than anticipated.
The Hidden Costs of In-House Solutions
As a software engineer, I’ve had to learn about these hidden costs the hard way!
Firstly, you have to gather the requirements for the solution, and this can be a complicated task. Often the stakeholders don’t know quite what they want and you have to work it out with them. Also, this can be further complicated when the requirements change throughout the development of the project (as they invariably do). Here is a post by HighGear’s CEO, Vaughn Thurman, on Emergence Theory and how it applies to BPM.
How High is the Learning Curve?
Secondly, you may have some new technologies to learn in order to complete the solution as desired. It’s difficult to know how long these parts of the solution will take to implement, because you have to learn the new technologies before you know how long it will take to apply them to the solution.
Does it Scale?
Thirdly, you have to consider the time it takes to make the solution scalable. The first version may support the immediate load and user requirements, but will it be built in a way that can sustain future growth? If not, significant time may have to be spent down the road to improve or rewrite the solution to accommodate new needs.
What About Maintenance Costs?
Fourthly, you have to consider the maintenance costs. Even if the initial development estimate is accurate, there will be time required to fix bugs and keep up with changes in technology. If you don’t consider these factors, you may be left asking for more time and budget to deliver the promised value.
When writing software, you usually don’t know what kinds of issues you will run into until you run into them. This makes estimating development time quite challenging. Unless your business problem has very clear requirements and your development team has prior experience with a similar project, you are better off purchasing an off-the-shelf product.