5 mistakes to avoid when developing a SOW with Accenture, Deloitte, and IBM

Most of you have heard the phrase that 90% of the manufacturing cost of a product is determined during product design.  The same can be said about the program execution risk profile of IT-enabled transformations. The master statement of work (MSOW) established at the beginning of the program locks in 90% of the risk profile of the project. The system integrators have a full appreciation of the execution risks, while their clients tend to be newer to the game. Does it surprise anyone that system integrators are able to mitigate 90% of their own risk in the development of the SOW while their clients, more often than not, are unaware of the risks and issues they will encounter?

Unfortunately, in a world where projects can run off the rails and actually destroy value, a vague, high-level SOW simply isn’t going to cut it.  And even in the best-case scenario, where your project delivers the expected benefits both on-time and on-budget, it’s going to take more than a handshake to get you there.  Why?  Because as your project progresses, things are going to change:

• You are going to learn things about your business you didn’t know before
• You are going to realize that some of the things you thought you knew…you actually didn’t
• Business imperatives can shift mid-stream due to changing competitive and economic conditions

UpperEdge has identified over 30 specific risk points that companies need to be aware of and take pro-active measures to address during the construction of the MSOW. Here are five of these common missteps:

1.  Not recognizing the legacy environment as a source of risk to program execution

Most companies see the current legacy environment as a risk to growth and operational efficiency. What they fail to realize is these same legacy systems provide a significant source of risk to the successful execution of the program. Issues associated with the quality of data, the condition and availability of test environments and the scarcity of knowledgeable resources often surface during the execution of the program.   Early evaluation of the potential risks and treatment minimize the probability of program delays or the need to bring in integrator resources to backfill for program talent that needs to be pulled off to correctly resolve the legacy issues.

2.  Failure to pressure-test the documented governance & decision model

Transformation programs are the proverbial fire hoses of issues and decision requirements. Often times companies are ill-prepared for the volume and urgency with which decisions need to be made.   To mitigate this risk, program leaders need to pressure test the governance structure by validating that the steering committees will have the availability to engage and sign-off on the significant decisions, and that project team leaders have the authority and autonomy to make most of the required decisions.

3.  Not treating end users as a constrained resource

User activities are typically back-end loaded on these programs.  From training, testing, data cleaning, and deployment planning, end users are overloaded with the volume of work and ill-prepared to deal with the pressure of a go-live. Programs can end up taking delays as the user overload is sorted out, or worse, tasks are shortcut and the business can end up in shambles with a poorly executed go-live. Companies are advised to map out the end user demand profile and adjust the program schedule to compensate for this constrained resource.

4.  Ceding program status reporting to the system integrator

From my perspective, 80% of the value of developing a status report goes to the creator.  Is it any wonder the system integrator wants to maintain control and take the “drudgery” of creating the report off their client?  The glitz and sizzle included in these documents can often be seducing to your executives, leading them to believe that the program is well managed, even though the program is crumbling.  Those who delegate status reporting to the consultants are also potentially allocating future leverage as the ability to shift providers becomes less of a possibility.  Companies need to retain the responsibility for generating status reports and focus on clearly documenting PMO (Program Management Office) metric reporting responsibilities.  

5.  Placing program cost and schedule risk as a priority over operational continuity

The majority of early program measures are focused on measuring the progress toward configuration of the system and the completion of the development activities. Measures on data quality, user readiness, and operational control do not typically appear until the second half of the program. Companies need to incorporate into the SOW equal focus on these measures early into the program. This allows for a balance of priorities and the proper allocation of resources to these activities throughout the life of the program rather than attempting some herculean effort to secure these measures at the end of the program.

These are just five of over 30 risk points to address in the construction of the MSOW.  I advise you to consider all program risk points prior to signing off on the MSOW rather than waiting until after the signing of the MSOW to conduct the first risk assessment.