Demotivation is actively nurtured, especially in large organizations, by the myriad of programs aimed at connecting individual performance with the company’s bottom line. Invariably, these programs fail to recognize that very little can be done to increase company performance by individuals who are slotted into a poorly designed organization. The shift has to happen at organizational design level by recognizing the web-like nature of work and reflecting that through a coherent control mechanism.
As mentioned before, capturing and managing the effect of interactions through statistical understanding (SPC) is critical; structuring these interactions into a manageable, measurable format is another important step. Projects do exactly that: they convey, powerfully and cohesively, people’s desire to contribute with their knowledge to the achievement of clearly communicated and shared goals.
By allowing individual competencies to be gainfully leveraged through projects, we achieve two fundamental results: individuals can give their maximum input via their knowledge-based contribution and we remove a major form of frustration and disempowerment engendered by performance assessment and year-end reviews. Most importantly, by allowing individual talent to shine tangibly (not just paying lip service to it) in a way that is systemic and measurable, we foster a genuine culture of self-empowerment that feeds directly into company results.
What we achieve by synchronizing these available competencies across projects is to maximize what existing competencies can contribute to the success of the organization. No need for further investigations on individual accountability and seat of the pants, bias-driven assessments.
How do we exemplify all this? How could we embed all this into a… tool?
Our journey: Ess3ntial
My partners and I were not born digital; let’s say we all have vivid memories of when Sir Elton John’s “Crocodile Rock” and Bruce’s “Thunder Road” came out. We grew up in a time when computers were in their infancy and software was developed, well, pretty much starting from mathematical logic.
So, we started from there. Instead of talking to a “software guy” we approached a “math guy”. It gave us cultural comfort and cognitive solace in a fast-changing world.
We chose him carefully: highly intelligent and curious and just as software illiterate as we were. With him, we spent months discussing the ins and outs of the management approach and new organizational design we had in mind. We asked him to read and become conversant with all the management literature that was guiding our thought process. It was challenging but definitely exhilarating. The result has been over 100 pages of beautiful logic; think of it as a riveting “mathematical novel” that we then fed to hungry and smart digital kids. The choice of programming language and the fresh and easy-to-use interface of the software that emerged is all to their credit.
We named it Ess3ntial because it gets to the essence of the issue of transforming organizations from silos to systems and it does it without unnecessary bells and whistles that may cloud its purpose.
At its very core, Ess3ntial is a cloud-based multi project platform powered by an algorithm to schedule competencies at finite capacity. It is largely inspired by Dr. Goldratt’s original work on Critical Chain but with some noticeable differences.
Ess3ntial was created to exemplify how an organization can safely move from silos to system; to do this we had to shift the focus of the scheduling from the individual (resource) to what the individual is capable of doing (their competencies). As a result, what we schedule is a competence. This means that two individuals with the same level of competence are interchangeable in a project. And it all starts with creating a database of competencies, what a person is truly capable of contributing, regardless of the silo they are in. We allow actions to be performed by individuals with an appropriate competence.
Ess3ntial allows us to put the solution (injections) into action.
As projects represent the way an organization makes its bread and butter it is only logical (as Mr. Spock would say) to design a control mechanism that accounts for the interdependencies inherent to the project. In the Theory of Constraints (TOC) this is called buffer management and we felt that an effective (and scientifically valid) way to portray the outcome of these interdependencies is via a chart that shows the overall progression of the project. We call this chart a process behaviour chart, a much less aggressive and more appropriate verbiage than control chart. By looking daily at the chart through the lens of variation as taught by Deming, we gain both insight and foresight that would otherwise be inaccessible into what we can expect to happen going forward.
I venture to believe we are now ready to take the first steps towards building our systemic organization. And it all starts with scheduling.
The process of scheduling
As we stated earlier in this series, you cannot have the same person work on two different tasks at the same time. Scheduling must be realistic. At the core of Critical Chain project management, just as with Drum Buffer Rope in The Goal, there is the common sense, yet revolutionary, concept of finite capacity scheduling.
The reason why we want to manage a project instead of just pushing ahead with an uncoordinated set of tasks is because we want to honor our commitment to the customer for an agreed-upon delivery date. Accordingly, the first step in scheduling must be to establish a delivery date; moreover, we want to protect this date from the vagaries of life (scientifically: Variation), hence we decide upfront how much protection we want to have. We call it a project buffer. Indeed, the size of the buffer is in some way connected to the amount of uncertainty we anticipate in the development of the activities. As the length of the project is dictated by its Critical Chain (the constraint of the project) the size of the buffer will be a percentage of the length of the Critical Chain.
The length of the Critical Chain of each project will obviously be influenced by available competencies so, the second step is to create the repository of available competencies the organization will rely upon to conduct its projects. Needless to say, competencies belong to individuals and so the third step in the scheduling process is to create the list of resources that will be called upon to execute the projects.
The fourth step is to assign to each resource as many competencies (at least one!) as he/she has and it would be wise to specify a level at which that competence can be exercised (high, medium, low, etc.). Of course, a resource with high level of competence X also possesses the medium and the low levels.
A project is made of tasks; these can be logically derived by identifying the steps necessary to achieve the goal of the project; in TOC this is done by developing a Prerequisite Tree and we can call this the fifth step in the scheduling process.
Immediately after, we have the need to provide an estimate for the task duration, and this is the sixth step in the scheduling process. This can be powerfully aided by the development of Transition Trees; they specify the details of the task to be executed, the reason why we want to perform it and the need that originated the task. With these elements in mind we can make an educated estimate of the task duration and decide the level of the competence we need to execute it in the desired timeframe. (Basically, based on the level of the competence required and the resource we have available for performing the task, we can provide an acceptable time estimate.)
Now we are ready to build the network, the seventh step in the scheduling process, and get a good visual sense of how activities are connected. Ess3ntial does it in a very simple and elegant way.
Time to schedule. The eighth step is to build the logical sequence of events, the Critical Path. This provides the clear-cut logical sequence of how the tasks should be performed. Unfortunately, reality bites and we have to deal with what we have available. Things may change drastically in this light, especially if you need to manage several projects simultaneously. This is what the powerful algorithm embedded into Ess3ntial is for: to make a reality check on what we can really do, to transform the Critical Path into a critical chain – the constraint of the project. This is the ninth step in the scheduling process.
A scheduled project is ready to be launched. Launching it is the tenth step in the scheduling process, when available competencies are deployed, resources taken into account and we can begin to manage the project. How? By understanding how the Chains of the projects are moving – how much the buffer is impacted by the progress of the activities in the project.
The eleventh step does precisely this: it allows us to manage based on understanding the impact of variation on the overall activities taking place. Ess3ntial leverages process behaviour charts to gain insight into the overall predictability of the project; by understanding buffer variation in statistical terms we can decide the appropriate course of action to manage projects. Buffer management done in this way focuses on process predictability (how reliably we execute tasks) instead of imposing colourful artificial boundaries (the three coloured zones) onto what we should do to improve project execution.
As we stated earlier, by synchronizing the available competencies across projects, any company can maximize what existing competencies can contribute to the success of the organization. They can satisfy people’s desire to contribute with their knowledge to the achievement of clearly communicated and shared goals. It’s a win for everyone.
This is the fourth and final article in a series! If you would like to read the first one, click here.