Recently I created a poll on LinkedIn asking the following question:
Yes, I am disappointed with the # of responses, yet I have high respect for the respondents. Thanks to all for the feedback! First, I will start with the textbook answer that stakeholder management is the first step in requirements management. Good job my friend, Lauren! I’ve never used a stakeholder context diagram (learning opportunity).
However, I’ve been around enough ERP projects to know that requirements management is not a neat linear or circular process.
It’s messy. Requirements management (i.e., setting expectations and scope) starts in presales and sales. Greg & Chris are insightful regarding internalizing the need for a new ERP solution. Typically, sales teams utilize tools like “influence maps” and “decision maps” as a rudimentary point for stakeholder management.
Source: Powerslides, Influence Map
Yet, stakeholder management is not a one-time document, but an iterative approach must be taken to fully develop a competent stakeholder management document. Many ERP SI partners wrongly think stakeholder management is a one and done activity. Sam, discovery is a vital part of requirements management and will identify and/or reinforce the key stakeholders (sources) for business requirements. Greg, I never had a true appreciation of ERP software selection until I worked for an ERP software selection provider. ERP software selection instills a discipline that is missing today where most ERP selection decisions are based on human perceptions.
Source: E-Max Systems
On last note, prototyping is an excellent approach to utilize in situations where business requirements are evolving. Examples include implementing a new ERP module or business activity where the customer is not sure what are their requirements and they do not have a complete appreciation of all the stakeholders.
Sorry folks, I could not find a competent, viable diagram to define a process for defining emerging requirements for COTs/ERP solutions (future blog post).
In summary, effective requirements management cannot be executed with a simple checkbox mentality. Experienced SI partners should always assess the heath & quality of document business requirements and take the necessary actions to fill the gaps via additional discovery, stakeholder management, scoping, prototyping and/or validation.
My Humble Opinion,
Noted Sources: I prefer not to reinvent the wheel but to bring different concepts into the right context.