SAP Governance Processes

[Former Member]

Governance Process

I have found that the structure and execution of a governance process is as critical to the success of a program as the positions and the tools that are used.  All organizations are political by definition and whether a company's politics are benign or Machiavellian, there are decisions that must be made while designing and implementing change that need to be properly and respectfully managed or they will derail the best of intentions.  The existence and organization of the governance process is critical to project preparation and execution, however, I have found that most of these processes are "built to formula" and around PMP principles, rather than being built to manage decision-making in a highly complex organization, which all cross-functional organizations are.  Don't get me wrong, PMP skills are critical and the governance structure is in accordance with these requirements, but the difference is in how "alive" the management process is to drive decision-making and Organizational Change Management.  In a future blog article I am going to discuss Leadership as it pertains to this process and relate it back to how the governance process is designed to fit with leadership styles.

The governance process I have designed and used successfully involves 3 distinct functions with clear relationships, authority and responsibility to each other and the overall project.  None of these are new, none have not been used in some form on most projects, however, I will argue that the rules applied here as a set are designed to work through the political processes that affect every program/project.  I will discuss each and how they are executed and then am going to use this organization in future blog articles on "Tales from the Front Lines", to demonstrate how this governance organization is used to deal with some very serious issues to all projects.  Even on very small projects, even if fully invested in one person, these functions still are important.  The three functions are": Executive Steering Committee, Program Governance Office and Project Office. 

1.  Executive Steering Committee

This standing committee must be led by the most senior client business leader responsible for the areas affected.  Typically this can be the COO or equivalent for an enterprise-wide program (or if the scope is more limited, to the senior officer responsible for the areas being affected), and the committee must include all senior executive stakeholders, which means that for each function affected the most senior leader in that group must be on the committee.  Many times, in order to avoid direct decision-making at this executive level, senior leaders will delegate this assignment down in their organization, however, if used properly, this committee can be used to enhance the visibility and control by senior leaders without threatening the political environment.  In any event, the top leader in each function must be engaged as a committee member and, equally importantly, must actually attend the meetings.  This will happen when the Committee chair makes the commitment to personally attend him or herself and sets the expectations for the rest of the leaders. I have found that the aversion to this by senior leaders is due to the tendency for this group to be used by subordinates to engage in highly political decisions, however this is not how this group should function and cannot be allowed to happen.  I will talk more specifically about this in a future "Tales" article. 

Unfortunately, it is not unusual for the executive leadership to treat this like an IT project and delegate all of the control to the CIO/VP-IT, which may satisfy the need for executive control, but avoids the real mechanism for achieving ROI - Organizational Change Management across the enterprise.  Delegated to IT, the ability to drive decision making on business process design, as well as the management of the process during the project encounters roadblocks at every turn.  In the early days, IT was a highly technical and little understood function that was mysterious, however, this is cannot be allowed to continue to be the case.  How IT is used to define business processes and produce business benefits has to become a component of the education and knowledge of all senior leaders and part of the never-ending personal development process.   

2.  Program Governance Office

This group is co-led by the senior executive who is responsible to the ESC for the successful execution of the program along with the senior consulting leader(s) responsible for delivery.  In a typical program this will be the CIO of the affected organization (by role if not title), and may include one of his/her staff members who have specific expertise in the software being implemented.  If the consulting role is split between system integrators, then senior representatives of each needs to be in this function.  The role of this group is to maintain a day to day oversight of the project and become involved in defining, discussing and driving decisions on the critical process design issues that must be made.  Typically this group meets formally once a week when all of the project metrics are produced and explained by the project managers.  This provides an opportunity and platform to focus on such metrics as progress against the critical path, review of both the issues and the decision logs and to either push to ensure that these are in sync with each other, or elect to become engaged in resolving roadblocks.  Other activities of this group are to discuss proposed Change Orders to determine if the change is required and therefore must be approved by the ESC or whether another approach will allow the program to stay in scope and/or on time, both of which obviously affect cost.  The ultimate responsibility to maintain the scope of the program, both to include prevention of scope creep and to avoid shortfalls is with this group.  All members of the Program Office must also be available on a daily basis to deal with unexpected issues as they occur or to deal with inability to finalize decisions that affect the critical path, or the costs that are incurred. 

In most projects that encounter design and resistance issues, it is my belief that this one of the two governance functions that either doesn't exist or is not used to keep the project moving forward on the critical path, the other being the commitment and involvement of senior leadership.  Keeping the focus on these programs is never easy and requires commitment and attention on the key critical path challenges and this function is designed to see that it happens.

3.  Project Office

This is the day to day operational hub of the project.  It includes the Project Manager(s) responsible for the overall project, the project manager responsible for the internal recording, tracking and reporting of program metrics and may include key other stakeholders like the person responsible for Organizational Change Management.  Typically a project will be divided into several functional teams, and depending upon size, may have several leaders who must work together, or may be small enough that many responsibilities are combined in one person.  Either way, there are team leaders, which may be as simple as a consultant and an empowered business representative or may be many times that size. 

The project office will include a Functional Project Manager who will typically be from the Systems Integrator, and a technical/business project manager who will be responsible for all of the support functions, such as RICEF, Organizational Change Management, Training and the gathering and reporting on all project metrics, and the client project manager who takes daily direction from the CIO  (or similar) and has direct access when necessary to the ESC chairperson.  In the case of large projects, there should be a Project Office Manager who has daily responsibility for expenditures, project logistics and all reporting against work plans and the critical path.  This person is not in charge of the project but supports the project office and is the eyes and ears of the Program Governance Office to stay on top of issues and project flows as they occur.  Obviously on smaller projects this is incorporated into a single person.  The issue really becomes, however, if your key project leaders spend all day buried in spreadsheets and metrics, who is left to work on resolving cross-functional design issues between departments.  Both are critical to the success of the project, however, may be conflictual when invested in one person - again, obviously depending upon project size.

Conclusions 

As I have indicated, it is possible, depending upon the size and complexity of the program/project that some of these functions can be performed by one person, or, on larger projects, there may be large staffs supporting each one.  The size, however, is important only to the extent that the governance process is scaled to be appropriate to the program.  Appropriateness is determined by how effectively the process can be used by leadership to manage the political environment and work organization to accomplish the goals.  If you look back at any successful project from the past, I believe you will see that each of these functions have been addressed, some formally and some perhaps by one very visible leader.  In my personal experience, on a small project all 11 members of the corporate office staff were part time on the project team.  All of the responsibilities of the Program and Project offices fell on me as the consulting program leader, and on the client project manager.  Unlike conventional wisdom as it pertains to smaller organizations being easier to work with, however, the key success factor on this program was Organizational Change Management as each of the key staff had designed the current business process and were emotionally committed to their designs.  Actual configuration, demo and testing of the solutions was simplified as it was done in two and three person teams.  Finally, data conversions were done manually and "as required" after go live - not a desirable situation but in this case it worked well.  The point here is that on very small projects the same issues and problems arise and the same organizational and personal dynamics must be managed.

On a larger implementation ($35M fixed price, full suite in 19 months), the full governance process described above was in place and proved capable of keeping the program on track to successful completion.  In that case, the overall project team numbered close to 100, but the process was the same, just larger and involving more people.

One additional aspect that will be discussed later, is that this model applies also to steady-state continuous improvement programs.  In this case, the goal is to flatten the investment curve, engage in smaller, less complex projects, but to be working on something continuously, and most importantly have all or most be based upon achieving an ROI that is real and realized.  As with the large project, this has to be scaled to match reality. 

Educational Requirements

Let's think for a couple of minutes of the skills that were required to be successful in the latter case.  Obviously highly trained consultants who could develop technical configurations to produce business processes as they were designed.  Also an empowered and trained client project team.  We had written into the contract that the entire team would start together going through a three day hands-on overview course produced on site, which provided the cross functional concepts to the entire team that they used to produce design decisions in a timely fashion.  Today, this could better be served by taking the entire team through a two week boot camp on TERP  10, business process certification.  In addition, an on-going SAP education program was designed to provide each key client user (eventually power users) knowledge of the functions they were going to support, along with the use of a training development tool to provide the documentation (RWD in this case, but there are others).  The project office had extensive project management knowledge with several PMP certified managers, OCM was led by a very senior practitioner, Training by professional training developers, the Supply Chain Management and Production Planning areas by workers with APICS certifications, etc.  If it had been available, MBA level courses to provide the business management context for the entire program would have been helpful and today there are graduate level courses taught several places up to and including the SAP Graduate Certificate program at Central Michigan University.  All of these add up to a corporate commitment to continuous learning across functions and skills.  As you develop programs, this needs to be considered both on the client side, but also in the consultants who help analyze, design and implement the solutions.  When continuous learning stops, typically so does progress - as we learn to deal with the complex relationship between business and IT this becomes even more important.