8 reasons why committees fail when selecting enterprise software

Enterprise software is always purchased to solve business problems. For example vendors no longer support the current software, new functionality is wanted, new compliance regulations must be met and so on. In all cases, business needs drive the decision to move forward with acquiring new software. Unfortunately, as the horror stories that so regularly appear in the technical press attest, buying enterprise software is inherently risky.

Finding the best-fit software for the organization’s particular needs and budget will minimize that risk and deliver the greatest ROI. The question that arises is this: What process should be used to identify that best-fit software?

Organizations often make major decisions by committee. However, when it comes to selecting enterprise software, this decision-making process is flawed. This article examines eight areas where committee decision making fails and suggests a better way to select enterprise software.

1)     Underestimating complexity

Most organizations underestimate the complexity of enterprise software products that literally have thousands of features. The organization must examine how well those features meet their requirements because most of those features will affect their business. If there is too great a mismatch between requirements and features, the software will fail. Typically, committees lack the time, resources, tools and methodologies to deal with this level of complexity. They take shortcuts that usually lead to problems or disasters.

2)     Inadequate experience

A committee based software selection decision assumes members adequately understand organizational needs and have a good enough understanding of that particular software market, but this is seldom if ever true. Organizations also need “out of the box thinking”, i.e. perspectives from outside the organization that can challenge assumptions people don’t realize they have. As many organizations find out from bitter experience, assuming committee members have the required background is a flawed assumption.

3)     Underestimating time required

The total cost of ownership for enterprise software is in the multi-millions, and a thorough software evaluation and selection process requires hundreds or thousands of hours of work. Even though much of the work will be delegated, committees are never prepared for this. Shortcuts are inevitably taken leading to the wrong software being selected.

4)     Inadequate requirements discovery

An enterprise software selection project is a journey of discovery where an organization uncovers their real requirements. Committee decisions attempt to substitute experience for this requirements discovery process. This fails because there are too many requirements when selecting enterprise software and committees neglect going into a great enough level of requirements detail. Committees don’t realize that front loading requirements development significantly reduces overall project risks.

5)     Inadequate implementation estimates

To be cost competitive software implementation vendors tend to understate costs and make up the difference with change orders. Software selected by a committee lacks the analysis that is so essential for an accurate implementation estimate. However, when software is selected based on a thorough evaluation process, there is a detailed analysis of the winning product, which is used for accurate estimations of the implementation work required.

6)     Implementation delays & cost increases

When a software selection process starts, there are always unknown requirements. A detailed analysis that includes the reverse engineering of features will uncover these requirements. However, if that detailed analysis is not done, these requirements are discovered during implementation where satisfying them introduces delays and increases costs. Some people call this scope creep, but it isn’t. Those requirements should have been uncovered in the analysis phase of the project, and then built into the plan.

7)     Voting process logically flawed

Using a committee to select software only masks the real problem, which is a faulty decision-making process. If you start with a software product selected by vote or consensus and work back towards the requirements, you arrive at a “black box”, namely the voting decision made by committee members. There is no logical way to trace the decision back to the requirements, which means there is no way to verify the correctness of that voting decision.

Compare this to a deterministic decision driven by weighted requirements and where the features of software products are scored against those requirements. There is a logical path between the software selected and the organization’s requirements (the traceability matrix) and the selection decision can be verified from the requirements. 

8)     General committee decision problems

Examples of general decision-making problems that software selection committees can suffer from are:

• Committee Leadership that is either too strong or too weak. Strong leadership can lead to authority deference. Weak leadership can result in one person dominating the process.
• Groupthink. Here a desire for group conformity leads to flawed decision making.
• Group decision fatigue. The selection project seems to drag on forever, and the committee members just want to make the decision and move on.

The solution

Some organizations rely on committees to select software but, as shown above, committees lack the process needed to minimize software selection risks and maximize ROI. They end up paying the price of poor software selection decisions.

Don’t waste the opportunity you have when selecting new enterprise software. Use a data-driven and deterministic process to remove subjectivity from the selection decision so you identify the software that best meets your particular needs. Use the information generated by the evaluation to reduce software implementation risks. For a real world example, see the Wayferry process, which is a refinement of the Kepner-Tregoe process adapted for software selection.

Acknowledgments

Article by Chad Stewart of SmartThoughts: Do Groups Make Better Software Decisions?