It is very common for enterprises to look at off-the-shelf software that purports to solve the particular business challenge they are faced with. And why shouldn’t they? After all, if you can touch it and see it, you presumably know what you’re buying. Furthermore, packaged software tends to have a lower cost of acquisition (NOT necessarily lower cost of ownership over time, mind you) due to the development cost being spread over a higher number of installations. The risk that the enterprise takes on, thus, should be minimal. That is true enough…in some cases. Cases where:

  • the need is generic (eg. word-processing where MS Word will suffice or email where Outlook is enough), or
  • the requisite solution meets a need that’s standardized within the industry (eg. medical billing software for physical therapists), or
  • the need is non-core and thus the possibility of having to conform your business processes to the software is a worthwhile trade-off

If, however, the solution:

  • has no off-the-shelf alternative, or
  • needs to accomodate unique internal processes (which, incidentally, tends to be true in organizations in highly competitive industries where the key differentiator is usually at the process and management level), or
  • needs to deliver very high levels of efficiency, or
  • will be expected to integrate with a variety of other information systems, or
  • will be expected to grow to meet as-yet unanticipated needs

then, a custom software development project just might make sense.

Custom software development, however, is not for the faint of heart. Anyone that has tried it probably has a war story to tell - stories of botched development suffering from poor understanding, lack of communication, scope creep that leads to over-budget and behind-schedule implementations, and even software that, when deployed, turns out to be totally useless.

Avoiding these pitfalls is hard work, but in no way impossible. Here are two key risks that should be actively managed to give you a fighting chance.

Risk # 1: Trying to automate bad processes

Pearl of Wisdom: Automating bad processes just leads to tears faster.

Risk Avoidance Strategy: Allocate time, money, and organizational resources to get rock-solid requirements. This also includes evaluating your current processes. Is your existing workflow unwaveringly exact every time? Are your current process streamlined already or can they be made more efficient? Have you cut out as many exceptions out of your business rules as possible? Tell-tale signs of bad processes include:

  • your team feels that the process is “quite complex”
  • there is no consensus within your team on what the process is exactly
  • it’s hard to keep track of all the exceptions

Bad processes tend to cause software architects to draw up incomplete and flawed user requirements. These requirements, in turn, cause developers to create elegant solutions for a broken workflow.

Risk # 2: Scope Creep

Pearl of Wisdom: Don’t gold-plate, focus on demonstrable return on investment, instill business-focus rather than technology-focus as a core value.

Risk Avoidance Strategy: Scope creep is a phenomenon defined in project management as uncontrolled changes in a project’s scope. Another way to put it: what exactly is being built keeps changing. Scope creep can occur because:

  • the requirements are ill-defined, processes are ill-understood, and/or stakeholders are ill-selected
  • gold-plating occurs because someone wants a particular “cool” feature added in that has no correlation to greater value
  • developers or IT personnel are rearing to use a new technology they’ve been reading about without any consideration to whether it’s the right tool in the first place
  • management lacks the requisite discipline to define scope and then hold it steady

Gold-plating and focus on favorite technology tends to lead to longer development times, higher cost, and, perversely, despite being provided both, lower usefulness of the software. There are too many features that make a user’s job harder to perform thereby increasing adoption rates and decreasing productivity. IT’s focus on technology rather than focus on business may mean higher development costs on the backend but possibly also higher utilization costs on the frontend should the selected technology lead to performance gaps, limitations to scalability and integration, and higher costs of managing the operating environment.

Those charged with delivering a custom software solution must, thus, instill a “business need is king” mentality where technology knowledge is important, but not as important and sacred as the understanding of and objective assessment of the core business operations. Demand return on investment analysis as well that is based on a strong requirements analysis. Anytime a change to the requirements document is proposed, go back to the ROI document and evaluate what the added time and financial cost means to the company.

 

It’s like ten thousand spoons when all you need is a knife.

Alanis Morissette

 

Risk # 3: Mismanagement of Scope

Pearl of Wisdom: Asking for everything to preempt scope creep is a great way to go, assuming you want to lose your shirt in the process.

Perhaps even more fundamental than the risk of scope creep is knowing what the ideal scope should be in the first place. The Pareto Principle, modified for purposes of software development discussion, suggests that 20% of processes account for 80% of contribution to productivity. The holy grail, then, becomes defining this 20% and building that into your initial scope document. Additional features may simply be costly overhead that only lose, confuse, and mislead users and cause them to make mistakes. What’s more, these additional features all need to be accounted for when systems are modified, upgraded, or extended. This leads to higher development and maintenance costs in the future.

Any comments to counter or refine my thoughts would be most welcome!