​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​
Home
Membership
Communities & Groups
Training
Conferences
Publications & Resources
Career Center
 

Applying a little reason to your projects

By Donald Kennedy and Simon P. Philbin

Executive Summary
Workers are frustrated by following bureaucratic exercises. They imagine ivory towers with managers making up rules while ignoring their impact. But while procedures dreamed up by rule makers are effective in most situations, the managers often do not foresee the present misapplication that is frustrating employees. A reason-based approach protects the organization from burying benefits under a mountain of paper and stewards its assets by avoiding unacceptable risks. Thinking about the appropriate level of process adoption for the desired project outcomes can create a middle path that is superior to following a rigid and generalized set of procedures.
 

There is a mantra among managers and consultants that people resist change. This explanation is rolled out every time a management fad fails during implementation. At any organization where the annual turnover through attrition exceeds 30 percent, one wonders just how change-averse these workers are when they are sending their resumés to anyone that will help them escape their current employer. In organizations with a stable workforce, many employees are focused on striving for a promotion (i.e., a big change).

However, if there’s one thing everyone agrees on, it’s that workers do resist changes they perceive to be “bad.” If you go to a bar on a Friday after work and eavesdrop, you likely will hear many workers complaining about one of these two extremes: frustration because they are given no guidance and frustration because their boss micromanages everything they do.

Quality guru W. Edwards Deming once stated that excellence comes from allowing workers to contribute to decisions on how work is executed. During the Hawthorne trials (read the sidebar "Aristotle, management and bad extremes") workers proclaimed that their increased output resulted from management ignoring them during the time the experiments were conducted. On the other hand, Frederick Taylor achieved huge improvements in productivity simply by telling workers what they were supposed to be doing and exactly how to do it. Today, no profitable fast food outlet would allow workers the flexibility to decide how long to cook a burger.

So what is the answer and how does this relate to engineering projects? The two sets of workers in the bar are both correct. Well-defined processes guide the workers, but flexibility must be there for the worker to apply reason to handle unforeseen events and nonroutine work.

We will now build on this logic for engineering projects.

Generally accepted project management best practice

The prevailing opinion is that project management should be underpinned by a robust adoption of processes in conjunction with the organizational structures that enable project delivery. In this regard, project methodologies and supporting processes are captured by management standards, such as the PMBoK (U.S.-based) and PRINCE2 (European-based) approaches. These processes are accepted across many industries to support both the engineering design and project delivery stages, including construction, infrastructure development, manufacturing, processing and production sectors.

For example, failure modes analysis helps identify potential risk elements early so the engineering design can be modified proactively. Earned value analysis supports senior management’s understanding of how the project is progressing, moving beyond simply tracking project expenditures. Furthermore, project scheduling and planning at each stage is reviewed by stakeholders through coordination by the project management office. With such reviews, the stages are well-defined, and a process gate is established to prevent work from progressing to future stages before all approvals are obtained for the work of the previous stage. These are all sensible approaches developed in response to problems that severely derailed particular projects in the past.

However, a review of any project management journal will suggest that most projects still do not fully satisfy the stakeholders’ expectations and, therefore, are viewed as failures. A question that arises is whether all these processes always contribute to the achievement of the desired project outcomes. Instead, could they actually hinder effectiveness? Some, of course, are necessary to support project delivery, such as the need to identify and mitigate for failure modes during the engineering design. But there are others, such as repeated management reviews – along with changes of direction and opinion that may come with opening up any decision for re-examination – which risk providing a lower level of value to the eventual project outcomes.

Could it be the case that projects often are subject to excessive process and control methodology that distract from the actual reason for doing the work? If this is so, how could the project environment be improved to ensure that the level of process adoption is appropriate for the particular project? Furthermore, who should have the responsibility to decide on a reasonable level of process adoption?

A need to use reason when choosing actions

What we will call reason-based project management is predicated on the axiom that all projects are different; therefore the level of process adoption should be contingent on the details of the project itself. Required levels of control should be related to each project’s characteristics, organizational  environment, stakeholder needs, personal attributes (including skill levels) of the project staff and the historical context of the project. Correspondingly, we propose that the level of process adoption within a given project should not simply follow a rigid set of defined steps, as stipulated  in some management standard or manual. After all, such standards are, by definition, generalized sets of procedures formulated for a generic project.

Moreover, the level of process adoption within a project will need to be determined before teams undertake any substantive project activities. It is therefore suggested that a project assessment should be done at the conceptual stage of such an endeavor to ascertain the type and extent of processes that are needed throughout the project lifecycle.

Reason-based decisions need to consider the actual benefits that can be realized to justify investment in the project. For example, designing and installing a high-performance valve for a natural gas liquefaction plant should focus on how the valve will enhance the overall performance of the plant and also how the valve can be fitted to minimize operational losses from any downtime associated with installation. An initial assessment of the project scope and requirements would capture the benefits and risks, and then the level of process adoption should support these outcomes.

For illustrative purposes, let us say the installed valve costs $200,000 and provides $500,000 each year in commercial benefits. This excludes $3 million in lost profits if the plant needs to be taken down for the time required to install. Existing project guidelines may stipulate that all projects are subject to the standard set of approvals at each stage gate, and these typically take seven months to process on a straightforward project. An unrelated maintenance shutdown of the plant scheduled five months in the future would allow maintenance to install the valve without affecting production. This also allows for the four-month delivery time for the valve, but only if a purchase order is issued quickly.

Under the rigid procedures of this organization, however, the valve cannot be ordered until the appropriate stage gate has been passed after seven months, and the installation must be assumed to require a dedicated outage. Consequently, the project is not justifiable on economic terms. Since the sponsor recognizes the potential benefit, the project is proposed repeatedly through the yearly budget submission process. Several of the initial stages are completed, and then the project is canceled once again for the same reasons until it is finally approved some years later.

The cost of continually reviewing a raft of such projects every year easily can run to hundreds of thousands of dollars in a modestly sized corporation. This is equivalent to simply executing one or two such projects every year and receiving some benefit from the expenditure. With reason-based project management, such inefficiencies can be minimized by assessing the appropriate level of project review required to ensure that quality, schedule and cost objectives are still delivered whilst ensuring the desired outcomes are maintained.

A review might show that 90 percent of projects, such as the above valve upgrade, eventually are approved and executed. This would suggest that the lengthy and resource intensive review processes are not adding value.

The main features of the reason-based project management approach are provided by the framework in Figure 1.

This management framework includes four levels. The base level represents the project lifecycle, which encapsulates existing best practices for engineering projects. The second level is the process level, where, in the reason-based approach, there is an early assessment of project scope that leads to identifying the project outcomes clearly. Then, crucially, the project manager must make a decision on the level of process adoption that optimally will support the required project outcomes. The third level represents the traditional triple-constraint requirements that, of course, still need to be delivered, which if supported by an appropriate level of process adoption will lead to successful delivery of the project outcomes, which are the benefits represented by the fourth level.

Case studies of applying reason over process restrictions

In this first example, an engineering procurement construction company (EPC) wanted to respond to clients’ requests for improved designs that meet their expectations. Therefore, the EPC company implemented a certified quality control program, complete with regular external audits to make sure that they were following their self-imposed procedures. In business, there is a rule of thumb that any page from a document represents $1,500 in costs. This considers the authors’ preparation time and all the time it takes an end user to digest and react.

In this case, it required a minimum of 15 pages of paperwork to fulfill the EPC’s quality control process requirements. Consequently, when a potential customer came with a small request, such as a week’s worth of direct work, the EPC company had to bid the work at a minimum of $30,000 to cover the actual work and the overhead effort ($22,500) dictated by the required steps. This led to almost all these small jobs being lost to unfettered competitors who charged less than half that amount for the same deliverables. The EPC company’s revenue took a significant hit, and the situation was recognized as unreasonable. To solve the problem, the chief operating officer changed the quality program so the lead designer could, when it was reasonable to do so, complete and file a single-page form. Company teams then could pass quality audits via the new form and be competitive on small jobs.

In a second case, a large operating company found that the administrative costs to manage small projects were orders of magnitude larger than the direct costs to undertake the physical work. The chief financial officer determined that this paperwork requirement to support all levels of management approvals made it unlikely that any small project could be justifiable on economic grounds. Furthermore, the time requirement of these senior managers on small, low-risk items distracted them from higher priority issues.

The CFO championed a policy that no project would be considered on an economic justification basis unless it had at least a $50 million budget. The company established small, preapproved operational budgets for managers to control as they deemed reasonable to cover small cost items with potential operational impacts. This allowed the company to recognize the high costs of its procedures and eliminated the efforts to chase small benefits. That is, the company made an explicit decision that following its management control and approval processes was unreasonable for any activity below a certain threshold. This led to administrative operations being streamlined with no material impact on production identified.

For a final case, in order to control scope creep on projects and prevent commitments being made outside the authority of the responsible manager, one organization implemented a strict communication protocol. All messages were to be directed through a single point of contact for each originating department. That contact would forward the message to the corresponding point of contact for the responsible department. For the operating plant, certain delays in decision making affected earnings by hundreds of thousands of dollars per hour under critical situations. In one instance, two engineers were attempting to decipher poorly worded instructions when the author of the instructions happened to be walking by in the corridor. “Let us ask him,” offered the one engineer. “No, we cannot,” countered the other, and he proceeded to request clarification from his single point of contact as per the protocol. There is a time delay from sending the message and it reaching the final intended recipient. There is a further delay while the answer is derived and the message is relayed back to the requester. Follow-up questions may be required, causing even further delays.

Upon hearing the reason for the delay in rectifying this particular problem, the project manager realized that there were unintended and unreasonable consequences from following the prescribed protocol. Going forward, the solution was to continue with the protocol whilst adding informal but reasonable contacts involving the relevant parties in parallel. For this instance, the person walking in the corridor could be consulted on the spot and even help develop the wording of the formal request for information. The expert then can begin developing an answer if it is not readily known. When the formal request is delivered to the expert, the answer can be submitted immediately, but it already should be known to the requester through informal channels. Management could intervene if deemed necessary. The new system was implemented without complaint from those affected.

Supporting reasonable management skills

How can engineering project managers be coached and supported in a reason-based project environment? They do need an adequate level of training in standard project processes, such as scheduling, risk analysis and cost control. But they also need the skills and personal qualities to be able to assess a new project and ascertain the most applicable level of process adoption to support delivery of the project outcomes and eventual benefits. They also need to have the leadership skills to secure acceptance of their decisions.

Many knowledge workers can become hamstrung through behaving as if violating the project procedures imposed upon them has the same inherent risk as ignoring design codes and standards. The more successful project manager must be able to see the big picture and help others see it too. As seen in the cases above, procedures sometimes are not tested fully for feasibility and perhaps cannot be followed as written. Therefore, project managers should be encouraged to recognize what is a reasonable course of action for implementation.

The organization should have clear levels of responsibility that allow certain decisions without always having to gain more approvals through a committee structure, especially if this additional scrutiny adds no further value. In one of his talks, management guru Tom Peters related how one hotel chain gives cleaning staff the authority to resolve customer issues on the spot. Some managers might be uncomfortable with front-line staff making financial decisions, but these workers are bound by the same paper trail controls that govern their supervisors. The actions of front-line workers have an immediate effect on the health of the organization with the ability to influence performance on a greater scale than the minor commitments the supervisor might be worrying about.

With projects, there must be sufficient trust in the organization that allows higher levels of management to support project managers on reason-based decisions. Too often, a senior manager will call on the project manager to explain why they chose a particular action. After hearing the logic, the senior manager may chastise the subordinate and give direction to reverse the decision because it violates some approved procedure, regardless of the cost of this reversal. This has the effect of suppressing any motivation to challenge inefficient or misguided processes, and the workforce will be inclined simply to follow the rules as written in the future – whether that benefits the enterprise or not.

Empowering workers for better outcomes

Rules and procedures are developed to help direct workers toward effectiveness and high levels of productivity. Sometimes the procedures are applied in unfamiliar circumstances, and there is clear indication that the results from applying the processes no longer are aligned with their intended purpose. Adopting reason-based project management will give the worker the ability to challenge these inefficiencies and develop processes that support the intended outcomes. The level of process adoption should be reasonable in terms of the project scope and characteristics, not simply determined through blindly following a set of procedures developed for generalized cases.

Furthermore, in this environment project managers need the requisite skills to assess projects in the context of the existing organizational management procedures and control systems and subsequently to take informed decisions on the level of process adoption. The extremes of having no processes and being held to procedures that rob the enterprise of value are to be avoided.

Donald Kennedy is approaching 20 years working as a management consultant through his company KTS Inc. Most of his involvement has been with heavy industrial projects. He is a former employee of mining manufacturer Bucyrus International and the large EPC firm SNC-Lavalin. He has published many articles, presented at conferences, lectured at universities and wrote a book on managerial ethics called Flogging the Innocent. Kennedy holds a B.S. in mechanical engineering, an M.S. in agricultural engineering and a Ph.D. in engineering management from the University of Alberta. He is a professional engineer. 

Simon P. Philbin is associate director of enterprise projects at Imperial College London and also visiting fellow at Imperial College Business School. He holds a B.S. from the University of Birmingham and a Ph.D. from Brunel University, both in chemistry, and an MBA with distinction from Open University Business School. He has authored or co-authored more than 40 journal and conference papers across several areas, including project management, systems engineering, university-industry research collaboration and chemistry. 

Print: Share: