I am dealing with some particularly frustrating bureaucracy and broken processes at the moment that I have no direct control over, so allow me to vent.
This is what it feels like: 
Theory of Constraints, Save Me!
Let’s see about a general approach to identifying waste and delays in trying to achieve a particular outcome, whatever that might be.
Given
Any system can produce only as much as its critically constrained resource. ~Theory of Constraints
And
The processes used to manage your project constitute a system, including support processes.
Therefore
Each individual process must contain a critically constrained resource (bottleneck).
So
Start with the one process that causes the most disruption and cycle time lag in your project.
And
Identify the bottleneck in that process.
Then
Elevate the productivity of that bottleneck to break the constraint (which moves it to another resource in the process while reducing cycle time for the total process). Or eliminate this step if it does not add significant value to the end product.
Continuously
Seek out waste in a similar manner across your entire project and support processes. Never add process unless significant value is added to the end product.
Thank you, I feel better now. But I’d feel even better if you shared your own thoughts and woes of dealing with crazy stupid processes.
image source
1. Alexander the Great, when challenged to untie the Gordian Knot, simply withdrew his sword and sliced it in half. Got sword?
2a. Email all concerned your flowchart. 2b. Ask what parts can be eliminated. 2c. Of course some people won’t empower/will continue to unempower your progress. 2d. Ask your boss for more time, more money, and lower standards.
What did I miss?
Love it Carol, “Got Sword?”
I don’t get 2d though. Lower standards shouldn’t be a part of it, and as a result of doing this you should have more time and funds within your current budget.
Can you explain more about what you meant by 2d?
Eli Goldratt’s novels showed that the Theory of Constraints often requires nonobvious change. On thing to take into account is the zeitgeist or spirit of the times.
I think some of the frantic maneuvering in about-to-be-downsized is the discomfort of not knowing how it will play out.
What I’m seeing is a 70% decrease in bodies, and none of the remaining people have the skills that are required. Figure on a complete change. No happiness in that scenario.
Good post, Josh!
I feel your pain.
…(so, adding my rant to yours):
My issue in projects is this:
Do the proven PMI process groups, in order:
1. Initiate (actually write a charter to empower a PM and set the scope)
2. Plan
3. Execute
4. Monitor & Control
5. Close
In the Army, we tend to (as Alexander w/ sword) just “move out and draw fire!”, i.e.
1. Execute…
But beyond the importance of PLANNING to eliminate rework, I’m learning that if you don’t INITIATE correctly and scope/empower up front, you’ll end up chasing your tail there as well, creating more rework, scope creep, and a process map within your project that resembles yours above.
In the age of downsizing, we have no time for rework, so can we just do it right the first time?!? ..pleeeeease?!?…
Is that chart available in 11 x 17?
@Dick, glad to see a fellow TOC fan. The sad thing is that by moving towards a truly Lean agency, the result should be the ability to do more good work with the same staff. It’s important that be the case, as opposed to downsizing as a result of process improvements. If you do that, the change will never be successful in the first place, because everyone will be in fear for their jobs. It can only work if it’s made crystal clear in the beginning that the result will be to do more with the same, not the same with less. And people have to trust their leaders enough to believe it’s true.
@Eric, in project work I like the deferred commitment of detailed plans until the last responsible moment. Lean is what makes sense to me, and I’m trying to move things in that direction in the work I do. I think a short iteration cycle is the best way to go, with a plan-do-check-act every time. What I don’t like are big waterfall approaches where we design months or years ahead of execution. In those cases, that plan-do-check-act cycle becomes many months or even years long, which is the cause of much wasted effort and rework.
@Dannielle, http://www.basement.org/2005/12/weird_naked_white_collar_guys.html#trackbacks
Thanks. I got the graphic as a .GIF but let it go. If I post it as a joke, someone might actually be inspired.
LOL @Dannielle!
I’d +1 what Eric said. And the key is that planning isn’t just planning for execution…but planning to achieve a specific outcome that actually links to advancing the mission..so that’s it’s not just doing for doing’s sake. (Yes! We got that done. Yes, but did it make a real difference?)
Thanks Andy. Quality and value must be defined from the perspective of the end user/customer — otherwise what’s the point?
If you are required to work through the labyrinth, show it to your boss and ask either for less specification, more time and money. If he can’t give you less specificaiton he should give you more time and money.
Thanks Carol.