 Reforming Project Management |
||
|
|
||
|
Friday, April 18, 2003
Customers, Promises, and TOC
Final remarks on the series on Theory of Constraints
Frank, Joe, and I had fun blogging collaboratively on the Theory of Constraints this week. We hope you enjoyed it too. I want to underscore one point Frank made yesterday. (M)y role in this series is to remind you that the reason we're doing the day-to-day work lies at the end of a string of days -- at the end of probably more than one chain of tasks -- and that while dealing with the current and immediate constraints, how we do so must take into consideration their import and impact on the larger constraints of the project as a whole.We do projects to make good on a promise to a customer. The big promise at the end of it all. This is easy to see when a customer contracts for a new building. The customer is obvious, so are the conditions of satisfaction. But what about internal projects? So often on internal projects someone has a good idea. S/he assembles a team. And they go to work. This doesn't mean it's a project. If you don't have a customer acting as the customer, then you don't have a promise, nor do you have a project. If you don't have explicit conditions of satisfaction for fulfilling the promise, then you don't have a promise, nor do you have a project. We make all kinds of mischief (waste) in companies when we don't take care to be explicit about the customer and the conditions of satisfaction. So, as we leave the subject of the Theory of Constraints remember that none of what we discussed this week matters when we act without a promise to a customer. Stop by and see what Frank Patrick and Joe Ely are up to. Thursday, April 17, 2003
Down 'n Dirty with the Theory of Constraints (part 5)
Projects are always constrained. Accept it. Now what?
We've discussed three types of constraints, the focusing process for managing constraints, and the perils of multi-tasking in a world that work is not ready. Now what? Let's consider some practices we can employ on a day-to-day basis to operate successfully in the uncertain world of projects.
Particularly on large or remote projects you can't watch everything all the time. Status reports are rear-view mirrors. By keeping your eye on the constrained resources you will have your hands on the leverage point for your project. Manage the project in a way that keeps the constraints busy performing what should, can, and will be done. Wednesday, April 16, 2003
Down 'n Dirty with the Theory of Constraints (part 4)
Multi-tasking can be eliminated (Ok, maybe significantly reduced)
We've been discussing constraints, resources in contention, and multi-tasking. Frank's posting yesterday showing the red, green, and blue tasks shows clearly that multi-tasking delays completion of some activities with no advantage to others. How could it be reasonable to follow a rule that resources in contention can only work on one thing at a time? Particularly in the world of projects where we often don't know what is needed from that resource 'til the last minute? The trick (technique) is to always have the work for a constrained resource in a condition to be started and finished PRIOR to the resource starting. Have you ever watched a person climb a ladder only to have to come down again to get materials or tools? Have you ever been asked to do something for someone and the person wasn't able to tell you what it meant when done is done? Joe offered this example yesterday: The key? Making work ready for Loren to work on it. We have instituted standards for him to work on a request. No specs for the loading of a roof?? No truss analysis. Wow. That's a shock to the system of those who were used to calling and letting Loren work on unclear requests. But it is vital. If we have a true constraint then there must be a queue of ready work in front of him.By queuing up ready work for people (resources) they can start work that will be finished. Finishing work on projects usually means work is released for others on the project. Further, when work is in a condition to be started and finished, the work gets finished reliably. But how do you do that? How do you know ALL of what needs to be done? You as a project manager alone don't know. You plan with a team of people who are responsible for assigning work on your project. You do this every week looking out a month or so. In these conversations you will discover what resource will be constrained and what is yet to be addressed for making the work ready. These are the conversations to assign responsibility for addressing each of the issues that keeps the future work from happening as intended. Tuesday, April 15, 2003
Down 'n Dirty with the Theory of Constraints
Day Three of the Series on TOC in the Project Setting with Frank and Joe
The lift story was an example of a temporal constraint. We call these resources in contention (RIC). There could be plenty of overall capacity for performing over the life of the project, but at any given moment two or more actions must be taken by the same resource. Engineers find themselves in this dilemma. An engineer may be asked to get 2 (or more) tasks done for the same or different projects in the same time window. Trying to please both parties by getting a little done on each everyday, the engineer fails to get either done on time. On the surface this only looks like a physical constraint. But is it? There may be a 'policy' to always please the customer. That policy gets interpreted as not saying "No" to a request. Further, engineering organizations are often run to maximize the amount of time spent on engineering. To do that, they build up work queues for each engineer. This necessitates a practice of starting and stopping and then restarting. Does it sound like waste? It is. Multi-tasking resources in contention is a principle source of throwing a project out of sequence. Projects that get out of sequence get delayed. So what can we do? Know who (or what) are the resources in contention on your project. Apply the five focusing steps to them. And, do not let them start one task before they finish the task they are working on. Sound crazy? We'll deal with that tomorrow. In the meantime check out these two TOC resources: CIRAS and TOC Dictionary. Then go see Frank's Focussed Performance Business Weblog and Joe's Learning About Lean. Monday, April 14, 2003
Down 'n Dirty with the Theory of Constraints
Exploring the Theory of Constraints in the Project Setting (second in the series) with Frank Patrick and Joe Ely.
Physical constraints are not the only limiting effects on projects. Eli Goldratt identifies two other types: policy constraints and paradigm constraints. Let's work through an example. On a multi-story building job site there will be an exterior man-lift for carrying workers and material up and down the building. Large jobs might have more than one lift. We can begin to understand the lift as a constraint considering it only holds 8 people. If there are 80 people to travel on the lift it will take at least 10 trips to get them to their place of work. It will take more trips when the lift is not full. On the surface this looks like a simple physical constraint. But is it? On most job sites the policy is for workers to start at the same time. While some people will come early to avoid the rush, which will only succeed if one of those people is the lift operator, what inevitably happens is a queue builds every morning, at lunch, and again at the end of the shift. What if the policy was changed? Perhaps the iron workers would come in first, followed by the plumbers five minutes later, followed the electricians, etc.? The end of their workdays would also be staggered. While there could be a bunching up due to variation in the arrivals of the individual trades, you wouldn't have less lost time waiting for the lift. Still, iron workers, plumbers, and electricians will likely be scattered across a number of floors. Bunching by trade will result is losses in travel as folks are dropped off on different floors. So what about paradigm? We live in a world that thinks whoever is in line first gets to go first. Further, if the lift is there, then one can ride it. Are these stated explicitly? No. But we do operate that way. What if we change the rules for riding the lift? Let's say it is reasonable for people to walk up one flight of stairs and walk down two flights of stairs. On what floors would the lift need to stop in a ten-story building? [think] In the usual case of first-come, first-served, a mixed group of people get on. Each time the lift stops some people get out, while others must wait to ride to their floor. That waiting time takes away from operating time. Adopting the proposed policy changes that. The lift only makes two stops - the fifth floor and the ninth floor. A policy could be added to have people arrive for travel to the fifth floor at one time and the ninth floor sometime later. That would reduce the waiting time for the lift and the waiting time on the lift.
In this example we turned a physical constraint first into a policy constraint, then into a paradigm constraint. Make your constraints disappear in the same manner. And, remember to check-in on Frank and Joe. Sunday, April 13, 2003
Down 'n Dirty with the Theory of Constraints
The first in a five-part series on applying the Theory of Constraints in the project setting.
Projects of all types get bogged down. Something happens - unexpected - that puts the team members into a react mode. From there it is all downhill. While many people will offer good advice (they've got no skin in the game) few can offer a perspective that can keep a project on track. Enter the Theory of Constraints. In the simplest terms think of a constraint as a restriction to flow. A bottleneck restricts the flow of liquid. Widen the neck and the bottle is emptied faster. Cranes are an obvious possible constraint on construction projects. Anything that must be lifted has to be carried by the crane. On any given day there may not be enough crane time to move all the material desired. Therefore the crane restricts the amount of work that can be performed in the day. These are the physical constraints:
We manage our physical constraints through a five-step process of focusing.
Now visit Frank Patrick and Joe Ely for their concurrent postings on TOC for projects. Visit the Archives for more postings |
 Reference Papers
|
|
| ||
