Introduction
A key challenge in business transformations is the definition and management of user requirements. Understanding this as well as strategies, processes and tools to sets the basis for every successful business transformation, with ERP implementations being no exception from this rule. While user requirements gathering and management used to be more straightforward using Waterfall where usually workshops and interviews were used and extensive time was invested at the beginning of the project, challenges seem to raise in large scale transformation projects when Agile-Hybrid methodology is used and a high volume of requirements is gathered and need to be managed.
Definition
A general requirements analysis takes place at the beginning of a project to capture the business goals and organization’s vision and a set of documents are created. In ERP transformation projects, user requirements are usually categorized between functional and nonfunctional. Functional requirements describe what the system should do and outline the system behavior in detail, while nonfunctional requirements include quality related metrics such as reliability, usability and customer experience.
In Agile environments user requirements are captured in a container of work called Backlog. The product backlog contains all the features and scenarios an organization wants to implement and which will later be converted into User Stories. The purpose of a user story is to describe a single feature or scenario as seen from a user’s perspective and provide context for the functional and development teams and their efforts. User stories are the smallest unit of work within an Agile environment and as a result in large ERP transformation programs a vast amount of them is generated which teams have to manage.
Requirements Gathering
Familiarizing business users on how to define a user story should be part of the overall Agile methodology approach in an organization. If your organizationis not following a holistic Agile approach, it is a key prerequisite to ensure enough knowledge and training has been given to the stakeholders involved in this phase. Transforming user requirements intoone or more user stories and define clear acceptance criteria, sets the foundations of your future solution. Getting this phase right, will save time and unnecessary efforts from going through re-iterations of user story definitions and rework cycles.
Our advice “Collaboration”
Collaboration is a key component to make sure that all stories and their respective acceptance criteria have been understood and can be successfully build. Many times, especially in complex system requirements, using a non-technical description it is hard to visualize into a technical solution. As such, collaboration is required and needs to be integral part across all teams to succeed in the definition and understanding of those stories. Make sure to establish communication bridges and a clear path of interaction between the different teams where clarifications and discussions can take place instantly throughout this stage.
User requirement life lifecycle management
In large-scale ERP transformation, hundreds and thousands of user stories may be defined. Managing such a high volume of requirements becomes problem for several of our clients. We have identified three key challenges which are related to the phases of:
- Prioritize and schedule
- Manage build and Test
- Manage Document lifecycle
Prioritize and Schedule
Prioritizing and grouping the user requirements is the next step in the implementation once these have been defined. Requirements should be planned and grouped following a hierarchical approach. Not all user requirements need to be converted into user stories and prioritized once they are captured. Different type of backlogs could be introduced and help organizing the delivery of the working items. In large scale transformations multiple integrated scenarios spread across various teams and functions, as well as across different timelines in an overall program and these factors should be considered. Each backlog should include those working items which their delivery time is common (same release) and where, end to end, contribute into a working scenario. When items in a backlog have been approved for a certain release, creation of user stories and prioritization of them should take place. A typical user story prioritization approach in Agile is done based on necessity using the MoSCoW method. The purpose of this, is to prioritize user stories over each other by classifying the importance and necessity of each feature for the business users (Must, Should, Could etc.).
Build and Test
Once prioritization has been completed and the various “work packages” have been created and released, it is time for the build phase to initiate. Getting into the implementation details may trigger additional questions for clarifications and a set of new iterations across different background teams and working groups may be required. We have tried to represent this phase with the following diagram:
The representation of the arrows denotes the multiple back and forth that may happen once this phase kicks off until the requirement has taken the architect’s approval and then configured/developed and tested to meet the acceptance criteria.
Again, the outcome of each of these iterations produces or contributes in the creation of a new set of documents named “Functional Specifications” and “Configuration Guides” which reflect the agreement between business and IT and describe in detail the behavior of the final solution. Additionally, the developed/configured items have to be tested throughout different types of tests (unit, integration, validation, user acceptance tests etc.) until they reach the production environment. In validated environments testing information has also to be documented. One can easily understand that throughout the Build and Test phase two additional topics need to be managed:
- The documentation which is generated throughout build and test
- The actual progress of the user requirements build
Documenting User Requirements
Since each user requirement will trigger a system change, documenting such system changes and their purpose is required in every implementation. Teams can, at any time, reference the reason and the decisions taken that triggered a change.
Especially for validated system environments such documentation is a regulatory requirement under ISO standards such as ISO 9001:2015. Managing such documentation requires not only to select the right tool that fits into your organization but also to setup the tool in an appropriate way to reflect the approval steps and documentation lifecycle needed until the development is finalized. (Business, Architect, Functional, Validation approvals etc.)
We have already analyzed our thoughts on the tools that could be chosen in managing the documentation and approval steps of such documents.
Managing the actual delivery work
Another aspect of the requirement’s management is to be able to track the implementation progress, track of the deliverables, the ownership as well as the pending actions until a requirement has been fully developed and accepted. We have deliberately broken the management of the user requirements build lifecycle into two pieces as we believe that user requirements documentation has different needs than the development lifecycle and, so far, there is not a sole management tool that can successfully manage the lifecycle and reporting needs in large scale transformations. More over in Hybrid environments we have noticed a higher number of iterations required and delays caused in the delivery of working items. Such interactions need to be properly managed and provide ease to the teams in focusing on the actual deliverables. Giving the means to your teams to track and report the progress on each working item, as well as handle rapidly any iteration needed within the chain Business-Architect-Functional-Developer will help in increasing delivery performance, bring visibility to the management and help in planning next releases and prioritize backlog items.
What’s next?
A successful user requirements phase sets the right foundations for a successful implementation. Having the skills to recognize and tackle the complexity from the very beginning as well as prepare the IT toolset landscape to face large volume of requirements will set a stable base for your whole program. Do you want to know more? Contact us.
