← DolphinUniverse Body of Knowledge

Self-Organization 3/3 - Why self-organization changes are cool for top managers and everyone else!

Wolfram Müller · 2019-09-29 · 16 min read
Critical Chain Project Management Self-Organization Self-Organization 3/3 - Why self-organization changes are cool for top managers and everyone else!

A picture of the Bénard-cell experiment - an example of self-organization in physics

Why self-organization changes are cool for top managers and everyone else! A real example ...

September 29, 2019

Note that this is the third of three parts on self-organization. At the end of the article, you will find links to Parts 1 and 2.

In Part #1 - I provided a scientifically based description of transitions in the order of systems (changes) based on self-organization - with the realization that these changes can happen very quickly. You actually only have to do two things: (1) adjust the control parameter - mostly Work-in-Process (WIP) - and (2) activate a signal/order parameter that makes sense to everyone and helps them behave in a way that works for the whole.

In Part #2 - I showed how to prepare such a change and that the key is the "power layer" in the company, namely middle management. The result of the preparation is a project/change plan that is structured in such a way that it is designed precisely to implement the above two parameters.

Now, in Part #3 - I will show you what such a self-organized change looks like, what can happen, and what to look out for - because self-organization does not mean leaving the system to itself ;-) Therefore, have fun reading.

But what does self-organization mean for a change in concrete terms?

The following also applies to the change itself: (1) set control parameters and (2) activate signal/order parameters! Then "lean back" and see how the system develops by itself.

After the preparation (see Part #2), there is already a rough change plan in place - the change now serves to implement this plan.

If the control parameter in working systems is the WIP, then this must also apply to the change plan! Then the question is simply: How many work (change) packages do I want to have open (in parallel) at the same time?

To check whether it's really a control parameter, simply think about how the behavior of the participants changes when I vary the number. It's easy to play through that in your head. What will happen if ...

10 open change (work) packages at the same time? This leads to "business as usual": everything is started, there is even more pressure, and the daily and project business must also be done - well, this can result in nothing being accomplished, so it is better to keep a low profile! With 10 change work packages at the same time, you have a second problem: if something doesn't go as planned, then you don't know what the cause was! Surely, it could have been any one or even several interventions.

0 change work packages at the same time? We have already seen that, too. This falls under "we are making the change now - but first, we have to do the projects and the day-to-day business." Disillusionment is the most flattering reaction of those involved - frustration is guaranteed - fluctuation is the consequence.

1 change work package at the same time? Oh-oh, that has an effect too! Everyone knows - if only one change package is running, then everyone looks at it (including top management), especially the employees. With only one at a time, you can also see the effect - or, if it fails, you can immediately see what went wrong. Definitely - full focus and probably no hiding until it runs. Okay, sometimes there can be two in parallel, as in a good project. But the fewer, the better!

So, the control parameter for a self-organized change is the number of parallel change work packages (-steps). Instead of WIP, we often call it CIP ("Change in Process").

All that is missing now for a self-organized change is the order parameter - the signal. Here, we use the idea from Critical Chain Project Management (#CCPM), which says: "Take a bit of buffer (approx. 1/3) from every work package and pack it at the end of the project. Check every day whether the progress on the critical chain is greater than or equal to the buffer consumption, and if it's not, take certain measures."

In concrete terms, such a fever curve looks like this:

A typical fever curve - with a "hello, were you awake?" moment

On the X-axis, the progress on the critical chain is shown in steps from 0-100%. Be aware that the critical chain is reduced at the start to 2/3 to gain a 1/3 buffer at the end. On the Y-axis, it is then shown how much of the 1/3 buffer is still left, from 0-100%. Each point represents the end of a week. [Tip: At the end of the article, you will find a link that allows you to request a free Excel template for project planning and control according to CCPM.]

It is very typical for change processes to have at least one or two jumps into yellow or red after 2-3 weeks. That's the "Hello - are you awake?" point. From this point on, the project actually starts in earnest - everyone is awake and starts actively taking care of the project.

With these two elements, you have everything together for a self-organized change, and it can finally start.

Not quite - what is still missing is clarity among the participants about what happens when the fever curve goes into the "red." How does the clarification work? How do you make sure it gets back into the "yellow"? At this point, it is still a pretense! But then it will certainly be put to the test. At that very moment, the signal becomes an active order parameter. That's the key moment!

But what am I saying now - isn't it all self-organized? In fact, from now on, the change continues, and the less you get involved as a consultant or top manager, the better! The biggest challenge for outsiders is therefore to do nothing and to "leave your hands in your pockets."

This change and the following story were about switching a medium-sized company with mechatronic products to agile multi-project management based on Critical Chain Project Management (agile CCPM). In doing so, the project duration is massively shortened (~50%), reliability increases, and, incidentally, satisfaction and project throughput go through the roof. The fact that, in the beginning, there were two development units that were put together in the course of the process is only a side aspect here.

And what else? The plan for change - i.e., the conversion of an entire development area to an agile project procedure - was designed for 100 working days, including 33 days of buffers. Not bad!

But now let's start as promised - and the best way to tell the story is through the fever curve of the change itself ...

The first 4 weeks ...

... run quite normally!

A fever curve - not just the color is interesting, but also the direction of the curve

The first task in switching to "agile CCPM" is to eliminate multitasking in the organization so that work can be done in the flow again. In other words, 50%-75% of projects should be paused internally. Internally, because this is not relevant to the outside world - by pausing, the most urgent projects are completed faster, and you can work on the next one more quickly. From the outside, it looks like everything is getting faster! So you don't have to care what others think - you can just do it!

But in the fever curve, you can see - it's not that easy! You have to discuss and agree on what is urgent now and get the okay from top management. Then you have to tell everyone which projects can now be worked on exclusively and what to do if you are scheduled on a paused project. This counts as about 15% progress in the change, and, as you can easily see, the buffer consumption here was already at almost 30%, twice as high as the progress. If you were to extrapolate the dashed line, then everyone would know: "This will not work - it takes too long."

It is important that this fever curve is made available to everyone, ideally with a small commentary, and above all to top management. Because that's the only way something happens - in their heads.

This is the decisive moment! Everyone is in charge here! For example, the implementation team is responsible for developing ideas on how to regain buffers in the following change steps ("Buffer Regain"), top management is responsible for tracking and demanding these ideas, and the consultants (or rather, supporters) are responsible for ensuring that this happens.

And as you can easily see, the measures to regain buffer have worked. The follow-up steps "use free resources to accelerate hot projects" and "subordinate other tasks (daily business)" were implemented consistently and quickly with the support of top management, and thus buffer was regained.

This is also an extremely valuable signal - everyone sees, "Oh, this is a different change - something is happening here." Furthermore, everyone sees the results - with the first three steps, smooth work is possible again - multitasking decreases, and everyone sees, "I can work effectively again (largely undisturbed)! WOW!"

Next FLEXISTONE - Focus on Go!Live

All attention is now on the next Flexistone (instead of Milestone) - the Go!Live date. There are no fixed milestones in the CCPM world - in Critical Chain, everything is flexible except for the finish date - hence the new name "FLEXISTONE."

Go!Live is the point at which all projects in the portfolio are themselves switched to Critical Chain - well-prepared, reasonably clean project plans that are shortened and equipped with buffers. All projects are staggered (lined up at the bottleneck so it becomes just a constraint) so that neither the constraint nor any other resource is overloaded - i.e., the work can flow smoothly through the teams.

This point is typically located at about 50% of the duration of the change. So let's have a look - what about the fever?

A fever curve as it should look - a motivated team getting things done

Imagine you were a top manager now. What would you say? Everything is under control!

Of course, problems arose again after the first Buffer Regain. Procuring software is not child's play, and it is not easy to get it running and configure it - especially if you only have 20 working days! Every day counts, and the buffer is quickly consumed. But it's just as exciting to see how quickly software arrives when everything is ready and IT is involved right from the start. In the end, it took 32 days for inquiries from 3 manufacturers, pitch presentations, the decision, price negotiation, installation, and configuration - WOW! [P.S.: The record is 3 weeks - 15 working days - for another company with 40 projects and 150 developers.]

In this phase and the following 29 working days, however, the following was done:

And what was the reward? Go!Live at 50% progress and 49% buffer consumption - a precision landing! What a feeling it is when you can deliver so accurately as a team - everyone was more than proud and, of course, now full of energy to see how what they had experienced with one project (the change) works for all other projects!

And then suddenly came Christmas

But maybe not as you might think: "Ringing, and everything will be good!" ... No, the fever curve jumped into the "bright red."

We forgot Christmas!

The team deliberately set Go!Live to 1 week before Christmas - as a focal point. And to be able to "practice" for a week so that they could go full throttle in the new year. All right, all right. Oh, embarrassing - only in the project plan, we had forgotten that at Christmas everyone is at home and no one can make progress. Unbelievable!

When we then estimated the "Remaining Duration" in January, the awakening came - the work was still there, but the Christmas season was gone.

But here, too, the team had "messed it up" (or, better said, the consultant had!). And no one can change the past - Christmas is over. In other words, the team was now challenged.

The next steps to be taken were "Ensure feedback on progress," "Stabilize task management," "Stabilize project management - clean up project plans," and "Ensure top management sticks to the rules and helps to regain buffer," followed by "Adjust the speed."

The good thing is that the next three changes are in the hands of the team. In other words, careful attention was paid to ensuring that feedback was provided (the remaining time in working days for the open work packages). The feedback itself takes no effort - you just have to provide it!

Sounds strange - but it's easier to give daily feedback

You can see the first week of "practicing" before Christmas. Then, on 09.01., we started again, and already on 11.01., the feedback rate was 100%. Over the next few days, it remained high except for small dropouts! This was the first "Buffer Regain" of roughly 3 working days.

Then it was a matter of cleaning up the project plans so that the progress vs. buffer consumption signal (red, yellow, green) became credible. The plan was 3 weeks (15 working days).

A typical red shift - it always happens once or twice

As you can easily see from the number of red projects per day, "cleaning up" is just hard work. Instead of 15 working days, a good 20 were needed to stabilize the portfolio. Nothing in terms of "Buffer Regain" for the change - but a lot of buffer regain for the underlying projects in the portfolio!

In order to regain buffers, the team therefore parallelized follow-up steps. For example, in order to bring top management in line, a super-transparent information policy was pursued right from day one. All participants received a short email in the evening with the portfolio status and the measures the team had taken to drive the projects from red to yellow. The effect was resounding - full support from top management and no negative interventions. As a result, the work package was no longer necessary. Similarly, the next "Adjust Speed" work package was completed immediately because the speed was already so high that there was nothing to adjust.

Thus, the buffer was back, and the change project was again close to "yellow."

And what was the reward? Of course, there were also crises here - through feedback, old patterns broke down, and real problems between departments became transparent. However, these were actively addressed, and the solution was launched. This was the only way to recover buffers in the projects. And every problem solved is like a drop of oil in the machine - a small step that brings the work back into flow. Calmness - real added value becomes possible. Flow also returns mentally for everyone involved.

In the final sprint, the legs sometimes get tired

The next steps are actually simple - you just have to bring the continuous improvement process to life. But sometimes your legs get tired - you can't always just sprint! [Attention: side note regarding "Sprints"!]

The team even fixed the "we forgot Christmas" trouble

So, at point (2), the team just had to adjust the estimates and focus on what's really important. The last few weeks were therefore simply marked by the fact that every week, you had to look at how to get the last bit of buffer just in time for the finish.

And then, after a good 100 working days, the buffer was exhausted and the legs were heavy, but the goal was reached.

Agile Critical Chain Project Management is established!

At this time, the number of active projects had been reduced from about 120 to 12. Each had a clean project plan, and most were in yellow and green.

A well-balanced, low-WIP portfolio - promises can be met = all

The employees report a completely different, much calmer way of working. At this point, a cross-departmental stand-up has been established in which fine-tuning (Buffer Regain) is discussed daily. And the continuous improvement process (CIP) has begun - more and more work is being done on cooperation among the departments.

By the way, the average project duration has been roughly halved! And reliability has been raised to previously unknown heights.

And what about self-organization now?

So, top management may have had to invest 10 hours - that's not much.

The staff wasn't away from the job much either. A 1/2-day training session for the project managers and maybe 1-2 hours for the task managers. The developers themselves were simply allowed to do what they like to do - develop! So, the skills to do perfect project management must have been there for a long time - yes, of course!

And clearly, the team leaders and managers had a lot to do. But they did it of their own free will. It was they who showed the creativity to bring the change back onto the track of success again and again! On their own - it is supposed to be self-organization.

The key lies above all (1) in the limitation to one change step after another, as well as the correct order (see Parts #1 and #2 of the article series), and (2) in the fever curve as the signal that immediately shows when something does not fit and the focus on getting "back to yellow."

Of course, this only works if the first steps of the change really make a difference - and we all have that in our hands!

But the most important thing - it's good for people! The FLOW is back - work makes sense and is fun again!

Greetings - Wolfram Müller - Founder of Speed4Projects.Net

Links