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.
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 stories of crazy stupid processes that have taken on a life of their own and become a perfect example of “process for process’ sake”.
Related posts:
{ 23 comments… read them below or add one }
Love it mate.
Silly processes are the number one cause for my projects related aggravation.
Let's make a stand and bring this wall down.
Cheers, Shim
http://quantmleap.com/blog/2010/03/how-much-pro…
Nice post. I like your simple step 1, step 2 approach. It is too bad each and every process does not have the single Process Owner with the mission in life to do what you describe.
Your post inspires me to share a more in-depth discussion of battling the “process for the sake of process” problem. http://bit.ly/aDGVDb
I am looking forward to your next rant.
Steve Romero, IT Governance Evangelist
http://community.ca.com/blogs/theitgovernanceev…
Josh
Don't forget about the things that is feeding the system. Sometimes the reason bottlenecks appear are because of the standards or objectives that drive the very existence of the system in the first place.
Perhaps, but those standards or objectives had better be adding value!
Thanks Steve!
I love this from your post Shim:
“Let’s be honest about it, in many cases, we are so process-holic because we are concerned about the consequences (to us personally) should something go wrong at a later stage and the wolves will be out to look for the scapegoats.”
Perfect. I think a good question to ask is “does this add value, or is it just a CYA activity?”
I think another problem is that we sometimes try to make processes idiot-proof, as you said we want the processes themselves to eliminate the likelihood of human error. But when we engineer processes without much regard for the actors involved or any factor of TRUST for them, we end up with requiring signatures to pass a document from one desk to the one beside it; seemingly unaware of the capacity for the people involved to TALK to each other.
-Josh
Well … where's the meat? What was the process that set you off? Why was it created? When did it stop providing value? Does it provide value to others even if it doesn't provide value to you? Has the bottleneck always been there, or is it new? Have you explained the issue carefully to the process owner in terms that they can understand? Have you proposed an alternative?
Great points Bill. I generalized my rant of course, as sharing specifics publicly would be ill-advised. All of your points have been considered and addressed, however in this case it seems to be a process I'm going to have to live with.
I try to remember something an Sr. Executive VP told me as I was updating him on the status of the program I was working on for him: “Complexity is a dissatisfier.”
Our “profession” attracts people that see inherent value in sometimes overly-complex processes that do not add real business value. Sometimes I wish Lean and PM were more intertwined than they are – there are high-value activities/processes that apply across projects of any size, but arguably scalability is not front of mind in most PMO's I have worked with.
You didn't speak to the value produced by the process and the exchange of effort for that value. Process improvement MUST address both sides.
And the picture you provided is old, very old. But it actually represents a “close of day” process for a brokerage house.
You can only measure waste against it produced value. Waster > 1 IIF Cost > Value returned.
As well productivity is not the first assessment point. An overly productive machine tool will produce too many parts and they will sit and rust if the assembly process can't keep up. I know this as a fact, since I was the naive process improvement engineer at an oil tools manufacturing firm that clearly didn't comprehend the “system” aspects of the process.
Rarely if ever is the solution as simple as the steps you've described.
My pet peeve here is detailed time tracking. Many CFOs forces people to do time tracking in a very detailed manner, often it is brought to an hour-level or even further – every quarter should be assigned to some activity. Thinking behind this approach goes like that: if we gather very detailed data we would be able to analyze costs very accurately.
And that's complete bullshit. I don't know anyone who does time tracking every hour (or quarter) writing down what they've done past hour (quarter). It always ends up with filling data weekly, when people are disciplined, or monthly, if they are not. Now, a question: how precisely you can say what you were doing three weeks ago between 10 am and 11 am?
And that's exactly how precise data CFOs get.
I've seen no evidence that hour-level time tracking produce better results than week-level time tracking. The only difference is how painful it is for people and how much time they waste doing time tracking.
Once I had power to arrange time tracking as I wished. We did it monthly and I wanted only a percentage of month folks spent on specific projects. Like 50% on project A 30% on project B and 20% drinking coffee and chatting with colleagues. If one was lucky and worked on a single project during whole month it took her about 15 seconds to fill the time tracking app for that month. And I got the same results as I would if I forced her to fill 160-so records for each hour.
Detailed time tracking works as a perfect example of process for process' sake.
This is an interesting one. I struggle sometimes with the cost in time and frustration for people to track their time in a detailed way, with the potential benefits in the form of information for future estimating purposes. As a rule of thumb however, I tend towards time tracking at higher levels as you described.
I am going to try out a hybrid approach soon, using daily stand-ups and the meat of running sprints to collect daily status as a means to record hours worked on individual tasks without being onerous and while reaping the benefits of a daily 15-minute tag-up.
-Josh
Josh, that sounds counter productive to me. You’ll potentially break – or subvert – the stand-up process.
Some questions:
What’s the problem you are trying to solve?
What value does the 15 minute stand up provide and how will adding task time reporting improve it?
What alternatives have you considered?
Thanks Craig. Since I posted that comment last May, I’ve implemented Kanban with all of my project teams and am loving it. It worked well to try and gauge time worked and time remaining when we were time-boxed (I was using an excel spreadsheet I created to track this) but now I am not doing this at all. We use GForge and my teams keep track of their hours spent in there…but I use planning poker and iterative estimation as a pretty darn good way of keeping our future plan realistic, rather than relying on extrapolation from “actuals” gathered in the past.
“I don't know anyone who does time tracking every hour (or quarter) writing down what they've done past hour (quarter).” Then I guess you don't know any lawyers.
Actually, lawyers generally track their time in 6 minute intervals.
The fact that you don't feel a need for detailed time-tracking on YOUR projects doesn't mean that it might not provide value for someone else. Nor does it mean that the fault is with the CFO (or CIO). YOU don't see value (and there may, indeed, be no value to you), so you will never get value.
Perhaps the CFO sees value? I don't know too many CFOs who actively implement practices that will increase corporate overhead. That is clearly a career-limiting-move on their part. Maybe the CFO has simply failed to communicate to you how they would like to see the information used?
By way of comparison … most USDoD contractors complain about the “unnecessary” overhead of having to report EV monthly. They say there is no value. The PM for one of Boeing's largest military projects reports EV weekly because he sees value: it allows him to be more responsive because he finds out about issues right away rather than with a 5-8 week delay.
Time-tracking is easy if you do it while you are working. I track my own time by client and by task in 15 minute intervals. It typically takes me 1-2 minutes to record my time at the end of the day: 10 minutes per week for a wealth of information that helps me manage better … and that also ensures that I am able to bill for all the work I do. Now, that's VALUE!
So … as I said … detail time-tracking may, indeed, be a waste for you. I would agree that it is often a waste on small projects where the PM is intimately involved in all the details, and on projects with no real budget constraints. But to make this statement: “Detailed time tracking works as a perfect example of process for process' sake” without any kind of qualification. Nope. Not true.
Well stated Bill. Do you find keeping track with pen and paper most effective, or is there another tool you use?
-Josh
CYA!!!
Pen and paper plus a spread sheet that converts time entered as numbers into hours. So I enter 11.45 and 13.15 and the spreadsheet computes the difference as 90 minutes.
Pen and paper plus a spread sheet that converts time entered as numbers into hours. So I enter 11.45 and 13.15 and the spreadsheet computes the difference as 90 minutes.
Ahh… time tracking…
An alternative to time/hourly oriented time tracking is task or product oriented measurements.
Instead of saying what did I send my time on, ask how long did it take to produce the last widget I just produced. (and what did I estimate at the beginning and how accurate was my estimation, and what changed from my initial plan?)
BTW – here’s my related post
I also dislike overuse of citing “policy” to protect the way xyz process has always been done.
Absolutely Taz. We should always ask “why?”