Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

The Tale of Hiding Spending Authority

Process knowledge, and more accurately knowledge of how business processes are designed, evaluated and implemented, is a necessary set of competencies for any business to operate successfully.  This is an even more critical skill set when undertaking the design or implementation, as well as the continuous improvement of the performance of, any comprehensive Enterprise IT Platform.  In the days when legacy systems predominated, differences between components of cross-functional business processes could be managed by creating interfaces between differing functional systems.  In this way, cross-functional issues were addressed in periodic updates that typically left a lot to be desired.  While this was not an optimal way to operate a business (since there would always be different versions of the truth), it somewhat served the need for applications to keep the business operating before the advent of integrated ERP systems.  However, functional departments would often operate to optimize their departmental objectives to the detriment of overall corporate needs.  With the introduction of ERP systems, and specifically SAP, this changed and as a result challenged businesses implementing the new systems to figure out how to address cross-functional issues and focus on corporate objectives rather than departmental goals.  It created new issues for organizational change managers to deal with and I will talk more specifically about the OCM function in future articles, but here we will talk about how to control these decision points and keep the program on time and budget.  

Many marketing programs have tried to make this sound easy, but it has certainly proved to be anything but.  There are myriad horror stories of large cost over-runs, missed implementation schedules, poorly functioning new systems and other catastrophes that have dominated the literature on this.  We have typically addressed the issues with cliches and hysteria around failures that focus on the software, the consultants, perhaps even "fate", however, identifying lack of education and organizational competencies, which could be addressed throughout the program, has rarely been done.  Taking a blindsided view of the governance process prevents an organization from addressing a critical need during any major transformation. 

Failures are often preventable when a workforce is educated to understand and address the issues, governance processes are sufficiently robust and in place to manage the change processes, and company politics are kept in check by executive leadership.  All of this requires a new level of awareness of where the deficiencies exist.  In this series of articles, I have addressed a number of issues that arise on virtually all ERP implementation programs, to analyze how and why they occur, and to discuss ways in which an organization can address them, in order to improve the results.  To accomplish this, many issues must be dealt with and this Tale describes another one of the most pervasive and difficult ones to keep under control.  I call it the Tale of Hiding Spending Authority and will talk about these elements:

1.  The Tale of Hiding Spending Authority

2.  How three-tiered governance is designed to help control this issue.

3.  Understanding the political environment

4.  The elements of workforce education that can help alleviate problems

The Tale of Hiding Spending Authority

As any significant project is planned, one of the most critical requirements is to analyze dependencies between planning elements to establish the critical path, meaning the elements that must be completed on a certain date and in a certain sequence to allow the project to stay on it's intended timeline.  Another requirement is to calculate the burn rate for each time segment.  By burn rate, I am referring to the amount of money being spent or committed per week or day that the project continues.  This Tale is a real life example of how knowing these facts can work with an effective governance process to keep a program on track.  

I was engaged in a fast track project, building a green-fields, grass-roots specialty chemical plant expected to cost $250 Million (in 2010 dollars) over a period of 17 months from inception to go-live.  The plant project included breaking ground on a 780 acre plot without roads, utilities or any other previous use except as a hunting camp.  We were also to build a utilities corridor that would be sufficient for several other plants to be constructed subsequently.  In addition to the designing and commissioning of the manufacturing process lines, there were roads to be built, buildings to be constructed, large equipment to be manufactured by a variety of vendors, utilities to be installed and many more critical milestones to be met in order to bring this plant on-line.  In other words, our project had complexity and uncertainty just like any ERP implementation.  The timeline was not at all subjective as maintaining our position in the market was dependent upon the success of the project.  This is an important point - any critical project that has a firm timeline must have a compelling case for why it has to stay on the timeline, other than something arbitrary - and it must be believable. 

As the project proceeded, the critical path was used to drive decisions from equipment and vendor selection to construction sequence, with more than 1000 people working on the program once construction started.  My role in the project was design engineer and ultimately manager of the first operating unit being constructed.  In that role, I worked for two Directors who in turn worked for the SVP, Manufacturing - one had engineering responsibility and the other process design.  A critical decision had to be made by a plan date on the calendar, the analysis had been done between two options and the two directors were in disagreement both on the selection, as well as on a process to get to this decision.  A meeting was convened on the date that the decision was required so that the systems could be put on order and be received on time.  The meeting, however, was just a rehash of previous meetings with no conclusion and was in danger of breaking up.  I indicated to the group (it was my meeting) that the meeting could not, in fact, break up without a decision and that everyone would be required to remain in the room until a decision was reached.  One director resisted, indicating that a couple of his required staff had somehow not been included (a ploy to put off the decision) and the next meeting could not possibly be held until the following Friday, a week's delay.  You can imagine how my role in "requiring" this decision was received, but at that moment, we either had to get this done or could have accurately predicted a delay in the program, and both directors knew it. 

I asked the Director who was trying to end the meeting what his "spending authority" was (the amount of expense that he could approve without higher level authority) and he indicated $50K.  I pointed out that a one week delay in the project (and we knew that would be the case because we had all agreed on the accuracy of the critical path chart early in the project, a critical point here) would result not only in a one week delay in the project completion schedule but would also cost the project $1M at the burn rate we were experiencing at that time.  Dead silence.  Then the director asked if Monday morning was the same as Friday end-of-day and receiving agreement, a meeting was scheduled for Sunday afternoon, when the decision was in fact made and the project kept on track.

Without knowing at the very start what the project dependencies were, expressed as a critical path chart, without agreement by all parties that the critical path was accurate and without knowing accurately what the burn rate was, there would have been a tendency to just assume that we could catch up.  It is important that the burn rate be in small enough increments to be useful in managing the decision path.  It is also critical for large complex projects, that a governance process be put in place to ensure these decisions can be made on time, without a confrontational setting like this one.  It is unreasonable for executives to knowingly create situations like the one I encountered and the remedy for this is to establish proper governance, appropriate staffing and focus on education for all participants so that all of this is well understood.  The political process is difficult enough to navigate without allowing these situations to occur when you can prevent them from the start.

How three tiered governance is designed to help control this issue

I recognize that the example given is from a capital project (plant construction) but this same approach has been applied to control of SAP projects.   It has proven effective in battling a less obvious and more damaging tendency for organizations to allow organizational politics to become a roadblock.  This, however, is not an easy task, in fact more difficult than when working with a group of engineers who have had long experience with keeping building programs on track.  Typical SAP programs have project managers who know where the project is on the critical path.  They have an Executive Steering Committee which is comprised of senior executives.  They do not have a process to ensure that meetings are held as scheduled or to prevent the meetings from becoming political battles, which will never result in good decision making (see previous blog post on Staffing for the General).  In the three tiered governance process (Project, Program, ESC) the project office is always responsible for the execution of the program and responsible to know what decisions or work completions are on the critical path, however, the Program Office is there and fully engaged in working with the project team and executive team to see that timely decisions are made through whatever political process exists in the client organization.  It should be emphasized here that the Program Office function is part of any PMO and is a distribution of responsibilities and not additional costs if the project is staffed correctly from the start.

Understanding the political environment

So let's talk about the political environment since it inevitably gets blamed for every conceivable type of mayhem that may occur.  All organizations are built upon political relationships that, over time, get institutionalized into "culture".  Judgments that blame politics or culture typically get in the way of getting the job done within the corporate environment.  It may feel good to blame culture or politics but it rarely is a productive exercise.  The importance of managing these relationships is key to designing a changed business process that, when implemented, will accomplish the intended business results.  It is critical that major change projects include workers who are expert as practitioners in Organizational Change Management techniques, but this by itself will not create success in the project.  It is rather the Program Office that has the responsibility to use their relationship between the project managers and the Executive Steering Committee to manage the decision-making process when it encounters issues.  It also requires that the chairperson of the ESC has to be the top executive responsible for the areas of the company that are being primarily affected by the changes.  If this responsibility is delegated to a "proxy" leader for this executive, the ability to get the political agreements necessary for successful implementation rarely occurs.  The program office ensures that the ESC Chairperson's responsibility is fulfilled without distracting his/her attention from the job of leading the organization.   

The elements of workforce education that can help alleviate the problems

Let's think for a few minutes about what implications this has for the role of education in workforce readiness.  This is often the crux of the issue, as leaders tend to delegate leadership of these programs to the head of IT, or to a Consulting Project Leader or some more junior manager as a "personal growth" experience - all of which will result in significantly higher odds of failure.  There are various educational needs that must be met at all levels of the organization. 

  • ESC members must have a general knowledge of how the ERP package supports business processes, which can be achieved through training like SAP01 or similar, or by the Program Office leaders conducting a seminar for this group that focuses both on the cross-functional areas that are being affected, as well as the role that the Program Office will play in working to get decisions made and approved formally in the meetings. 
  • Program and project leaders must be trained in management tools that will be used to oversee and deliver the project, such as Solution Manager, PMP, and other tools that may be added (OCM tools or Training systems, for example). 
  • The overall project team needs to be trained in business processes through TERP 10 ideally, or other programs that serve the same function. 
  • Consultants need to either be certified in their functions or be able to demonstrate that they have equivalent knowledge through experience. 
  • Finally, business leaders need to increasingly include courses in the role and use of ERP concepts in their on-going business training, like MBA programs that include this education such as Central Michigan University. 

All of these indicate the need for a comprehensive approach to using educational options to improve workforce readiness to help achieve very real business benefits.