The only reason new ERP software fails is that it doesn’t meet expectations. That happens because buyers make assumptions about the software that they later discover are not true. This is the "devils in the details" problem.

The way to avoid this problem is to document those assumptions as requirements. “That's crazy!” people say, “There are so many things the software needs to do! That is too much work, and it will take too long. And our users don’t even know what they want.”

But that is precisely the problem. If you can't be bothered to define what you want because those requirements are "unimportant," you can't complain when the software doesn't meet those requirements because they weren't important. Unfortunately, when the new software goes live you discover requirements you didn’t think were important actually are, but by then it is too late to change.

Business requirements specify WHAT the software must do, while software requirements specify HOW the software will be configured (or written). When selecting ERP software over 99% of the requirements will be business requirements. Less than 1% of requirements will be software requirements, and they are usually for interfacing with other systems.

WHAT to do, HOW to do it & WHY it works

Business process discovery

Start by interviewing business process owners, which are the people in a company responsible for business processes being executed. These interviews may also include power users.

Rather than asking users what features they want in the new software, ask them to describe WHAT business processes the software needs to run, and WHAT outputs those processes must deliver.

At this stage you don’t need to worry about HOW things are done; the HOW is handled during the implementation and will depend on the ERP selected. People have a natural inclination to talk about HOW they do things today but keep them focused on WHAT business processes they run because the new software must run these same processes and deliver the same outputs.

Best practice advice

• Interview people online using a tool like Zoom and record the meetings. You can pay full attention to the interview and not get distracted by taking notes because your interviews are being recorded.

• Do not have people join the zoom meeting from around a conference room table because it makes it difficult to identify speakers in the transcription. Have people on the zoom call join individually from their own PCs.

• To save time with the transcription, ensure everybody names themselves correctly on Zoom.

• Start each interview by having all the participants introduce themselves and explain their role in the company. You use this information to identify the speakers in the transcript.

• Sometimes participants may share screens to show a process. This gets captured by the recording and can provide useful process information.

• Focus on the pain points with the existing software, because the new software needs to address those pain points. (If it doesn’t, what was the purpose of the whole exercise?)

Meeting transcriptions

Transcribe the meetings with a tool like Otter.ai. Otter’s machine transcription is not perfect, but it is fast, good enough, and economical. And you can listen to the audio behind the text and correct it if needed.

Best practice advice

• Break up the transcription into one idea per paragraph. Otter gives each paragraph its own timestamp and identifies the speaker.

• Avoid the temptation to correct every error in the transcription. The goal is to use the transcription to generate business requirements, not to have a perfect transcription.

Capturing requirements

Summarize business processes and process outputs from the transcription in a tool like Smartsheet. For every hour of recording, we budget 4 hours of summarizing.

Best practice advice

• Use Smartsheet to organize requirements hierarchically in increasing levels of detail as needed. This keeps related requirements together and in context. While spreadsheets can organize things hierarchically, Smartsheet is FAR easier to use, and you can export the result to Excel if needed.

• When capturing a business process or output in Smartsheet, capture the recording, speaker, and timestamp in a column. Use this to refer to the recording if the notes in Smartsheet are unclear. This also gives you full bi-directional traceability so important in regulated industries.

• Focus on users’ pain points because they are usually the main drivers for replacing outdated software.

• Once you have captured all the business processes and process outputs you can write the business requirements for the software features that will execute those processes.

Prioritizing requirements

After writing your requirements, you need to prioritize them.

Best practice advice

• Generally, most requirements discussed will be weighted as “Showstopper” because software with those features will execute the necessary business processes.

• When multiple people mentioned the same pain points, those are automatically high-priority requirements.

• You may also want to capture “Future requirements” when you know something will be needed in the future.

• Any requirement that is prioritized as less than “important” should not appear on the RFP because it is not important!!

• It is worth capturing requirements of “No interest” because this documents the requirement was discussed but deemed not worthy of including on the RFP, important for regulated industries.

Wrapping it up with a gap analysis

Once requirements are specified and prioritized, you can have vendors respond to an RFP. Often this is done by emailing them a spreadsheet. After the RFP closes, use a gap analysis to measure how well different potential products meet your requirements, and that is the topic of a future post.

All ERP purchases involve some degree of compromise. The purpose of the software selection is to minimize that compromise. Beware of the vendor that claims to meet virtually all your requirements with minimal compromises. Either your requirements are badly written, or the vendor is “excessively optimistic” about their software. Either way, you are taking a huge risk.

Remember that at the end of the day, provided it is reasonably easy to use, WHAT the software does matters far more than how it gets things done.