If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Article Series - Down n Dirty with the Theory of Constraints
Day Three of the Series on TOC in the Project Setting with Frank and Joe
Multi-tasking resources in contention is a principle source of throwing a project out of sequence.
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 team members 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.
? Guy Kawasaki wrote, "Less is the new more." Easy to learn: symmetry, seduction, subtraction, and sustainability. Very valuable to do. Step 1: Read Matt's book!! just 140 keystrokes.
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=03314884-90d1-47e5-acf3-2821313e9fdc)
![Reblog this post [with Zemanta]](http://img.zemanta.com/reblog_e.png?x-id=4ce3f392-8989-448a-a97a-c1432dd3fce6)
{ 4 comments… read them below or add one }
This anti-multi-tasking, ability-permission to say ‘NO’ and maturity (for hierachy and customer) to listen and accept this ‘NO’ constitute the biggest ‘paradigm constraint’ (as Hal put it) to tackle if one wishes to better their project management process (or all organizational processs for that matter). We are not talking about simple adjustments here, but a major cultural change where assertiveness has to take over a lot of submission and dictatorship reflexes.
When I talk about ‘reducing multi-tasking’ with fellow project specialists or my clients (employees and management alike), they usually answer back that multitasking is the way life is at work and cannot be changed, even by a few rules permitting a few ’substantiated NO’ here and there.
The aversion to say NO (which is translated into our mind as ‘I cannot say I cannot do what is asked from me, or the boss-client will think I am an incompetent’(for the worker) or ‘How dare you say NO to me…he! I’m paying you to do, not to not-to-do’ (for the ‘alpha-male/fe-male’)) is the single most-inhibiting ‘paradigm constraint’ to good management and to the implementation of TOC in organizations. It is the one I have personnally to work against everyday of my consulting life and the ‘Berlin Wall’ keeping us from promises that are realistic and that we can meet.(thus it does not mean, however, that it is undestructible but it is sure a tough cookie).
Implementing TOC is a major cultural change, one that is fiercely resisted by both workers and employers because it redefines traditional power-hierarchy relationships.
I had to be interrupted (multitasking dilemna). I cannot say NO to my wife when she asks for her breakfast, her coffee and her newspaper — all at the same time…power-hierarchy relationships, indeed !!!
To finish on a positive note (i’ll talk about YES
).
I found out lately that suggesting to my clients (and their employees) to say ‘YES…But’ instead of ‘NO…Because’ when asked to switch tasks was really better received as a strategy.
Instead of you having to explain why you cannot switch task now (the because), you get the ‘ASKER’ to figure out a way to rearrange (or at least reconsider) the priorities he/s-he(the alpha types!!) had imposed beforehand on you (the …’But’(in YES…But): such and such thing you asked me to do first thing first is now a close second or maybe a third and, Oh my God, it will sadly slip and be delayed by your own making !!!).
Food for thought
Claude
Hal —
What happened to your Wednesday post?
In answer to Frank.
Unhappily, my experience is a bit different. Might be either a cultural thing (I am dealing mostly with French Canadian outfits). Might also be that what I am working on covers more ground than TOC only, my work consisting in moving whole organizations towards implementing project management as a core business process, which means breaking a lot of habits, including tackling multi-tasking, which is always a huge habit to break when upper management just do not want to get their priorities straight. I used to believe that rational approaches like TOC, balanced scorecards, etc. could easily be implemented, once explained, but it just does not happen that easily for me.