Autonomy, accountability and tunnel effect

One young employee told me “I don’t like my manager to ask me over and over again about the progress of my work. I like to get my objective and then be let on my own to achieve it, I’ll report when I’m done”.

Well I thought, you have never been project manager nor in charge of a team. You probably barely know anything about project management techniques and the difficulties to synchronize multiple outcomes, and probably voluntarily ignore the existence of dependencies between tasks for your own selfish comfort.

This kind of cocky open arrogance from someone without significant experience is not something a seasoned project manager will appreciate. Chances are that facing such a mindset, the manager will reinforce his/her control.

It is one thing to demand empowerment, autonomy and be willing to take accountability, it is another to give periodic feedback about the progress of a task or project.

What managers or project managers don’t like at all is the tunnel effect, a common metaphor in France and in project management parlance that describes the extended period during which, the customer and/or the project manager are left in the dark, without any clue about the progress of the job do be done.

At the end of the tunnel, when customers and/or project managers discover the results, chances are that the outcome is not satisfactory or can even endanger the whole project! Something that could have been prevented if there had been periodical feedback, assessment and realignment if required.

This is why software development went for methods insuring loops, scrums, instances during which the stakeholders can share the state of current development, mitigate the risks and even take into account late changes.

Giving periodic feedback is not only something to please customers and project managers, it is also something useful for colleagues and other stakeholders that are dependent on tasks or outputs. By getting feedback and insight, those stakeholders can adjust their own schedules and actions according to current progress.

Management at all levels is highly facilitated through shared visual management, like for example using a Fever Chart, a simple visual dashboard/indicator introduced by Critical Chain Project Management.

Therefore, even in organizations granting a large autonomy to their associates, there is no such a thing as getting an objective and returning to report when it’s achieved.

View Christian HOHMANN's profile on LinkedIn

Can CCPM reinforce Parkinson’s law?

In this post I share a post-mortem analysis of a situation we’ve encountered while helping a company to improve its performance. This company was specialized in custom-made machine engineering and asked for help to improve its On-Time Deliveries performance. We proposed to install Critical Chain Project Management (CCPM), an obvious choice given the circumstances.

Critical Chain Project Management (CCPM) is supposed to supersede Critical Path Method (CPM) with its capability to deliver projects on time, something CPM has consistently failed to do for more than sixty years now.

Among the obstacles to on-time project termination is the Parkinson’s law. This law – not to be confused with the disease of the same name – states that “work expands so as to fill the time available for its completion”,

The Critical Chain Project Management approach recognizes this specific behavior consisting of refining the work, add unrequired features or perform additional tests instead of handing the task over to the next person in charge when finishing a project task ahead of time.

The main reasons for this behavior refered to as “Parkinson’s law” are that someone finishing earlier will:

  • fear to see the allocated time to achieve the task reduced by management the next time
  • fear to appear unable to give a trustworthy estimation of the time necessary to complete a task
  • enjoy the extra time when finishing earlier instead of being late and under pressure
  • enjoy to seemingly deliver just-in time and as predicted something that is ready and waiting for a while

Critical Chain Project Management being aware of the Parkinson’s law, its proponents educate the project members about the consequences of this behavior and put the relay race principles as well as common project buffer in place.

The relay race principles state that when a task on the Critical Chain is nearing its completion, a signal is sent to the next resource that will take over. This resource is then using this early warning to make sure to be ready on the high priority task that soon will be handed over. This is like the relay runner starting to run when the baton is approaching in order to be at top speed when it’s handed over.

The common buffer is a shared protection of the finishing date made of the sum of roughly the half of all individual protection margins. Please see Introduction to Critical Chain Project Management for more details about CCPM protective buffer.

So far so good. Now here is a developers team that was working in constant hassle, with chaotic and permanent priority changes and countless interruptions. Multitasking was so bad that some of the members could not work on a given task more than 3 minutes in average before the next interruption occurred.

Thanks to CCPM, multitasking was banned, interruptions prevented and focusing on one single project at a time became the new rule. The team members soon acknowledged the positive change and the comfort of getting rid of all the hassle and the multitasking.

Yet top management was not happy because the development team did not deliver more by finishing projects earlier, and taking a closer look concluded that CCPM reenforced Parkinson’s law. Indeed, the team members took it easy and did not really rush to the next priority job once their current task on the critical chain was completed.

What went wrong?

Well, nothing went really wrong, simply putting the system under control and stopping the constant chaos let the true problem show up: the team was not managed.

As long as everyone could influence the work on the projects, mainly sales managers and general manager worrying about the delivery date, someone was giving orders. Under such a pressure the developers managed to push the projects to their completion, even they finished late. As things were progressing, even in a total uncoordinated way, there was a general feeling that the process was delivering.

Once the CCPM rules were agreed and installed, sales managers and the general manager refrained to interfere with development team and developers had their list of priorities to work on. What they did not have was a manager taking care about work intensity (another word for productivity), cadence, challenging for continuous improvement. In one word: a manager.

Without the management’s constant challenge and care, the developers simply laid back, feeling legit to do so after all the years of stress and bad working conditions.

Insufficient cause

Reflecting on this story I realized that the top management was assuming that CCPM principles of stopping multitasking and keep focusing on the critical chain priorities was enough to squeeze out the unnecessary individual margins and consequently speed up the development process. This in turn would allow to increase throughput with the same resources.

In the Logical Thinking Process (LTP) lingo, this is an insufficient cause, meaning that by itself it will not be sufficient to cause the expected effect; increasing throughput.

What we consultants, and probably the general manager, considered a given was that this team was managed. As well this was clearly a Necessary Condition, we felt it was “oxygen”, another LTP term for conditions that are supposed so obvious that it is not necessary to express them, just as oxygen is necessary for humans to breath.

Conclusion

The CCPM principles worked well. The chaos was tamed and the developments could finish within the estimated time, now based on so-called focused durations.

The Throughput did increase, but not dramatically. There a three reasons for this:

  1. First reason is that the increase of throughput allowed new projects to start earlier, but given the average length of a project (10-12weeks), the speeding up was not very noticeable.
  2. Second, CCPM was applied on the work packages without challenging the work package contents nor engaging continuous improvement at once. The local management chose to collect data about buffer consumption first, in order to understand where and what to improve. Given the projects durations, this is a slow process.
  3. Third, there was no incentive to improve due to the lack of team management. This later becoming blatant once all other disturbing factors have been neutralized.

So CCPM did not enforce Parkinson’s law. CCPM did what it is supposed to: set the scene for efficient focused work and deliver the projects on promised dates.

CCPM is no cure for everything and no substitute for failing management.


Bandeau_CH160608
View Christian HOHMANN's profile on LinkedIn

My takeaways from Breakthrough Project Management conference

Paris, October 17th, 2016. Ian Heptinstall, co-author of “The Executive Guide to Breakthrough Project Management, Capital & Construction Projects on-time in less time, on budget at lower cost without compromise” (full title), was there to deliver his conference on the subject.

Before you turn away thinking this has nothing to do with my industry, you should ask yourself if yours too struggles to deliver on time, in full, on budget. If yes, the ideas shared in this conference should be of interest, whatever your trade is.

Ian’s claim is to introduce a way to deliver in less time and less budget, without compromising on scope, quality and risks, no longer trading off.

The conference

The time indications are related to the video

Many project managers do not realize their projects go wrong, but several studies show that most (capex) projects do not fulfil their requirements (2:26). Ian goes through the major reasons at macro and micro level for projects to miss all their targets. Three issues are found at the heart of the problem (8:10); the way to contract, the way to plan and the way to execute.

Ian, together with co-author Robert Bolton, believe they’ve found an easy, repeatable and sustainable way to overcome these issues. The shift from traditional project management to Breakthrough Project Management is presented from 10:00.

Among the things to change is the methodology shift to Critical Chain Project Management (CCPM) briefly introduced at 14:32. The project’s monitoring Fever Chart is explained at 22:20. The proven CCPM methodology will face a major obstacle: the way of contracting and purchase (26:06).

The new way to consider contracting is introduced at 29:16 and starts with the issues related to fixed pricing. For instance, complex problems involving high-tech or some new technology are tricky to estimate in terms of costs. Second, buyers want to have fixed prices. Contractors subcontract and ask for fixed prices as well. The buyer is usually the winner on the expenses of the contractor.

Instead of a hierarchy of contractors, the new approach promotes alliancing, i.e. putting stakeholders in a single team aligned onto a common goal and paid in the same way: “cost-fixed-variable” (34:17). Cost are expenses to be covered, without markup. The fees are fixed and variable and not related to costs. The only way for the partners to make more money once the project is started is to get the variable fees, thus have a successful project. What the success is made of is left to the client to decide: time, quality, safety.. This changes the team members behaviors.

The characteristics of project alliances are summarized at 37:45. Project alliancing does not mean the bidding is not competitively sourced (39:10).

The conference summary is presented at 39:50.

My takeaways

The whole conference is presented in a lively way, with some funny and true everyday’s examples of the ridiculous requirements or expectations in traditional project management. It makes the conference anything but boring!

Being knowledgeable about Critical Chain Project Management (CCPM), it is not the CCPM discovery that raised my interest, but the simple way Ian presented it. It is consistent with the book’s aim: being an executive guide, thus give concise necessary insight and explanation, without boring the audience.

Alliancing was new to me and raised my interest, reminding the issues I’ve seen with the usual hierarchical buyer-supplier relationship.

Finally, I’ve found the whole conference (content and presentation) worth a post to promote it. I hope it will do.

Bandeau_CH160608View Christian HOHMANN's profile on LinkedIn

The Executive Guide to Breakthrough Project Management – Book Review

The Executive Guide to Breakthrough Project Management is about combining Critical Chain Project Management and “alliancing” or collaborative contracting for a win-win efficient way to manage huge (or small) construction projects.

Soon when reading the guide, it becomes obvious that what the authors describe as efficient in construction and capex projects can be used in many other trades.

Watch the author’s conference

We are all Lean now. What’s next?

Every once in a while, for nearly 30 years, the question arises: “what’s the next big thing after Lean?”, suggesting that the askers are done with Lean. We write July of 2016 and it seems that everybody is Lean now.

Many people have been repeatedly exposed to Lean methods and tools, have been involved in Lean workshops, kaizen events, sketched Value Stream Maps and identified wastes, sorted out, cleaned up and rearranged stuff 5S style.

They have seen improvements, celebrated the workshop’s success and were dismissed with a feeling of mission accomplished. Others didn’t see a clear outcome, noticeable improvement or a sustainable result and resumed their regular work.

Both may have a legit feeling of being done with Lean, the first because their objectives were met, the latter because Lean doesn’t work.

Almost everybody has heard about Lean, in good or bad, in manufacturing or administration, in hospitals or software development. Lean is a word that found its way into the business lingo, and hearing it often makes it familiar.

There is also the growing impatience as everything speeds up and the instant satisfaction sought by everyone becomes commonplace. Few people are able to commit to a very long and tedious journey towards excellence in the Lean way, most would prefer periodical quantum leaps. Just as they replace their smartphone from one model/generation to the next, keeping up with fashion or state-of-the-art technology.

Of course we are far from done with Lean and very very few companies I’ve visited can claim being Lean. Nevertheless I can understand the fading interest in Lean and the need to reinvigorate it with something new and effective.

Something new means something new to people they didn’t know about until now, not necessarily new per se. Effective means bringing positive results system-wide, not a local optimisation.

My advice would be to consider Throughput Accounting, Critical Chain Project Management and the Logical Thinking Process.

This is not about the next big thing AFTER Lean but the next big thing WITH Lean!

Throughput Accounting (TA) is not really accounting but rather a Throughput-based decision-making approach. In a nutshell, TA shifts focus from cost reduction to Throughput increase and optimization. Follow this link to know more.

Critical Chain Project Management (CCPM) revisits Critical Path Method, the prevalent project management method that failed so far to get developers and project teams to finish on time. CCPM makes sure that projects finish on time and that, thanks to continuous improvement Lean and CCPM style, project durations can be shortened in future.

Logical Thinking Process (LTP) copes with system-wide complex problems. It provides logical tools and methods to surface and neutralize false assumptions, beliefs, conflicting objectives and the like that hinders the organization achieving its goal.

Giving a try with any or all TA, CCPM and LTP, will reveal new potentials and focusing points for Lean to exploit them. Lean isn’t gone soon.


Bandeau_CH160608View Christian HOHMANN's profile on LinkedIn

Critical Chain Project Management alone is not enough

Critical Chain Project Management (CCPM) alone is not enough to drastically reduce a project’s duration and improve the development process efficiency.

CCPM is a proven Project Management approach to ensure a project, any project, will meet its finishing date without compromising quality nor any of the requirements, and even though CCPM can lead to terminate projects earlier, CCPM alone will not squeeze out all improvement potential still hidden in the development process.

What CCPM does well is reconsider in a very smart way the project protection against delaying. Individual protective margins will be confiscated and mutualized in a project buffer, allowing everyone to benefit from this shared and common protection.

There is a bit more than this protective project buffer, but for the sake of simplicity let us just be that… simple.

The visual progress monitoring with a Fever Chart will provide early warning if the project completion date may be at risk and help spot where the trouble is.

Fever Chart

Fever Chart in a nutshell: x axis = project completion rate, y axis = protective buffer burn rate. Green zone = all ok, don’t worry, Amber zone = watch out, the project is drifting and finishing date may be jeopardized. Red zone = alert, project likely to be delayed if no action bring the plot into Amber and preferably Green zone.

After a while, with the proof that all projects can finish without burning up all the protective buffer, meaning ahead of estimated finish date, this arbitrary margin confiscation can be refined and some tasks durations trimmed down while fixing some of the common flaws in the process, like incomplete Work Breakdown Structures, poor linkage between tasks, ill-defined contents or missing requirements.

When done, the projects may be shorter because of lesser of the original protective margins and the other fixes, but the tasks themselves are seldom challenged about their value.

For instance, many of the project’s gate reviews have been set to monitor progress and give confidence to management. They were countermeasures to the drifts and tunnel effects, the period where management is blind about the progress, but with the early warning and easy visual monitoring through the Fever Chart, and more agility in the process, many of these reviews are now useless.

Thus, the time to prepare the documents, KPIs, presentations and attend meetings can be saved for value-creating activities or simply eliminated.

Other tasks may clutter the project, like legacies of fixes of older issues, long obsolete but still kept as the project template still carry them over. Evolution in technologies, unnecessary or suppressed downstream process steps, never fed back may also let unnecessary tasks in the project.

This is where a Lean Thinking approach completes CCPM, challenging the Added-Value of each task, questioning the resources required (both in qualification or competencies and in quantity) and even the linkage to preceding and following tasks.

When considering a development process, embracing Lean Engineering can even go further. Lean Engineering fosters learning and reuse of proven solutions. Libraries of such solutions and ready-for-use modules can save significant time, which can be reinvested in experimenting for the sake of further learning or to shorten projects and engage more development cycles with same resources and within the same time span.


About the authorView Christian HOHMANN's profile on LinkedIn

Rotate a Tree to start your project

During the Logical Thinking Process training course (June 2015), Bill Dettmer took us through the whole process and the associated tools at each step.

The process starts with the famous Goal Tree, assess the current situation and focus on critical root causes with the Current Reality Tree (CRT). Conflict Resolution Diagram (AKA Evaporating Cloud) may be used to resolve conflicting objectives and find solutions (called “injections”) to turn the CRT into a Future Reality Tree (FRT).
But in order to get to the future state, some obstacles will have to be removed or by-passed. This is done with the help of a Prerequisite Tree (PRT).

Once the PRT is ready, it is a kind of logical proof of concept. In order to turn this POC into real action, Bill shows how rotating a Prerequisite Tree gives an almost ready-to-use project network. Therefore, Critical Chain Project Management (CCPM) is the sixth tool of the Logical Thinking Process.

By the end of the demonstration, Philip Marris highlights the “beauty” of this process, patching one of Critical Chain Project Management “weaknesses”: how to ensure what is to be executed as a project is meaningful? He does this by giving a sadly funny and true example in aeronautic industry.


About the authorView Christian HOHMANN's profile on LinkedIn