Project Management: Process Classification
"There is more than one way to skin a cat." That phrase has an interesting history, but it's still amazing to me how often that saying get used today. I was going to use it again but instead I'll just say there are lots of ways you can go about classifying requirements when implementing an ERP system. I actually don't care that much what system someone uses, as long as they have a system. If you use the Sure Step Excel sheet to track requirements, you'll be doing it according to the module under which the functionality exists. We started doing that too, but we found a big problem with it - traceability.
Why Is Traceability Important?
Traceability is a big word that doesn't get thrown around too much - however, it's important in the context of an ERP implementation. You need to be able to understand from where your requirement comes. If I'm the second consultant looking at a requirement that says "Add external comments to the project invoice report", I would say, "great, we can do that". However, I have no idea why that requirement exists or who originated it. When I have the developer modify the report to add this field, who do I have test it to make sure it looks the way they want. This is where listing a ton of requirements in a spreadsheet falls down. It's a lot of information that's disconnected from anything other than a module.
You can still classify requirements against modules if you'd like, but you need to include information about who requested and why. This is what we started doing on our first couple of projects, and it worked okay because they were smaller projections so we knew where to go digging if we had a problem. The concept starts to get pretty difficult when you have a big project with multiple SME groups and different consultants. We found it much easier to associate requirements with a process that the customer follows.
Process Driven Approach
At Stoneridge Software, we use a process-driven approach to gathering and tracking requirements. What this means is that we first learn the customer's processes, then we start to figure out what they need the system to do to support these processes. These should be their "to-be" processes, and not just how they do things today. We dive deeper and deeper into the processes throughout the analysis and design phase so we can get down to the task level and understand everything that needs to be done to achieve this process. To help us define this, we've adopted the hierarchy that's articulated in Lifecycle Services, which originally comes from the APQC.
By utilizing this approach, we can trace a requirement back to a process which has a defined process owner and a visual workflow so we can see where the system need fits into the process flow. This really helps us trace back the need for the requirement and makes it easier for us to understand the importance of it in their flow.
Process Hierarchy
Here's my representation of the process hierarchy which includes a Process Category, Process Group, Process, Activity and Task:
In Lifecycle Services, Microsoft has used the APQC hierarchy to provide 12 process categories and their associated process groups, processes and activities. While we agree with the hierarchy and the approach, we have found that re-classifying the process categories to fit an ERP implementation activities more closely as a better plan for us.
How We Approach a Project
When we start a project, we come in with a set of process categories and groups based on projects we've completed in the past. We first try to see if the customer wants to implement any or all of these process groups and then understand what different process sets they have which we'll need to explore. We then put them into the broader hierarchy within our SharePoint site and Enterprise Architect so we can trace back any requirements to the processes which ultimately lead back to these process groups that were originally defined. By using a relational model for our process tracking, we have an approach that will allow us to connect the whole project together and make sure that our plan is comprehensive and cognizant of the other parts of the implementation.
Let me know if you're interested in learning more about this approach and I'll continue to add more nuggets to it over the next few weeks.
Eric Newell
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.