In the previous article I raised the fictional scenario of a company wanting to automate a timesheet submission process. In this article I'd like to touch on some of the project processes that would be used by the majority of companies.

Generally, most companies will start off with the sensible process of evaluating existing software packages, looking at what's out there and maybe even seeing what other companies use. After a period of time a sensible company will come to the conclusion that there is no one piece of software that fits their requirements and so their requirements must change as well as some processes. This is a key point as every company likes to think that they are unique and so around that uniqueness certain process have appeared so when it comes to upgrade or computerise those processes they are reluctant to change them.

However, back here in the real world most companies will do one of three things, they will

1. Abandon the idea
2. Buy the commercial package closet to their requirements and get it customised
3. Hire a developer to write a bespoke piece of software

Of the above three options the first is the best and safest but at this point many companies make another fundamental mistake. They never document the issues found or the reason for the project to be abandoned. This means that often someone else will reopen the project 6 to 12 months later, reinvestigate options and then select option 2 or 3.

Option 2 is an interesting one, surely there can't be much wrong with making some customisations could there?
Well, it depends. If the software is designed to allow those customisations then go ahead. However, may companies will want to alter certain business logic (e.g. maybe three people would have to approve a timesheet and the system, by design, only allows a maximum of two.
Quite often a company will purchase development skills and get the codebase changed to support what they require. This causes a problem when upgrades are required or if a security hole is discovered as often the customised verison will break when patches for the mainline system are applied if it's even possible to apply them at all.
Now the company ends up in a situation where they like and want the features in the next version but are tied to an old version due to the customisations, often they will have to face the choice of staying with the customised version, migrating to the new version or paying out to get the customisations in the new version.

Option 3 opens up all sorts of interesting possibilities for problems and complications to occur but I'll save that one for another blog