Let’s say you haven’t found any software packages that will support your factory’s operations in the way you need. You want to work on a highly/fully customized set of designs and logics. And yet, you have heard of 5- and 6-figure IT projects that led nowhere, and you want to avoid the same mistakes.
In our ‘8 Rules for Successful Software Implementation and Process Changes‘, we wrote rule 6 as follows: “avoid heavy customization if possible”. That’s generally the advice I give our customers.
However, if you really want to go down that route, here are our 5 tips for developing customized software.
Tip 1: plan for the roadmap… and break it into small stages
Having a fully developed idea for the digitization of your processes is great. A lot of things are technically and economically possible these days, from tablets to wearables and sensors, and from displays of key numbers to individual workstation status indicators.
However, break the implementation of that full idea into several phases. Do not try and fit everything into phase 1!
Rather than spending 1 or 2 months building complex workflows and only after that testing them in real conditions, consider making smaller [configuration + pilot trial] loops. You will have something simple in the hands of users faster, and you can take their feedback as inputs for the next steps.
Tip 2: explore your three main alternatives
- You can hire your own team and build the new tool within your company. You will need a Chief Technical Officer (CTO) to assemble and vet the team and to make the big decisions. You will need to commit to maintaining that tool over the long run. And just getting the bases in place will take months, with nothing to show. That’s the most expensive and, if you can finance it over the years, the most powerful option.
- You may find a software vendor that accepts to develop new features (for a fee) on top of their existing system and to bill you in SAAS (Software-As-A-Service) mode. You will need to explain your needs and let that vendor decide on the details of the implementation. It is their application and their intellectual property, and they will usually refuse to do something their other customers won’t be likely to use. You will benefit from some features already built that you can use, and they might charge you only a portion of their cost for your custom features.
- You may be able to negotiate with a software vendor for a non-SAAS deal and for custom feature development that can’t be re-used for other customers. The development fee will be higher, but you will have more freedom. Note, I have seldom seen this type of deal, but it exists.
Tip 3: Make sure your organization is ready
- Intention — do all managers, in all sites, have the same ideas in mind? Do they have compatible objectives? If top management wants to push something onto unwilling middle managers, the new software will not be welcome and may not get the level of support needed.
- Implementation — was the process actually put in place in a way that makes sense? Was it implemented in a consistent manner in the different business units?
- Ease of re-designing — I have seen companies develop a complex Excel file and keep adding many layers of sophistication to it. When they are asked to summarize the key features it achieves and to think of how it could be designed in a simple way in a new IT tool, a lot of resistance appears.
- Documentation — are there work instructions, flow charts, checklists, etc.? Are special cases, loops, etc. covered? If not, how will the designer know what is needed?
- Effectiveness — are people actually working as they are expected to? Or are they ignoring their managers’ intent and the documentation?
- Stability — is the organization going through heavy changes? Or have people had time to get used to the current process? Remember, the digitization of that process will probably bring enough changes on its own to require user training and a pilot.
- Persistence — if some custom logics and/or designs were developed, plan for hiccups in the pilot trial. Prepare the operations team for that – the solution is not ready yet and it is being tested to find what needs to be fixed/improved. People will have to give it some time.
Tip 4: give the developers an idea of how perfectionist you are
The normal steps of software development are:
- Documentation of the needs
- Gap between what exists and what is needed
- Quotation
- Configuration
- Pilot trial
- Ramp up
I’d also add a “step 0” to the above list: get a demo of the current software features, or a demo of another type of software the development team has worked on. Confirm if you like the overall design, and give them an idea of what you don’t like.
If you are very picky about the design of the solution to develop, you have make it very clear from the start. It may multiply the amount of work by a factor of 2 or 3!
As early as possible, work with the vendor to sketch the main pages and to design 1 or 2 of those pages, as part of the ‘needs documentation’ phase and before a final quotation is submitted. This may prevent a lot of frustrations.
Tip 5: keep in mind, custom-built software nearly always takes longer, and costs more, than originally planned
As I wrote in tip 1, make sure you break the roadmap in small blocks of work. The more complex the project, the (exponentially) higher the risks.
Do not push for premature optimization. Put something simple in the hands of users, and then iterate based on their feedback. Developing a complex solution out of the gate is often a recipe for a lot of rework.
Testing and debugging will have to be part of the process. Do not expect something that works “out of the box” in real operations.
If you require the development of new features and you are not flexible on the scope, you will probably have to be flexible on timing.
Summing up…
To sum up, bringing to life totally new functions may, in some cases, be the best or the only viable approach. It can be very frustrating if not handled the right way. If you follow these 5 tips, your odds of success will be much higher.
