Best Practices in Handling Uncertainties in Business Requirements in Enterprise Solution Implementations
Experience shows it is impossible to define all business requirements in the initial phase of a packaged software implementation. Some requirements are missed due to schedule pressure or oversight, while others originate later due to changed business realities. How can program sponsors manage changing requirements without impact to budgets and schedules? This article attempts to answer the question based on practices observed in multiple large enterprise system implementations.
Implementations of packaged software aim to deliver solution components for all validated business requirements (See Figure 1) gathered mostly in the initial phases.
Figure 1: Evident and hidden Business Requirements and Solution Components in a packaged software implementation
Business owners - with assistance from process improvement groups and IT members - can specify current and foreseeable new requirements. However, some business requirements still remain unforeseen as they do not exist when the program is in nascent stage. Solution components, on the other hand, can take the form of non-system solutions (business process changes and user orientation), or system solutions (use of standard packaged software features and budgeted development resulting in package extensions). Some package extensions remain unseen (and hence unbudgeted) in the initial stage.
The implementation team focuses on the cells shaded solidly in Figure 1. These cells represent known and foreseen requirements, and budgeted solution components that deliver these requirements. Cells not shaded in Figure 1 represent sources of uncertainty in the implementation.
Figure 2: Sources of uncertainty in a packaged software implementation
As shown in Figure 2, this uncertainty has three themes: Requirement Coverage, Solution Scalability, and Solution Extensibility. Requirement Coverage represents the uncertainty due to requirements that should have been captured in the initial pass but are were missed due to oversight, schedule pressures, or inadequate business involvement. These requirements surface later in the implementation (usually during System Testing - or worse - during User Testing). Implementation teams rely on business members to minimize this source of uncertainty. Solution Scalability represents the uncertainty related to how well can the budgeted solution components address the unforeseen business requirements without additional development. Such requirements arise unannounced from unforeseen business process changes during the implementation. Only mature implementation teams design solutions with the foresight to handle this source of uncertainty. Solution Extensibility represents the uncertainty due to the unbudgeted changes needed in the solution to handle unforeseen business requirements. This is a blind spot for most implementation teams.
The following strategies have been found useful in minimizing the impact of these uncertainties on the quality, cost, schedule, and scope of an implementation:
Uncertainty |
Strategies to reduce the impact of the uncertainty |
Requirement Coverage |
Make first-pass requirement gathering a foolproof process
Enforce early and continuous user involvement for smooth course corrections
|
Solution Scalability |
Develop “Solution Platforms”, and not just “Solutions”
Enforce a standards-based architecture
|
Solution Extensibility |
Define clear governance guidelines around solution changes
Expand the review net to capture unforeseen requirements and capabilities
|
Handling these three uncertainties demands different leadership skills. Business leaders can effectively lead the effort of ensuring “Requirement Coverage”, Functional and Technical Solution Architects can lead the effort of ensuring “Solution Scalability”, and the Program Management Office – with inputs from business leaders and solution architects - can ensure “Solution Extensibility”. This guideline can be customized based on how the program is organized.
