A Utility project is where underlying business process is not the differentiator, e.g. Payroll process, every company want it but a better payroll process does not give your business edge over your competition.
The way you staff, run, and budget a strategic project is entirely different to how you do a utility project. For utility projects the biggest risk is some kind of catastrophic error – you don’t want to miss payroll. So you need enough attention to make sure that doesn’t happen, but other than that you want costs to be as low as possible.
However with strategic projects, the biggest risk is not doing something before your competitors do. So you need to be able to react quickly. Cost is much less of an issue because the opportunity cost of not doing something is far greater than costs of software development itself. Usually only 5-10 percent of projects are of strategic type.
Since the definition of utility is that there’s no differentiator, the obvious thing is to go with the package. For a strategic function you don’t want the same software as your competitors because that would cripple your ability to differentiate. Often people realize this and buy a package for a utility project, but then spend huge amounts of money customizing this – which is just as wasteful. My view is that for a utility function you buy the package and adjust your business process to match the software. Usually this is politically infeasible, so the workaround is to put a low grade software team to work on it, provide enough care to avoid catastrophe.
[via Martin Fowler]