Building bespoke software can be perceived as a risky, costly option. But just like any project it’s all about understanding what you want, controlling the project and reducing risk.
“It’s too expensive”
It’s true that bespoke build software is never going to be cheap. You are building a tailored, quality product to meet your specific demands, and this requires dedicated software developers that are normally charged at a day rate. So in a time when everyone is use to acquiring and using ‘freely available’ software products, the costs can seem high. But rather than focusing on the costs you must look at the cost/benefit model. Whats important is that the project ‘pays for itself’ over an acceptable period of time.
There are also variations of cost models to explore. Ask your supplier to ‘fix price’ the development so that they share the risk, rather than just paying them a day rate.
“It never does what we want it to”
Well make sure everyone knows what it’s got to do before hand, get it documented and track your project deliveries against it. It sounds easy, but it’s very easy to overlook, seemingly innocuous, issues or requirements that can have a huge impact later on. I heard of a project that needed to interface with a third party database. “Don’t worry about that we’ll sort that out later, let’s crack on with the app”. As it transpired, the 3rd party database didn’t provide an interface, wasn’t contractually obliged to do so and couldn’t do it. The result was a team of additional temporary staff were required to manually enter data from one system into another, costing the business more money than before.
Also, make sure you get the right people ‘bought in’ at an early stage. It’s a fact that nearly everyone will object to changes to the way they work if you just spring it on them. Get the heads of the departments involved. Ask them to provide some staff who know what they’re doing and listen to them. These people will then become the ‘Ambassadors’ of your project rather than your ‘Assassins’.
I went to a new client not so long ago, to talk about a new stock allocation system for their business. “Who, outside of IT, should I talk to” I asked. “Oh no, you don’t want to talk to them” they said “they will just ask for all sorts of stuff”!! Well isn’t that the point. Listen and learn, and make sure the requirements deliver the project scope.
“It’s always full of bugs”
Anything ‘hand built’ is going to have defects in. There’s nothing you can do to stop it. But you can reduce the risks of defects having any impact on your business.
- Get a good supplier with a proven track record with relevant experience. Good developers will produce better quality code.
- Know you requirements and make sure everyone else knows your requirements. Unclear requirements leads to misinterpretation and assumptions.
- Test, test and test. A good, comprehensive quality plan is essential. Know who is doing what testing, what they are to test, and how they’re going to do it.
- Don’t rely on developers to do the testing.
- Catch any defects early. Generally the cost of addressing defects goes up the later it is detected in the project
- Don’t skip testing because your project is running out of time.
For more information on whether bespoke software is right for you read “When bespoke software is right for you”