Nobody likes to fail. Nobody likes to do a poor job. And nobody likes to deliver less than they have promised or what has been asked of them. But unless you have clarity on what it is you are to do, the probability is you will miss your mark, possibly by a significant degree.
This is more common than it should be, and the impact is extensive. And believe me when I say we are not being overly dramatic.
The importance of requirements analysis in ETRM selection cannot be overstated.
Notably, the requirements analysis part of CTRM or ETRM selection goes hand in hand with the first phase in selecting the right ETRM system (or systems) for your organization: Defining the problem. We can go in depth about that topic too, but for this post we’ll assume you’ve accurately identified and defined the problems you’re looking to solve with an ETRM system.
So why do we say œfail? Because even if you know for sure the problem you’re trying to solve, poorly or inaccurately defined requirements can make solving that problem an uphill battle. To understand why this is, let’s first explore requirement types.
The Different Types of Requirements
œRequirements is a fairly broad term, so let’s narrow it down a bit and walk through the three main types:
- Functional requirements
- Non-functional requirements
- Organizational requirements
Functional requirements tell you what the system does (i.e., functionality) to help solve the organizational problem. These are specific functions or behaviors of the system, in specific words. For example: œCapture user-entered date range and use to search for and display selected report type for that date range.
Non-functional requirements tell you how the system performs its functions. These are a bit broader than functional requirements and impose certain attributes or demands onto the behaviors of the system.
For example, you may require the system to search for and display user-requested reports within a certain timeframe, say 10 seconds. Another example would be having the system be compatible with a specific browser. One further example could be requiring the system to be cloud based.
Organizational requirements tell you everything else, including the who, where, and when. These requirements represent the criteria, restrictions, or boundaries that the functional and non-functional requirements must fit within. Sometimes, these are referred to as project requirements or critical success factors.
For example, the system may need to be implemented by a certain date. It may need to abide by a predetermined budget. Another constraint could be the location of the implementation. There could also be criteria for who is involved with the implementation, such as in-house or vendor personnel.
A summary of the three different types of requirements
What Requirements Have to Do with Avoiding Failure
As you probably gleaned from the descriptions above, these requirements represent the fundamental building blocks of an ETRM implementation. You need to know what you want the system to do; how the system should accomplish it; and the œwho, œwhere, and œwhen constraints to abide by.
Otherwise, you’ll be going into your ETRM implementation blind. And that’s a sure way to engineer failure into the whole project.
What Failure Looks Like
It’s important to remember that requirements analysis applies to all of the ETRM systems available in the market”including ones such as OpenLink, Allegro, Brady, TriplePoint, and Ignite, to name a few.
We’ve helped organizations implement a number of these and similar systems. But a consistent œlessons learned we’ve observed revolves around the requirements analysis portion of ETRM selection.
Now, of course, when we’ve been approached for ETRM selection consulting, we’ve advised our clients on giving the requirements analysis phase appropriate due diligence. And the implementation portions of those engagements were all the better for it.
However, for the times we were not approached initially, the results tended to be¦different. In several instances, we were asked to lead the turnaround of an already-in-progress ETRM implementation. These turnaround projects were either over budget, out of scope, outside of contingencies, lacking accountability, or some combination thereof.
Yet, through returning to the core principles of requirements analysis, as well as re-planning, we were able to put these projects back on track and deliver within reasonable parameters. Now, given the opportunity to rewind, do you think the organizations we helped with turnaround engagements would take the same approach they took the first time around?
Hopefully not. (Unless they’re gluttons for punishment!)
Takeaway
Putting it plainly, success or failure is highly dependent upon your requirements analysis. The effort you put in at this beginning stage will have a direct impact on whether your implementation proceeds smoothly or stalls.
Of course, this is all predicated on your organization’s ability to perform a thorough requirements analysis that takes into account the specifics of ETRM systems.
And with that said, I’ll close with this: You start with what you know, and you are bound by that knowledge, unless you seek additional knowledge to extend that boundary. Which means you can’t get the best answer for what you need without outside expertise. This is especially true in the niche C/ETRM space. So, don’t go at it alone!
Thoughts you want to share? Join the conversation below.