Requirements management tools can be generally categorized into three categories based on their intended purpose:

– Product Requirements

– Software Requirements

– Enterprise Project Requirements

At first glance, these may appear similar, but in actuality they differ significantly. Product requirements must be carefully defined and then handed off to engineering and design. Once manufacturing and distribution begins and products have been shipped, changes in requirements are a moot point.  For software, new requirements and changes to existing requirements are included in software updates. Software can be upgraded frequently overtime, while products often cannot.  This fundamental difference often makes requirement elicitation, development, and management techniques very different depending if software or a product is being developed.

Enterprise projects are a totally different thing. For example, for many enterprise projects we don’t build software, we buy it.  Let’s examine what is different about requirements for enterprise projects.

Intricately Tied to Underlying Business Processes

Enterprise projects usually involve and require fundamental changes to a business process, which the new or changed system must support.  Extreme care must be exercised to ensure that the requirements are defined for the optimized “To Be” process, not the problematic “As Is” process.  Since changes to business processes can be a moving target, this can wreak havoc on the requirements definition process.  It is important to keep in mind that defining system requirements for a poorly designed or flawed business process is a waste of time and money.

Software Development May Not be Required

The solution for many enterprise projects is to use commercial off the shelf software (COTS), such as an ERP or CRM system. Requirements are needed to ensure that the correct product is acquired and then that the implementation and configuration is appropriate. Requirements for COTS implementations are very different than those needed to custom develop software.

Number and Location of Stakeholders

Enterprise projects generally have substantially more stakeholders than traditional product or software projects. Often an enterprise project spans multiple divisions and business units; compliance, internal audit, finance, and HR are also stakeholders involved on an enterprise project.  Not involving the entire span of impacted stakeholders upfront can result in a solution that does not address their needs and can create significant organizational resistance when it is time to deploy the solution.

System Interfaces and Data Integration

To implement a solution in an enterprise setting often requires interfaces or changes to existing systems. These requirements for changes to existing systems must also be specified. Separate teams usually perform these system and data integration changes. For example, if an organization was going to acquire a CRM system, they may want an interface to the organization’s ERP system.  Within an enterprise, a simple interface such as this might require the work of three teams: the CRM Team, the ERP Team, and a middleware team. System interfaces and data integration always add complexity to interface projects. There is no longer just a single development team like there is for traditional software projects.

Multiple Types of Users

Products often only have one user or user class.  Look at a cell phone or vacuum cleaner, for example. Alternatively, users of enterprise solutions are much more varied and complex, For example, the following may be users of an enterprise solutions:  executives, mangers, data entry clerks, and knowledge workers. Each of these user classes have very distinct needs.  In addition, you may have outside suppliers and customers who also interact with the system.

Transition Requirements are a Must

For enterprise projects, it is not only important to define requirements for the solution, transition requirements must also be defined to address how the solution will be deployed. Transition requirements include such as things as:

• Data migration and conversions
• Training
• User buy-in and support
• Changes to policies and procedures
• Changes in roles and responsibilities
• Infrastructure (network, servers, and storage) to support the solution
• Organization and compensation changes

Organizational Change Issues

Many enterprise projects fail because the user community fails to accept the solution.  Defining organizational change requirements and preparing users to take advantage of the improved system and processes should be a standard part of all enterprise projects.

Conclusion

Clearly, requirements development and management for enterprise projects is significantly more complex than defining software or product requirements.  Suggestions for selecting the right tool to define requirements for Enterprise Projects include, among others:

• Do not use a word processor or spreadsheet to mange enterprise project requirements. These tools were not designed or developed to manage requirements through iterations and the complete system development lifecycle.  Trying to do version control of multiple word documents to be shared among many stakeholders is a sure recipe for failure.
• Chose a tool, such as the Enfocus Requirement Suite™, that is specifically designed for enterprise projects.
• Verify that the tool can accommodate both solution and transition requirements.
• Ensure that the tool supports collaboration to enable stakeholders located in multiple places throughout the world to work together in defining the requirements.
• Stakeholders should be able to use the tool to manage and support (e.g. clarify and add details) the requirements throughout the project lifecycle.

[cta id=”7443″]