Infosys’ blog on industry solutions, trends, business process transformation and global implementation in Oracle.

« Oracle's MTO Solution for Process Industries | Main | An Introduction to Oracle Manufacturing Operations Center (MOC) »

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

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


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

  • Involve the right levels of business users in requirement gathering. Ensure representation from right geographies, roles, departments, and product/service segments. Involve senior business managers (VPs/Directors) in reviewing the requirements and signing them off.
  • Validate against previously created requirement inventories to ensure requirements are not missed. Such inventories can come from older business or IT assessments, business cases, package evaluation exercises, and industry best practice literature.
  • Make sure the requirements tie to the to-be process flows. Tying each requirement to a step in the to-be process flow sometimes unearths many missed requirements.
  • Validate against the business functionalities provided by the current legacy system. Focus on functionalities required in the to-be system and check if all have been captured as business requirements.
  • Conduct detailed Conference Room Pilots (CRPs) to validate the first-pass requirements.

 Enforce early and continuous user involvement for smooth course corrections

  • Involve business users early in the solution testing process. Let business own the task of test script preparation to ensure the system design has voice-of-customer embedded. Involve newer business members (different from the ones involved in requirement gathering) early in testing for an unbiased assessment of the solution.
  • Conduct testing with a consistent data set that represents real business data. Use such data sets to conduct testing for all business process flows and variants from start to finish.
  • Pilot training materials early with real business users


Solution Scalability



 Develop “Solution Platforms”, and not just “Solutions”

  • Design first for “Foundational Processes” and then for “Variants” within each foundational process. Adopt a Solution Platform approach adopted in other industries where solutions for individual variants can be enabled by configurable setups and options built over a core Solution Platform that addresses the foundational process. Continuously improve on the solution platforms based on experience.
  • Avoid monolithic design. Keep the design modular by dividing the solution into pieces that can be loosely coupled to address a process variant, as needed. Build design redundancies based on implementation experience. Design data structures with the capability to handle multiple scenarios of the same data.
  • Design reporting platforms with ad-hoc reporting capability for end users.

 Enforce a standards-based architecture

  • Centrally coordinate the solution design process. Embed approvals for detours from established design standards.
  • Enforce open integration architecture with plug-and-play components and common input and output data formats. Use industry standards (if available) for integration design and data mapping.
  • Define uniform data cleansing, enrichment, and data stewardship rules. Define clear standards for master and slave systems for master data.
  • Evaluate compatible hosted software for specialized process steps that need not be kept in-house (for example, tax calculation, export control validation, and background checks during recruitment).


Solution Extensibility



 Define clear governance guidelines around solution changes

  • Lay down clear guidelines for developing a business case for new requirements that demand changes to the budgeted solution. Get senior business and IT leaders involved in evaluating business cases above defined cost and schedule thresholds. Define rules to decide how the validated solution changes will be funded.
  • Prioritize and schedule validated solution changes so that they do not impact the running projects.

 Expand the review net to capture unforeseen requirements and capabilities

  • Monitor business initiatives to catch unforeseen requirements. While reviewing requirements, involve stakeholders in charge of areas from where the unforeseen requirements might come. Some examples of such stakeholders are: business owners responsible for establishing a new plant and business leaders from sites where the solution will be rolled out next.
  • Monitor upcoming package upgrades for new features that can be useful.


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.

Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.

Subscribe to this blog's feed

Follow us on

Blogger Profiles