ERP implementations are complex projects that demand time, energy, and resources from an organization. When company leaders decide to embark on a project of such magnitude, they have a few things in mind: do it one time, do it on time, do it within budget, and do it right! One of the critical components of making sure the project is done on time and within budget is knowing what needs to be supported by the new system—critical business requirements.
Most project teams assume they can gather critical business requirements during the design phase. Like the gift that keeps on giving, new requirements will be identified later in the project. Business needs change and new ideas are generated during prototyping. Ignoring the new requirements or suggesting anything identified after design should be pushed to a different phase would be a big mistake. Pushing the newly identified requirements to a future phase could result in a system improperly configured to support the business at go-live.
It seems counterintuitive to allow new requirements to be identified and addressed throughout the project. Successful project teams need to address new requirements throughout the implementation.
Initial business requirements should be gathered and documented during the ERP selection process. The critical requirements will be supplemented during the design phase. Successful project teams leverage consultants like Trenegy to create a future state process improvement vision, design future state processes, and draft critical, industry-specific requirements. The requirements should be refined in a series of workshops and validated against best or usual practices. Successful project teams will assume new ideas and concepts will be developed as soon as key end users gain access to the new system.
Traditional ERP methodologies assume that key business requirements will be determined in design and suggest anything identified after should be delayed until a future phase. The reality is very different. Successful project managers will get key end users exposed to the new system as quickly as possible. This allows key end users to see how the new system and processes will affect day-to-day activities and spur new ideas, which will result in new requirements. Strong project teams should manage the addition of new requirements with consistent requirement documentation and solid project governance guidelines.
After the system goes into effect, stakeholders across the company will grow comfortable with functionality and new processes. With this increased usage comes discovery of additional requirements for the system. Do not dismantle the project team directly following go-live. It’s crucial the team stays intact after the project, at least to some degree, to capture and address these requirements. The post go-live support model should be structured with issue resolution and requirement gathering in mind. Requirements discovered after go-live may be quick fixes, or they could be issues added to a master list for a future project.
It's rare that all critical business requirements can be identified at the beginning of the project. Team members will identify requirements throughout the project as the system and processes are tested. The project team needs to be ready to capture business requirements throughout the project.
Trenegy helps companies manage ERP implementations and leads project teams to take the right approach to gathering business requirements.
Trenegy is a non-traditional consulting firm based in Houston, Texas.