The Pareto principle (also known as the 80-20 rule), states that, for many events, roughly 80% of the effects comes from 20% of the causes. The principle was developed to explain income and wealth distribution in Italy. This principle has evolved into a “rule of thumb” in business. In the software industry the Pareto principle has been applied to several areas:
- Fixing the top 20% software errors would result in addressing 80% of reported software issues.
- 80% of the value customers receives from software comes from 20% of the software’s functionality.
ERP Selection Case Study
I recently completed a software selection project for a mid-market discrete manufacturer. A key activity for software selection is prioritizing requirements. The following table provides an executive summary of our requirements gathered.
|
Area | Requirements | Pains |
Benefit Opportunities |
| Order Management |
207 | 35 | 25 |
| Warehouse |
93 |
19 |
16 |
| Manufacturing |
88 |
17 |
9 |
| Engineering |
44 |
24 |
16 |
| Finance |
142 |
8 |
24 |
| Purchasing |
37 |
23 |
11 |
| Reporting |
77 |
14 |
38 |
|
Total | 688 | 140 |
139 |
Allow me to make a few key points. Gathering requirements is an iterative process. The objective of requirements gathering was to define requirements to a level where the customer could make an informed decision on selecting an ERP solution. As the implementation progresses from software selection to implementation the high-level business requirements will be further refined. Second, as you gather requirements it is important to capture business pains and benefit opportunities. Pains are limitations or barriers that keep business from meeting their objectives. Pains may result in additional requirements and/or opportunities for quick wins. Benefit opportunities are directly related to business requirements and will enable the customer to start with developing the business case up-front versus towards the end of software selection (which is reactive and a bad practice for software selection).
Requirements Prioritization Guidelines
Requirements prioritization can be a painstaking, time-consuming process. For the customer in this case study we had a single prioritization session instead of individual, functional prioritization sessions. As part of the joint session we defined the following guidelines:
- Individuals should consider their top 3 – 5 business requirements.
- As a group we will determine priorities for all requirements (not just your own).
- Priority classifications: “Must Have”, “Valuable”, “Nice to Have”
- “Must Have” requirements include competitive, strategic, and compliance business needs. Revenue-generating business processes should drive the majority of these requirements.
- “Valuable” requirements are usually not “show stoppers” however, they will add quantifiable benefits to the organization.
- “Nice to Have” requirements are convenient but do not provide a significant or quantifiable benefit to the organization.
- Rule of Thumb: Demonstration scripts for vendor demos should primarily focus on “Must Have” requirements.
- Using Pareto to estimate requirements prioritization
- No every requirement should be marked as “Must Have”.
- Prioritization should be solution-based, not functional-based.
- 80% of benefit is generated from 20% of effort (requirements).
- 20% (138) of the total requirements (688) gathered should be prioritized as “Must Have”.
Summary
Prioritizing business requirements for an ERP selection project is both an art and a science. Sorry to say that there is not a simple formula that can help you magically produce appropriate rankings. There are heuristics like Pareto’s principle that can provide you “signs” that you are heading down the right path.
Join the community! 10k followers across 100 countries!
Leave a Reply