A new ERP system is the platform on which a company will shape its business for the next seven to ten years. It’s a substantial investment for any company but also the opportunity to really innovate. The project team has a responsibility to look ahead, to dream and to push boundaries. They must design and deliver the best possible platform to enable enhanced competitiveness and true business agility across the enterprise.
So it’s not merely a software implementation. It’s a future-defining journey.
The first practical step is to elicit, understand and manage business-critical requirements that will drive the initiative. But project leaders often delegate this crucial responsibility to software specialists. The fundamental risk of this approach is a final solution that the software specialists are proud of but:
- does not serve the business purpose that necessitated the project in the first place; and
- diminishes the opportunity for innovation.
The Dangers of Casual Requirements Management
Allowing software specialists to drive the business requirements process is dangerous because:
- Software specialists typically think in terms of previous successful projects and steer the requirements conversation in that direction. The result is a cloned system that offers no real competitive advantage.
- Software specialists typically consider ERP system requirements only. However, the ERP system does not live in isolation inside an organisation. Broader business requirements may demand implementing systems or processes outside the core ERP system.
- Software specialists like ERP, CRM or BI consultants all work within defined systems and constraints that reflect their respective areas of expertise. Requirements planning and management transcends these limitations to embrace a higher level of enterprise existence. Anything less jeopardises the corporate mission.
- Software specialists focus on system implementation. But business requirements management and traceability extend past go-live. At any future time, features and functionality must be readily traceable back to their original requirements to facilitate their review.
- Software specialists don’t consider soft requirements and dependencies, such as user mindset, effective communication, or stakeholder management and inclusion. When business users feel left out, adoption of the system falters and change management is ineffective.
Software specialists are not challenged to innovate, find solutions for the business requirements, or investigate business ideas that they haven’t come across in previous projects. Without the business pushing the boundaries with pure, non-system-based requirements, there can be no innovation.
An anecdote from Apple perfectly describes the innovation challenge when left only to engineers.
Why Steve Jobs drowned the first iPod prototype
When engineers working on the first iPod completed the prototype, they presented it to Steve Jobs for his approval. Jobs played with the device, scrutinized it, weighed it in his hands, and promptly rejected it. It was too big.
The engineers explained that they had to reinvent inventing to create the iPod, and that it was simply impossible to make it any smaller. Jobs was quiet for a moment. Finally, he stood up, walked over to an aquarium, and dropped the iPod in the tank. After it touched bottom, bubbles floated to the surface.
“Those are air bubbles,” he snapped. “That means there’s space in there. Make it smaller.”
In conclusion, not managing business requirements professionally results in a project that risks failing to take the business forward. The project also risks not attaining true investment status and the company may not experience real enhanced competitiveness.
The Onpro Requirements Management Service
The Onpro Requirements Management Service is based on the Business Analysis Body of Knowledge (BABOK) which is developed and published by the International Institute of Business Analysis (IIBA). Version 3.0 of this guide is available from http://www.iiba.org/.
The Requirements Life Cycle Management knowledge area includes the following tasks:
- Trace Requirements: Analyze and maintain the relationships between requirements, designs, solution components, and other work products for impact analysis, coverage and allocation. Requirements traceability identifies and documents the lineage of each requirement, including its backward traceability, forward traceability, and relationship to other requirements. Traceability helps ensure that the solution conforms to requirements and assists in scope, change, risk, time, cost and communication management. It is also used to detect missing functionality or to identify if there is implemented functionality that is not supported by any requirement.Traceability enables:
- faster and simpler impact analysis,
- more reliable discovery of inconsistencies and gaps in requirements,
- deeper insights into the scope and complexity of a change, and
- reliable assessment of which requirements have been addressed and which have not.
- Maintain Requirements: Ensure that requirements and designs are accurate and current throughout the system life cycle, and facilitate reuse where appropriate. A requirement that represents an ongoing need must be maintained to ensure that it remains valid over time. To maximize the benefits of maintaining and reusing requirements, they should be:
- consistently represented,
- reviewed and approved for maintenance using a standardized process that defines proper access rights and ensures quality, and
- easily accessible and understandable
- Prioritize Requirements: Assess the value, urgency, and risks associated with particular requirements and designs to ensure that analysis and/or delivery work is done on the most important ones at any given time.
Prioritization is the act of ranking requirements to determine their relative importance to stakeholders. When a requirement is prioritized, it is given greater or lesser priority. Priority can refer to the relative value of a requirement, or to the sequence in which it will be implemented. Prioritization is an ongoing process, with priorities changing as the context changes. Inter-dependencies between requirements are identified and may be used as the basis for prioritization. Prioritization is a critical exercise that seeks to ensure maximum value is achieved.
- Assess Requirements Changes: Evaluate new and changing stakeholder requirements to determine if they need to be acted on within the scope of a change.
The Assess Requirements Changes task is performed as new needs or possible solutions are identified. These may or may not align to the change strategy and/or solution scope. Assessment must be performed to determine whether a proposed change will increase the value of the solution, and if so, what action should be taken. Business analysts assess the potential effect of the change to the solution’s value, and whether proposed changes introduce conflicts with other requirements or increase the level of risk. Business analysts also ensure each proposed change can be traced back to a need. When assessing changes, business analysts consider if each proposed change:
- aligns with the overall strategy,
- affects value delivered to the business or stakeholder groups,
- impacts the time or resources required to deliver the value, and
- alters any risks, opportunities, or constraints associated with the overall initiative.
The results of the assessment must support the decision making and change control approaches of the overall project.
- Approve Requirements: Work with stakeholders involved in the governance process to reach approval and agreement on requirements and designs.
Business analysts ensure clear communication of requirements, designs, and other business analysis information to the key stakeholders responsible for their approval. Approval of requirements and designs may be formal or informal. Predictive approaches typically perform approvals at the end of the phase or during planned change control meetings. Adaptive approaches typically approve requirements only when construction and implementation of a solution meeting the requirements can begin. Business analysts work with key stakeholders to gain consensus on new and changed requirements, communicate the outcome of discussions, and track and manage the approval.
Getting Requirements Right
As you can see, managing requirements is a complex process that operates at a strategic level far removed from the implementation effort. It demands a top-down understanding of business and a keen insight into the interplay between operational processes. Software specialists are generally bound to specific areas of expertise and do not possess the appropriate skills to manage requirements thoroughly.
Onpro Consulting offers the Onpro Requirements Management Service, a comprehensive framework that ensures your requirements are correctly elicited, planned, tracked, managed and maintained. The process delivers the highest possible business value regardless of the ERP system or enterprise software you employ.