Theory of Constraints

Theory of Constraints says that any system must have a constraint that limits its output. If there were no constraint, system output would either rise indefinitely or would fall to zero. Therefore, a constraint limits any system with a nonzero output. 

Deming  “We learned that optimization is a process of orchestrating the efforts of all components toward achievement of the stated aim.”

A physical chain provides the most commonly used prop to describe theory of constraint. The goal of a chain is to provide strength in tension. Everyone accepts that the weakest link determines the strength of a chain. Anyone can see that improving the strength of links other than the weakest link has no impact on the strength of the chain.

Dettmer poses the following list in his book Eliyahu M. Goldratt’s The Theory of Constraints, A Systems Approach to Continuous Improvement :

1.    System thinking is preferable to analytical thinking in managing change and solving problems.

2.    An optimal system solution deteriorates after time as the system’s environment changes. A process of ongoing improvement is required to update and maintain the effectiveness of a solution.

3.    If a system is performing as well as it can, not more than one of its component parts will be. If all parts are performing as well as they can, the system as a whole will not be. The system optimum is not the sum of the local optima.

4.    Systems are analogous to chains. Each system has a “weakest link” (constraint) that ultimately limits the success of the entire system.

5.    Strengthening any link in the chain other than the weakest one does nothing to improve the strength of the whole chain.

6.    Knowing what to change requires a thorough understanding of the system’s current reality, its goal, and the magnitude and direction of the difference between the two.

7.    Most of the UDEs within a system are caused by a few core problems.

8.    Core problems are almost never superficially apparent. They manifest themselves through a number of UDEs linked by a network of effectàcauseàeffect.

9.    Elimination of individual UDEs (undesired effects) gives a false sense of security while ignoring the underlying core problem. Solutions that do this are likely to be short-lived. Solution of a core problem simultaneously eliminates all of the resulting UDEs.

10.  Core problems are usually perpetuated by a hidden or underlying conflict. Solution of core problems requires challenging the assumptions underlying the conflict and invalidating at least one.

11.  System constraints can be either physical or policy-based. Physical constraints are relatively easy to identify and simple to eliminate. Policy-based constraints are usually more difficult to identify and eliminate, but they normally result in a larger degree of system improvement than the elimination of a physical constraint.

12.  Inertia is the worst enemy of a process of ongoing improvement. Solutions tend to assume a mass of their own, which resists further change.

13.  Ideas are not solutions.

Five Focusing Steps

Having realized the goal of the system and the fact of a constraint, Goldratt invented the five focusing steps as a process to get the most out of a system in terms of the system goal.

1. Identify the System’s Constraints, In order to improve the system in terms of the goal, you have to identify what is holding it back. You have to decide “what to change.”

2. Decide How to Exploit the System’s Constraints , Exploiting the system constraint requires getting the most out of the weakest link of the chain. In this step, you are deciding “what to change to.”

3. Subordinate Everything Else to the Above Decision, This is the key to focusing your effort. While subordinating, you may find many assumptions that seem to inhibit doing the right thing. This step is the first part of deciding “how to cause the change.”

4 Elevate the System’s Constraints, This is the implementing part of “how to cause the change.”

5 If in the Previous Step a Constraint Has Been Broken, Go Back to Step 1, This is the optimum continuous improvement strategy.

Skill Portfolio Management

Significant number of project execution organizations have started using project portfolio management (PPM) as a means of selecting the right projects,  The same approach can be used to manage our skills, or say skill portfolio management (SPM)


Project portfolio management (PPM) is generally defined as a dynamic decision-making process, whereby a business' list of active projects is constantly updated and revised (Cooper, 2001). In this process, new project are evaluated, selected, and prioritized; existing projects may be accelerated, killed, or deprioritized. Organizations are using project portfolio management (PPM) as a means of selecting the right projects .The derived definition of skill portfolio management could be , a decision-making process, where one evaluates the need of new skills, select and prioritize acquisition of skills. The way organization maximizes returns on capital by using project portfolio management, we can also maximize returns on our time investment by using skill portfolio management.


Let us take example of two project portfolio management tools for skill portfolio management.
• Strategic Alignment Model
• Boston Consulting Group Products/Services Matrix


Strategic Alignment Model
This model attempts to align projects with the direction the enterprise has decided to follow. In other words, it aligns projects with those things that are important to the enterprise. For skill portfolio we can look at it along with Habit 2 from “7 Habits of Highly Successful People”. The habit 2 talks about   “Begin with the End in Mind”, if your ladder is not leaning against the right wall, every step you take get you to the wrong place faster.  We should have clear career goal in mind, so when we think of acquiring a skill we should look at the possible contribution of this skill in achieving the career goal.


Boston Consulting Group Products/Services Matrix
The Boston Consulting Group (BCG) Matrix is a well-known model that has been used for several years. It defines four categories of products/services based on their growth rate and competitive position,

Cash Cows
These are well-established products/services that have a strong market share but limited growth potential. They are stable and profitable. Projects that relate to cash cows are important to the organization because the company will want to protect that investment for as long as it maintains that market position.
On the same line, Person’s skills, which are returning profit in current market falls in this category, for example a coding skills of a developer. It is necessary to protect and enhance these skills, but it should be understood that these skill will not be enough for growth.

Dogs

Because these products/services are not competitive and have little or no growth potential, any projects related to them should not be undertaken. The best thing an organization can do with dogs is, phase them out as quickly and painlessly as possible.
First I thought that dogs are not relevant for skill portfolio management, but later I realized, we do need to identify skills which are not adding value to the current role, lets take example of a project manager, He is not expected to keep enhancing his coding skills, he should not be investing time in enhancing dog skills.

Stars
These are products/services that have strong market positions and clearly strong growth potential. Projects related to stars are good investment opportunities. Stars are the future cash cows.
Stars skills are the one which gives us future growth, the skills which has great growth potential. We need to invest our time in enhancing the star skills.
?
For both the cases, the question mark represents the starting point of the model. Products/services that are untested in the market but appear to have strong growth potential. The objective is to turn them into stars and then cash cows.


Conscious career planning can help us in achieving our career goals faster. Identification of right future skills is quite challenging exercise but we have to do it, there is no alternative to it.

Overview of Critical Chain Project Management

The Critical Chain solution to scheduling and managing projects was derived from a methodology called "The Theory of Constraints. Within any project, the Critical Chain is defined as the longest chain of dependent events where the dependency is either task or resource related. This definition assumes that the longest chain is the one that is most likely to impact negatively the overall duration of the project

One of the assumptions in Critical Chain is that a task time is not a deterministic number. It is an estimate. It means that any task that is part of a project cannot be predetermined to take an exact amount of time. sound strange? Most of us take pride in doing reliable estimates, but critical chain believes that the reliable estimates comes when people give estimates with padding, the 80 percent chance of meeting the estimate is often 2–2.5 times the 50/50 duration

In a Critical Chain project, management accepts that task times are not deterministic. Task times are guesses. Therefore, it is perfectly normal for task times to take longer than estimated. Management does not worry about whether or not a task finishes on time. They focus on finishing the project on time.

To make project finishing on time, the following steps are necessary:

 -Take all forms of padding/ buffers out of the task estimates.

 -Resource level the project. All tasks should be well resourced

 -Don't measure people on the accuracy of their estimates. 

 -Implement a project buffer to protect the project's Critical Chain. It sits at the end of a project and is calculated as a percentage of the length of the Critical Chain, typically 30–50 percent.

-Implement feeding buffers on each feeding path, to protect the Critical Chain from variances on any feeding path.

So the critical chain suggests to keep buffer at the end of the chain, say if we want to get to the office by 9 AM, we should plan our schedule in such a way that all planned tasks / activities of reaching office finishes by 8:30 AM, so the difference 9 AM – 8:30 AM will act as buffer and will    absorb the delay if happens at any stage on the chain.

In this diagram I tried to create a typical software project's activity sequence using the critical chain approach, here we are developing two use cases and integrating them at the end, In order to give predictable start date to Integration testing we need to have feeding buffer at the end of each use case development chain and to give predictable end date to the project we need to have project buffer at the end.

Buffer management is one of the important activities in critical chain projects. Every task in a Critical Chain project is connected either to a project buffer or a feeding buffer. When a task takes longer than estimated, it eats into the buffer that it is connected to. Buffer penetration reports indicate when the project is in danger. They also indicate which current task is causing the problem. Feeding buffers are shock absorbers on the noncritical paths; only after a feeding buffer is 100 percent consumed does the project buffer get impacted

Dealing with student syndrome

Student syndrome refers to the phenomenon that many people will start to fully apply themselves to a task just at the last possible moment before a deadline. This leads to wasting any buffers built into individual task duration estimates.

Parkinson’s Law … “work expands to fill the time available for its completion”

Our Projects do suffer from student syndrome, whatever we estimate the actual time tend to be more than the estimated one. Here I am sharing my view on dealing with student syndrome in project environment.

Setting of short term deadlines, short term deadlines or intermediate milestones provides effectively feedback about the project progress; these deadlines should be reviewed on regular basic, the duration depends upon the nature and stage of the project but we should not end up in micromanagement. Team congruence on short term targets is quite essential, it can be build by involving team in setting up short term deadlines.

Share the big picture, along with the short term targets, team should also be clear about the ultimate goal of the project and should be able to see path to it by meeting short term deadlines

.

Measure productivity, we should have model for measuring team’s productivity; once we start measuring it we can also improve it. This will put check on “work expands to fill the time available for its completion”

I kept reminding my team and myself "The more we sweat in peace, the less we bleed in war."

Scheduling of long duration projects

My aim today is to share some insight on scheduling of long duration projects.

The Purpose of scheduling is to provide a roadmap which represents how and when the project will deliver the project scope, Project Schedule establish the time required for the project. Critical Path Method is commonly used for project scheduling; The Critical Path method is scheduling network analysis technique which determines the minimum project duration.  For creating a critical path we have to define, sequence and estimate activities but It’s very difficult to foresee activities for a distant future say six months from now.

Here we need to understand two terms Rolling Wave Planning and Course-Grain Plan
Rolling Wave Planning

Rolling Wave Planning acknowledges the fact that we can see more clearly what is in close proximity, but looking further ahead our vision becomes less clear.

Fine-grain / course-grain

“Science requires different levels of abstraction for different phenomena.  Scientific theories can be big picture and course-grained like a highway map, or fine-grained like a local street map. Both are equally valid; they just need to agree with each other and conform to reality.”

– The Origin of Wealth by Eric D. Beinhocker

In software projects we do effort estimation using estimation model (UCP, FP, and transaction Point etc) and based on effort estimates we drive team size and project duration. Project duration is divided in various phases depending the software development methodology (iterative, waterfall etc) in use.  We should do fine-grain planning to the current visible duration and course-grain planning for rest of the project. The fine-grain schedule will have clear definition of activities, their sequence and resources which in turns gives us critical path of that duration of the project in course-grain schedule we should identify some critical milestones these milestones should not only  limited to phase ends but also include external and internal dependencies. All these milestones should be linked with each other and duration between two milestones should be estimated using estimation model. If we do so we can see the critical path of whole project even though we have not fine-grained the complete schedule, this helps in identifying the critical milestones (the one coming on the critical path )  and tracking project progress. If we don’t link the milestones till project end we may plan well the current visible duration but will not be sure of the conformance to course-grain schedule.

The schedule provides reliable prediction of dates and critical path only if the activity relationships or milestone relations are clearly defined and activity duration is know with higher degree of certainty, As we can not predict all activity durations with higher degree of certainty that is why we need to do schedule risk analysis on regular basic, the schedule risk analysis gives answer to questions like following:

• What is the likelihood of finishing the project as per schedule?

• What contingency need to be build to establish a completion date with a probability of success that is acceptable to the stakeholders?

• Which activity (or summary activity) is most likely to delay the project?

• What action can be taken to control risks in the schedule?

I will discuss my view on schedule risk analysis in detail sometime later but I feel we can not do effective schedule risk analysis if we do not maintain course-grain schedule with defined dependencies.