When I was growing up, I was told the bigger the goldfish bowl, the bigger a goldfish would grow. Keep the bowl small if you want to limit the goldfish size. Thinking back, it's a pretty good metaphor for my understanding of Parkinson's Law. The saying "Parkinson's Law" was first coined by Cyril Northcote Parkinson in his essay published in the Economist way back in 1955.

Work expands so as to fill the time available for its completion

This is what I see happening when developers or others have not decomposed their work to small enough chunks, in order to properly estimate their work. The same goes with meetings if people don't stick to an agenda.

Yesterday, I saw a (vendor's) manager trying to break the Parkinson's Law. Granted, I shook my head at his proposal but I admire the fact that he knows there is a problem and is trying to do something to correct it.

This manager has provided a (non-resource-loaded) schedule that has activities planned to conclude on September 30. The customer is not happy because new work of higher priority has appeared since the vendor provided their 5,000 lined schedule, several months ago. The customer does not have more money it can commit to new scope and they are unwilling to drop scope from the existing timeline. Yes, we all know customers do this. So, what was the vendor's proposed solution? Going forward, all estimates of work (previously identified and baselined in the schedule) will now have 10% less time to complete. Since they never allocated any slack for activities in their existing schedule, this will become their schedule reserve. Don't ask me where they got 10%. Tada! Now they have time to complete more work. Oh wait, you mean they shouldn't use schedule reserve in that way? No, they should not! And they shouldn't look at management reserve in that way either. I know some out there are going to have a heyday with this. It's not up to me.

I have to say, the vendor has done a very poor job with their predictive planning. But who is to blame them? It's not easy! I've found adaptive planning to be much more accurate. That 5,000 line schedule was out of date the day it was published. When I first looked at their estimates and later at their schedule, I new the efforts were grossly over-estimated. But, both the estimates and schedule were accepted by the customer. I do think the customer will now get more value for their money.

I got a kick out of the manager's response when someone in the meeting challenged him on the probability of people being able to complete the work in less time. Though I'm paraprasing, his response was

It's surprising, if I tell people to have their work finished by Friday COB instead of Monday COB, somehow they just seem to get it done.

That is a clear indicator that people on his team did not do their own estimates and the original estimates were more on the level of a rough order of magnitude (ROM). If it was my team, and I had made the same proposal, I would have had a revolt on my hands. The difference here is my team estimates their own work, within a few weeks of actually doing the work, and we ensure the work is in small enough chunks that the customer can see something of value in a very short period of time.

What kind of goldfish are you?

Small goldfish in a small bowl? (small group, small timebox, small deliverable)
Small goldfish in a big bowl? (small group, big timebox, big deliverables)
Big goldfish in a big bowl? (big group, big timebox, big deliverable)
Big goldfish in a small bowl? (big group, small timebox, big deliverables)

Image: PPT Presentations

I just reviewed an Integrated Master Schedule (IMS) comprised of almost 5000 lines. I didn't write the thing. I was just asked to review it. You might be saying to yourself that must be an absolutely awesome schedule, detailing every nuance of a project. Counter to that, you might be saying to yourself that is the most overdeveloped schedule ever creating, complicating the most trivial of work. In the business of project management or leadership, you should always be asking yourself, "does this make sense?" If it doesn't, you should be looking for the Goldilocks approach to documentation or process. Do something that is not too complicated or simple. Do something somewhere in the middle.

Don't make your schedule as complicated as a rube goldberg machine

As I read through the IMS, I started to think of a Rube Goldberg machine and the OK Go video titled This Too Shall Pass. Rather than reading a very straightforward schedule, identifying all of the deliverables and a decomposition ad nauseam, I saw a schedule that both inveigled and obfuscated. A Rube Goldberg machine is the perfect analogy for this schedule.

A Rube Goldberg machine is irreducibly complex. It is a single system which is composed of several interacting parts, and where the removal of any one of the parts causes the system to break down. If one component is missing, the machine doesn't work; the whole system is useless. This is NOT how an IMS should be written. I see a schedule as a tool of transparency. It is a way to communicate if a project is on time in a passive manner. A fully resource loaded (properly decomposed) schedule can help you do a lot of other things. But 5000 lines? I don't think so, not in this case.

Image Source: www.rubegoldberg.com