Now, let's return to the central topic: how to effectively engage a technology vendor to get it right the first time.
Don't engage a technology partner to help with your business
One of the biggest mistakes organisations make is to engage the technology vendor too early, on the premise that they will help them with their business processes. The technology vendor knows about technology, not about business -- after all, you wouldn't get them to run your next business strategy meeting -- so why are they relied on when it comes to the business processes that have to deliver on the strategy?
With such a heavy focus on the technology, the IT department begins to think that business is all about technology -- in fact, business is about people. That is, people doing business with other people to exchange value through products and services. Therefore, if you only engage a technology company, you immediately create a void on the people and business side of things. Successful organisational change comes about when people, business and technology are fully aligned.
When they're not aligned, staff who want to do a better job are forced to find workarounds for poor practices. But once the processes are embedded in the software, it becomes harder to get around the inefficiencies. Then two things happen -- people start performing at a lower level and/or they return to the old applications or use Excel and Access databases to compensate.
So why doesn't the business first engage a business management expert to assist them in ensuring their business processes are best practice before embedding them in software?
Pick a vendor that can match 'your' business model
Instead of compliying with the application's embedded business model, organisations must ask the fundamental question about their technology partner: 'What do they know about my business?' Even better, 'What does this technology vendor know about best practice, change management and other fundamentals of running a successful business? How do I know the embedded processes really work and are best for my staff and customers?'
While the vendor may be able to successfully run their own business -- selling software -- what do they really know about other people's businesses and people's performance? How can you know that the changes their application will invariably force will improve business or drive success? You could even ask if the technology vendor uses their own software to run their business.
Before you pick a vendor, you need to be absolutely clear on the business processes, user requirements and interface designs necessary to implement these processes. Technology vendors are not generally good at this aspect and leave it to last, or downplay its importance.
Cheapest is not best
The tough competitive landscape means that vendors need to cut their prices to 'get in', knowing full well they'll make up fees in the ongoing change requests and the fact they'll still be working on it years after they said they'd finish. For its part, business has also been known to twist vendor's arms on pricing. Something's got to give and it is invariably the quality of the end result.
Despite the promises of off-the-shelf software, there is always some customisation required as you find out that the software doesn't work the way you want it to. How did you end up in this situation? Mainly because the initial requirements were so vague and ambiguous that any of the vendors appeared to deliver on them -- so you picked them on price. But as we all know, the devil is in the detail. With inevitable customisation requirements, custom built software may be a better solution.
The critical success factor: The user interface is all people see!
With technologists in charge, the user interface is generally the last thing to be designed. Why is the user interface critical? Firstly, the user interface defines the application behaviour and implements the business processes. Second, to the user, it is the application: you don't take the executive down to the server room to stare at the hypnotic qualities of the flashing lights, or let them ogle in wonder over the coders' shoulders. The only thing they (and end users) can make sense of is the user interface.
I mentioned earlier the gap technology vendors have in getting the people and business side right -- well this is where it all goes pear-shaped. If your staff can't use the application, or it takes twice a long as before, then this is where your return on investment will evaporate. Staff will just go back to the old ways or use their spreadsheets instead. The alternative is to continue to engage your vendor and work though hundreds of iterations with the user interface as you try and get something that people understand and can use.
Don't assume customisations will work when the base program is updated
The vendors regularly update their fundamental codebase to introduce better and better technologies. Unfortunately, all that customisation that you had to get to make the application do something close to what you need is not compatible and needs to be done again. If you don't upgrade, the vendor simply 'desupports' the old version and you are stuck in a bind - pay more money to stay up to date with an application that will still not work the way you want it to.
As I suggested earlier, sometimes custom software may be better.
Please sir my comments is to ask you that using a computer for long hours can cause brain or eye problem?