12 Risk Management Considerations to Measure WRICEF-A

Do You Know What WRICEF-A Means?

WRICEF-A Objects or Workflows, Reports, Interfaces, Conversions, Enhancements, Forms and Authorizations, is a common term you might run across on any SAP project. 

For some, this is a roll your eyes back in your head term.

If you are the SAP project manager, or the technical project manager working for the SAP Project Manager, you are going to be faced with a considerable number of items that fall within the world of this little acronym. 

There are templates available to define each of these items and we can provide them to you if you don’t have access to them.  The mechanics of defining, developing, and deploying these WRICEF-A items are well known.  What is more relevant to the SAP Project Manager are the risks to the project go-live.

Project Risk Management is an Art and Science

What are the WRICEF-A Risks to Consider?

1. Are the conversion requirements stable?
   
   In other words, has more work been done than simply establishing that some conversions will be required.  A Key Performance Indicator is whether or not you have sign-off Functional Specification documents for each requirement.
   
   
2. Are the enhancement requirements stable?
   
   What I tend to see here is a disagreement on both what the enhancement should do and whether it is really essential at this time and given this budget.  Successful Project Performance Management comes down to finessing these sometimes political sensitive requirements.
   
   
3. Are there interfaces to third party legacy systems?
   
   Are the interface requirements stable?
   
   Are the companies still stable and in business?
   
   Are the companies direct SAP competitors?
   
   The red flag here is (in my experience) that if there has been a long, expensive, hard fought win by SAP and one of its main, say database providers that also sells ERP software, it might not be unheard of for the database provider to come up with reasons why the required interface is not legal under the terms of the license. 
   
   
4. Are the report requirements stable?
   
   If there have been frequent management changes, you can expect that the business reporting requirements are in flux.
   
   
5. Are the authorization requirements stable?
   
   Have you completed the major subproject within every SAP Project to define the User Roles and Authorizations?
   
   
6. Are there concerns about CEIRA (Conversions, Enhancements, Interfaces, Reports, Authorizations) “scope creep” during the project?
   
   Is there a formal change control process?
   
   If there isn’t concern, there should be.
   
   
7. Is there any “To Be Determined” work?
   
   (Conversions, Enhancements, Interfaces, Reports, Authorizations)
   
   This is a landmine situation for which you will certainly end up hearing the click of the trigger on the top of the mine. 
   
   
8. Are there any CEIRA requirements you know should be included but are not?
   
   Will you be able to get these into the project requirements?
   
   Where might you encounter this? 
   
   There are many situations but one in particular to be aware of is when there has been a major restart in the project. 
   
   This means, perhaps, the project was abandoned and is now a do over (did you know according to a recent study, 94% of all projects are restarted at least once), or perhaps, there has been a major swap out of resources.  These resources may have a completely different cost profile than the ones originally planned for.
   
   This one item is probably the single biggest cause of grief I have encountered when running projects. 
   
   Sometimes, a new boss makes a strategic decision to increase scope due to business reasons, and you certainly have unknown requirements in this situation.
   
   For example, our Enterprise Performance Consulting practice often uncover 'hidden' strategy opportunities buried within the EPM data warehouse, which drives a a need to change.  
   
   
9. Does the customer have any unwritten CEIRA requirements/expectations?
   
   Is there a way to capture these requirements?
   
   As an example of this situation, was recently on a project where the client provided expensive equipment to the government. 
   
   The buyers had a tendency to have a lot of ‘oh by the ways’ while you here, which meant you were doing work that was known but never documented prior to the contract being signed. 
   
   
10. Are there any “state-of-the-art” requirements?
    
    Does the project have sufficient knowledge in these areas?
    
    Is there a plan for acquiring knowledge in these areas?
    
    I refer to these as science fair projects. 
    
    Though not avoidable, it may frequently be the case that in order to do the deal, commitments must have been made to deliver functionality that will have to be invented. 
    
    My experience has been that these type of projects tend to be, er, challenging.
    
    
11. Are you able to understand the CEIRA requirements?
    
    Are the ambiguities being resolved satisfactorily?
    
    What has to be avoided here is a failure to communicate. 
    
    There are many proven ways to develop clear functional requirements. 
    
    The downside is that to get to clear requirements may require more money than budgeted for.

If you are unsure of your current project's risk profile, or would like some advice on identifying and mitigating risk, we can help. 

People who read this also read:

Learn to Specify WRICEF Functional Specifications

Specify WRICEF Objects From a Functional Perspective

Track Your WRICEF Items and Control Development Cost

Manage Risk Using our Risk Management Guide

10 Steps to Manage SAP Project Sub-Contractor Risk

Thanks