Affecting change in a project performing organization
Because projects are about change, it would seem natural for project-performing organizations to endorse change in their project management; however, this has not been the author's experience.
There are many reasons why organizations may resist changes in the project processes, and there are also many mechanisms by which project process improvement can fail to achieve the desired results. This paper explores some of these reasons and mechanisms and provides the solutions for them. The author then presents some basic guidelines for introducing change into project management organizations, as they have been applied in a specific organization.
Through many years of working in organizations that specialize in the performance of projects, the author has found project management organizations to be very prone to getting stuck in a trap; they continue to do what they have been doing and in the ways they have been doing them, over and over again.
A recent example is an organization that demanded that an electronic time sheet approval process, successfully used with the client for years, be abandoned in their project because it was not part of their standard process. Significant expense was being incurred to route and approve paper time sheets for no purpose other than this organization's unwillingness to adapt their processes.
The author's experience with this phenomenon has been primarily in construction organizations, in which the entire business revolves around managing projects for clients. The scopes involved range from very small to multi-billion dollar projects. Time frames range from very intense activity over a few weeks to programs that last many years.
The concern here is not in the successes of these clients’ projects, but rather in the internal processes used for improving the processes used to serve the clients.
While each situation offers its own challenges, each provides opportunities. The intent here is to generalize principles that, when applied, lead to an increased likelihood of achieving effective project process improvement.
The Difficulties in Changing Project Processes
Obstacles to project process improvement come in many forms and are often disguised. Some common reasons for resistance to change are:
- The risk involved in attempting change
- Assuring a return on the investment in change within the time frame of a single project
- Allocating project budgets to process change
- Project management independence
- Organizational inertia
In any process change, one or more of these reasons are probably going to act as an obstacle to endorsing change, and these are briefly discussed below.
The Risk Involved in Attempting Change
Anyone involved in projects understands that projects involve elements of risk. What are the potential consequences of the risk? Can the project be completed on time and within the budget? Slight deviations from project goals can have huge consequences. In one semiconductor manufacturing project, a manufacturing start-up date missed by a few weeks destroyed the viability of the project and its products. The billion-dollar plant was never placed in production. In another case, a major computer network rebuild was delayed by more than a year by the selection of unproven technology. The designers depended so fully on this technology that, when it failed to perform as expected, the project objectives could not be realized.
Faced with such uncertainties, it is hardly surprising that project managers rely on proven technologies and methods, even in the face of strong evidence that there is a better way. Overcoming this reason for resistance to change involves both reducing the risk and reducing the consequences of the realized risk.
For example, consider a proposal to change the means of monitoring the schedule in an intense project. A back-up system might be needed to assure the schedule can be monitored if the new method proves to be inadequate. The author has experienced this scenario on several projects and discusses one such case in the section on scalability below.
Assuring a Return on the Investment in Change within the Time Frame of a Single Project
Most projects are freestanding, in the sense that the costs of any changes to processes made on that project will be borne by the project. Even after mitigation of risks, implementing process change can distract project management and incur costs. One version of this might be illustrated by a graph, sometimes associated with the concept of a “learning curve.” In Exhibit 1, we illustrate this concept by example.
Exhibit 1 – A Learning Curve
In this figure, the y axis represents some benefit derived from operation of a process. The x axis shows the progression of time. At point A, representing a current condition, we have a stable level of benefit. At point B, we hypothesize a target higher level of benefit through adoption of a new process. Unfortunately, in almost every real case, we can expect that a point C occurs on the path between A and B. This represents the issue that during “the change,” the rate of benefit is reduced. The amount of this reduction is represented by the area marked D. At some point, E, en route to B, the rate of benefit is projected to exceed what we were receiving at point A. From that point, to some point in time, F, the balance of benefits is still negative owing to the change. We could realize the level of benefits envisioned as B, exactly on time, but if point F occurs after the end of the project, we might still have a deficit of total benefit to the project for the improvement.
Any prudent project manager, faced with a process change proposal, has to ask him- or herself if point F will be reached within the life of his or her project. In reality, the decision threshold is higher than that. Given the distraction of managing the change, the project manager will normally have to be convinced that point F will be reached long before the benefits stop accruing on his or her project. The alternate scenario is to sell the change based on uncertain future benefits that would accrue on future projects; uncertain future benefits are, rightfully, a very hard sell.
As a hypothetical example, let's assume that a project manager is familiar with a paper spreadsheet-based system of tracking equipment on his or her project, from specification, through purchase decisions, to delivery. Although the system is very labor intensive and communicates information very poorly on any but an item-by-item basis, it has proven itself to be robust on many projects. Now a proposal surfaces to computerize this information so that it is more readily available, more easily updated, and more easily shared. The project manager has to ask him- or herself:
- What is the cost to the project in terms of dollars and distraction?
- What are the risks, including the risk that the system might break down at a critical point?
- How tangible are the benefits of the improvement?
- What is the probability that this can be implemented in a time frame that will assure benefit for this project?
- Are such benefits based on the assumption of reducing my already inadequate staff even further?
Unless the evidence about this system proposal is very persuasive, it is understandable that the project manager will decline the opportunity to try it.
The Allocation of Project Budgets to Process Change
Most project estimates are made based on accomplishing things in a proven way, with emphasis on the tangible accomplishments. While a certain inadequate amount is allocated in the project budget for “overhead,” it generally translates to a number of personnel based on methods we are comfortable with. The idea of spending money within that budget on process improvement, in ways that were not anticipated when the budget was created, is foreign to the way we look at project budgets.
In order to sell an improvement in this case, the business case must be persuasive. The organization making the change may find it necessary to adjust accounting so that the project budget does not bear the full cost of making the improvement.
An example of such an adjustment comes from my experience. In order to implement a new process, we provided an individual to the project, who supervised that implementation, and provided such assistance in other areas when he was available, and without his time being charged to the project budget.
Project Management Independence
Since we recognize projects as unique undertakings, we generally view project managers as being very independent. We expect the project manager to make quick decisions, unencumbered by certain organizational norms in order to move his or her project along. Suggesting to the manager that a process change will benefit the organization and its other projects is often seen as an indirect attack on his or her independent action. The project manager takes it as a warning that, “If I endorse this project change, knowing that the intention is to impose it on other projects, then I can expect the same thing to be used against me in the future.”
An antidote for this attitude is usually to see that process change is initiated by groups of project managers who agree, in advance, that they personally, and the organization generally, will benefit from the change. This then leads to a cheering section of peers who act to support the project manager who leads the process change.
An example of an improvement in this model was the suggestion that we develop a computer process to forecast client costs from our cost accounting processes in a more timely fashion. The requirements included capture of cost, particularly payroll cost, before it was “posted” to the job cost system and the allocation of costs in the client's account structure. All project managers agreed this would be a useful tool and recognized that it was too big a project to develop for a single project. A “volunteer” was then found to help define and implement the improvement process for the benefit of all projects, while maintaining a practical focus. The resulting cost modeling exceeded expectations in accuracy and is now widely used in many projects.
All organizations exhibit inertia, which is often ascribed to a resistance to change. In reality, inertia is mostly associated with a well-developed skepticism that the change will be as painless as portrayed and as beneficial as claimed. It takes energy to make change, and management is often more concerned about reducing energy expenditure through stability and this leads to real difficulty in putting the change into motion.
In one rather unique experience of process change, management confronted this issue head on, in a meeting with all those who would be implementing the new process. In that meeting, managers acknowledged that short-term productivity would go down, longer hours might be necessary, and glitches would appear in the system. They also made it clear that there would be no turning back and that the system would be worked on until it worked efficiently. In this case, support for the change developed quickly, and the system was implemented successfully in a very short period of time. Acknowledging the doubts in the beginning became an important tool in reducing resistance.
Project Process Change Failure Mechanisms
Having overcome, or temporarily neutralized, the resistance to change, we can embark on our project of improving our process. So, what can go wrong?
My experience suggests the following as common causes of process change failure:
- Poor picking of improvement targets
- Bad project definition
- Lack of support
- Failure of the improvement to scale
Poor Picking of Improvement Targets
The most common error in picking improvement targets is to pick things that most people in the organization do not care about, do not value, or do not feel touched by. Such improvements are really part of the personal agenda of a single manager or of a very narrow constituency. They are unlikely to gain wide support.
The benefits of the improvement need to be felt by those who are called on to make the process work. For instance, projects based on better information for management are likely to be unpopular with those providing the information unless they also see the direct benefits. Such changes will be particularly unpopular among information providers who may view the result as a potential “club” to be used against them or to be used in unfairly judging their performance, without fully understanding the system.
Since the project environment is always marked by the impending end of the project, it is common for short-term perspectives to dominate. For instance, don't expect enthusiasm from hourly workers for a project process improvement to “reduce overtime.”
Bad Project Definition
Bad project definition includes under budgeting the time, cost, or management effort needed to make the change. It also includes overestimating the benefits of the improvement. Generally, we are better off focusing on projects with obvious returns.
As a personal rule of thumb, I often state that you can't do something less expensively or more efficiently than you are not now doing. For instance, it is very difficult to justify a project based on “improved information” unless you include the costs suffered by the organization from the lack of that information. A good improvement must cover enough of the system to anticipate all those who will benefit or otherwise be affected.
Lack of Support
A critical error is misjudging the level of support needed for the change. It is obvious that overlooking voiced objections, conflicting agendas, or lack of resources can sink a project. What might not be so obvious is bulldozing others into silence. Silence is neither an endorsement nor assent and does not indicate support of the change.
The key to a successful change effort is commitment. To measure that commitment, project managers must be asked to endorse the adoption of the change and not merely silently assent to others desire for the change.
Failure of the Process to Scale
Often our project systems have a fragile flavor about them. They are held together with chewing gum, duct tape, and a little bailing wire. In this environment, it is common for improvement proposals to surface when someone “develops an Excel spreadsheet” that will “pull information together flexibly and make it available to everyone.” In other cases, the proposal involves something more formal but still falls short of a detailed investigation of interactions.
I have experienced a number of cases of improvement project failure caused by such thinking. In several cases, a web of spreadsheets was assembled and convincingly presented as the way to control certain project processes. The project moved forward on the assumption that this method would be of assistance to everyone.
The concern is not for the model itself, because such modeling can move improvement forward through improved understanding. The real concern is scalability. Can the “spaghetti bowl” of interlinked spreadsheets withstand the pressures of the real world? As you might imagine, what works acceptably at low volumes of line items under the direction of a smart engineer might not work hen the numbers increase and the engineer is tasked with fighting other fires.
In one project, I installed a visual map of the work in the form of bedsheet–sized bar charts, taped to a wall in the office. Because the client had mandated a fairly sophisticated system for tracking the same work, as well as the work of other contractors on the same project, this was explained as a visual system to support his system and convey the daily details to our supervisors. In reality, it was a backup for a system we were convinced was doomed to failure when it was scaled up to complete the entire project under the pressure of working two 10-hour shifts per day.
Our prediction of the need for this backup was realized when we found the client's project control people sneaking into our trailer to track their progress from our bedsheets, when their system broke down under the pressure. Our decision to provide this “redundant” system as a backup was further vindicated when the client asked us to take over the management of work previously assigned to other contractors. They had lost control of their work when they could not track it through the owner's broken system.
Some Guidelines for Process Improvement as Applied in One Organization
An improvement process applied in one organization, over a decade of project process improvement, is described below. The process is first described in general terms and then followed by exploring some key points in operating the process, with examples drawn from experience.
The process developed as one in which current process improvement teams were part of the monthly management meeting agenda. Quality action teams were chartered for a specific time, usually one calendar quarter. Team actions were given a general charter for accomplishment in one quarter. Together, the team leader, management sponsor, and team members developed specifics for the charter, and the success of the team was judged by their accomplishment of this charter. Each team, generally from 3 to 5 at a time, was reviewed in the management meeting every month. In this review, the management sponsor reported on the actions of the team. At the end of the quarter, the team leader, usually not a member of the management group, represented the team in reporting the team's actions to management.
Assure Management Support
The process director kept a list of improvement ideas from which specific recommended actions were selected by the management group to tackle each quarter. If the idea was not well developed it was generally held for future consideration. If broad support for the initiative was not evident, the effort was not undertaken. This assured that the management group, not just a single manager, valued the effort. This also generally prevented the adoption of projects valued by only a narrow group. If an individual manager felt strongly about the improvement and its benefits, then he was responsible to make a better case with the group.
Each initiative was assigned to a member of the management team who acted as the sponsor. Generally, this was the manager whose functions would benefit most from implementing the change, tempered by recognition of other demands for the manager's attention.
The role of the sponsor is to remove roadblocks from the path of the action team. In the management group, the sponsor is the person most accountable for the outcome of the initiative.
Here's another example: a major project to bring document imaging to the company was handled by a series of teams. Team sponsorship moved from administration, to accounting, and then to information systems as various parts of the improvement changes were undertaken.
Focus on Well-Defined, Bounded Efforts
In this organization, improvement projects were not considered if they did not affect and benefit multiple departments. Suggestions for a change initiative that would help one department were referred to that department. Suggestions that benefited one department, but had to be implemented by change in a second department that received little benefit, were weeded out early. Proposals for ill-defined initiatives were referred back to the originator, who was asked to do the preliminary work to assure that the idea was actionable before it could be assigned to team.
This resistance to quick chartering was frustrating, but it also kept many poorly defined projects from failure.
Initiatives were chartered with a general statement about expectation, but every attempt was made to avoid forming teams to endorse decisions.
On occasion, this effort missed the mark and the failures to properly vet the charter were obvious. In one painful example, the management group chartered a team to consider allowing summer flex time for office personnel. The team made great progress toward a positive recommendation until the president of the company let it be known he was against the idea. The team sponsor effectively killed the team action out of fear that their eventual formal recommendation would be unacceptable. This was an example (fortunately, a rare example) of a poorly considered change initiative.
As noted above, action team charters were limited to one calendar quarter. In practice, this resulted in about a four-month time period from when the charter was issued until the final report was presented. Emphasis was placed on defining each charter in a quarter bite. This meant that a team charter might result in a recommendation without implementation details or in the development of a sample of improved process without full implementation. A team recommendation could very likely be handed to another team, often with the same leader and team members, to further develop under a second charter. The emphasis was on evolutionary change through a series of completions, rather than on huge projects with ill-defined interim steps.
In one example of success, changes in the billing process to clients were initiated and accomplished through the efforts of two quarter-long teams. The team leader commented that he had been associated with attempts to reform this process for over two years, but that the focus of the quarterly objectives had resulted in more progress in each of two quarters than had occurred in the previous two years.
In addition to the management sponsor, each initiative was assigned a team leader. This was usually not a member of the management group, but someone with interest in the outcome. The assignment served as a development position for future leaders. Members were drawn from all involved departments. An important consideration in selecting both leaders and team members was a commitment from their supervisors to make the time available for their full participation. Because the team effort was endorsed by the company's entire management group, this was usually not a problem. On occasion, changing client needs could derail an effort by overloading the leader or one or more team members; on such occasions, the person was generally released from the team and others were assigned to the role.
Use a Quality Team Process
Developing this change process was a part of a corporate dedication to continuous quality improvement. As such, we attempted to apply ideas from that culture, such as making meetings prompt, keeping to an agenda, using trained meeting facilitators, and developing team behaviors.
Report Progress Regularly
As noted in the general process description above, each team made a brief report on its progress every month in the combined management meeting. This had the positive effect of focusing attention on underperforming teams. Because the sponsor could find himself in the “hot seat” if the team was not moving forward, the regular reviews served as an effective push to continue moving forward.
At the end of the team action, the team leader was expected to report to the management group on the conclusion of the team action. As noted, this might be in the form of a team recommendation, a report on a pilot implementation, or whatever else the team accomplished. An attempt was made to make it clear that, when the team action resulted in a recommendation, the success of the team was measured by the clarity of that recommendation, not by its adoption by management for further action. Usually, recommendations were followed by implementation charters, but this was not always the case.
In most change initiatives, the process resulted in small-scale implementation of pilot projects. When the pilot was successful, those involved became natural evangelists for the initiative. This made the job of selling the improvement to others much easier. In the desired course of events, a successful pilot resulted in requests from other projects to gain access to the processes, software, or methods. As more projects extended the pilot, a critical mass was reached in which more and more project teams wanted the benefits of the improvement. While this took time to move through the organization, it proved much more effective than publishing a new standard operating procedure, with directions to implement it on each project, before it had proven its worth.
Follow Through with Training and Documentation
As change occurred, we followed through with training and process documentation. We found that without a commitment to these aspects of change, the change would not stick.
Some of our most successful projects involved getting practitioners to develop documentation on the processes that they used routinely, and then providing training in these processes. In many cases, this showed that our project processes had evolved beyond our documentation and we were providing outdated manuals not regarded by users as being very relevant.
Offering Project Managers a Choice
At some point in any initiative, you may reach a level of organizational penetration, when it is obvious that many projects or personnel are using the process. However, many may still not be using it and do not intend to unless pushed. An effective way of dealing with this is, when that point is reached, project managers who have not endorsed the new way are given a choice: They can either adopt the process as documented or fully document their current process as an alternative. We call this difference the choice between using the corporate model process or developing a project-specific process. It is amazing how often the corporate model (or a slightly modified version) becomes acceptable, if the only other option is developing full documentation of an alternative process.
Successful change efforts build on recognition of effort and value. To ask a team to undertake an effort to implement a change, and then not recognize that effort, is a morale killer. In any change process, remember to celebrate, celebrate, celebrate!
Over the course of nearly a dozen years, the process just described was used in over one hundred change initiatives, across many projects and branches of the author's company. Examples of some of the larger projects that were successful using this system include:
- Customizing accounting systems to account for client requirements, significantly reducing manpower requirements to comply
- Implementation across the company of a document imaging process, including electronic routing of invoices for approval
- Successive development of a corporate Intranet based on “front page” type technology and its eventual replacement with a “Share Point” environment
- Development of standard process models for project work, estimating, and project planning
- Development of an in-house capability to track earned value progress measurement in increasing detail and applying this capability to the deployment of a lean project environment on key projects
In each case, incremental accomplishment of the overall objective through focused, quarterly action teams led to successful change in an organization whose entire focus is performing projects for clients.
© John Homer
Originally published as part of Proceedings PMI Global Congress 2010 – Washington D.C.