Parkinson's Law

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?

1. Small goldfish in a small bowl? (small group, small timebox, small deliverable)
2. Small goldfish in a big bowl? (small group, big timebox, big deliverables)
3. Big goldfish in a big bowl? (big group, big timebox, big deliverable)
4. Big goldfish in a small bowl? (big group, small timebox, big deliverables)

Image: PPT Presentations

Intro to Value Stream Mapping

I'm in the process of doing a Current State Value Stream Mapping (VSM) for the PMO. The big questions are, based on the current state, are there areas we can improve? Can we eliminate any waste (or increase efficiencies) from our current processes? The answer to both questions is YES.  Everyone should be reviewing there processes on a regular basis, giving themselves opportunities to become more profitable.  Though I'm advising a Federal Government project, the American people still deserve the most bangs for their bucks. Today is the last day for one of my projects.  It is done.  Now is the time to see what worked and what did not.  We now need to do a retrospective and see if we learned any lessons from the last go-around. I will give the vendor credit on this particular project. This small cross-functional team did a better job than others, in part, because we had a daily 15 minute status meeting. (otNay allowedway otay entionmay Agileway). One of the other program teams wastes so much time because they only communicate once a week in a 3 hour meeting.  I hope my VSM will change that.

For those new to Value Stream Mapping, I included a 5 minute video that does a pretty good job of explaining its value.  See how a process that took 140+ days to complete was shortened down to just 30 days.

If you don't have your current process documented, you need to do it!  As the saying goes, "What cannot be measured cannot be improved".  Don't be complacent and accept the waste.  Times are tough and we need to think lean!

Like the drawing? Get it free at Pictofigo

What is in a Name

This weekend, I took the first step of rebranding myself. Some know me as Derek Huether the "PMP"; some as Derek Huether the "CSM"; some even refer to me as The Critical Path blogger or Zombie PM. With the real risk of the Federal Government shutting down this next week, I'd be an idiot if I didn't eat my own dogfood and have some kind of Risk Management strategy.  Though I may have to "accept" the risk, I will do what I can to mitigate it.

Because I am NOT a government employee, if there is a shutdown, I will NOT get paid.  When I heard about a possible shutdown, I remembered the similarities between grief and risk.  So, what needs to get done?  I need to get my resume and social links updated.  Wherever my name is, I need to make sure the message I'm sending reflects my current frame of mind.

When I look at LinkedIn profiles, it appears some people really love adding initials after their names.  I saw one fellow had no less than 6 acronyms after his name.  Though people in the industry may understand this alphabet soup, I think many are just annoyed by it.  I did a search on him and he really had nothing to say (publicly).  So, who is this guy?  What I see happening is he'll be loaded into a database with everyone else and he'll become nothing more than a keyword search.

Though I admit, that could happen to me as well.  I'll do what I can not to pander to it.  I think people should be hired because of their personalities or because they are good culture fits.  I wouldn't want to be hired because a hiring manager needed a body with a PMP or CSM.

I'm not going to turn my back on what I've learned over the years.  I will still champion the baseline information the pursuit of these certifications or accreditations exposed me to.  But, I'm not going to continue using them in my name.  It's just not who I am.

PMI Agile Project Professional Survey

The Project Management Institute (PMI) finally made the public announcement that they intend to have an Agile Project Professional "APP" certification. Surprisingly, I have heard very little negative feedback. My questions? Do you think this new certification will be good or bad for either the Agile Community or the Traditional Project Management Community?

I created a survey form in Google Docs. After you enter your choices, you will have a chance to see what others selected. I thank you so very much for participating!

Regards, Derek

Thank you for your interest. This survey is now closed.  Here are the results.

Like the drawing? Get it free at Pictofigo

End Of The World As We Know It

After the public announcement last night, that PMI intends to create an agile project management certification,  I heard REM playing in the back of my head.  "It's the end of the world as we know it and I feel fine".  Though I will admit I was a bit nervous when I learned PMI was going to do an Agile certification, back in October (2010), I made my peace with it.  I came into the picture toward the tail end of the PMI Agile Project Professional (APP) process.  As Mike Cottmeyer stated on his blog,

We’ve had a ton of really smart people involved, people you’d know and respect in the agile community.

Those people worked really heard and I applaud them for their efforts.  As an independent reviewer of the competencies, techniques/tools, knowledge and skills, I can personally assure members of the Agile community that PMI is not trying to rewrite Agile as they know it.  It's not perfect, but it's a pretty damn good version 1.0!

For those who were not at the PMI North American Congress back in October (2010), there was strong representation by the Agile Community of Practice and a lot of curiosity, and might I add ignorance, by the average Congress attendee.  I didn't find it surprising, considering there is a complete omission of the word “Agile” in PMI’s Project Management Body of Knowledge (PMBOK®) version 4.0.

It is my hope that this new certification will provide that baseline understanding of Agile for many.  I do believe this is a step in the right direction.

Like the drawing? Get it free at Pictofigo

Meetings: Get To The Point

Upon a brief review of my site analytics, I noticed something striking. For the month of February, almost nine percent (9%) of my page views are for one thing:  Free Meeting Minutes Template Back in March 2009, I wrote a post about helpful tips for running a meeting.  With it was a free copy of my meeting minutes template.  So, I think it's time for a brief refresher with a few updates.

When Hosting a Meeting:

[1] Write out the purpose of the meeting with actionable events in mind. e.g. “Provide an updated status, identifying risks and opportunities, and identify new action items.”

[2] Identify your attendee list but only keep those you can map to the actionable events listed in step 1.  There is a difference between an attendee list and a communications distribution list.

[3] Create an agenda.  Never schedule a meeting without a written agenda. A meeting without an agenda is inefficient and a waste of time.

[4] Identify who will run the meeting and who will take notes. It should not be the same person.  Both people should know their roles before the meeting begins.

[5] Ensure discussion points align to the agenda. If the conversation drifts off topic, recommend taking the discussion to another forum.

[6] End the meeting by having the note taker read back discussion points and the action items. Make sure there is a consensus before the meeting ends.

[7] Send out the meeting minutes within one to two days. Consult your distribution list to ensure all necessary people get a copy.

As a disclaimer, I hate meetings.  Many are unnecessary.  But, when meetings are necessary, get them done as quickly as possible.  Get in, get to the point, get out, get back to work.

Bonus Recommendations:

[1] Start on time. If you don't start on time, you can't finish on time.

[2] Do not schedule your meeting to end at the top or bottom of the hour. I'm a fan of the 22 minute meeting.  Have meetings end a little early.  Some people need to get to other meeting and this will help prevent them from being late.

---

Team-Based or Value-Based

I'm currently reading a book about Systems Analysis and Design.  In a chapter discussing Agile Methods, one of the statements really rubbed me the wrong way.

The Agile Manifesto is a set of team-based principles...

For the last 6 or so years, I've assumed the Manifesto was a set of "value-based" principles.  That is, at its core, Agile is about delivering value or eliminating waste.  What I like about the Manifesto is it leaves a lot to interpretation.  It doesn't spell thing out to the N^th degree.  But, I'm very curious what the community thinks.  How would you describe the principles?

Please leave a comment.  Tell me what you think.

---

Project Management Joke

So the NCI Research Fellow and the PM Blogger are having beers.  The Fellow turns to the Blogger and begins to describe the structure and function of viral RNAs and their interactions with proteins with a focus on the identification of new targets and the development of novel anticancer/antiviral strategies.  The Fellow asks the Blogger if he had ever heard of the polymerase chain reaction (PCR). The  blogger says no, and then received a high level summary of what PCR was. After a few beers, the the Blogger turns to the Fellow and begins to describe different methods of project managers and leaders and how they may interact differently with a team, depending on the project.  The Blogger asks the Fellow if he had ever heard of Agile practices or approaches. The Fellow says no, and then received a high level summary of what Agile was.

So, that is where the joke ends.  This really was not a joke.  After a short discussion about fast zombies versus slow zombies, Dr. Legiewicz and I found ourselves talking shop.  We talked about recent conferences we spoke at and about how things have changed in our jobs.  We started our careers following one set of practices and have watched how techniques have developed, matured, and evolved.

Dr. Legiewicz stated, when PCR was developed in 1983, nobody saw its value.  But, it is now a common and an often indispensable technique used in medical and biological research labs for a variety of applications.  I told him that Agile techniques sound like they may take a very similar path.  Being Agile just celebrated 10 years of the Manifesto, I have seen a lot of acceptance in just the last few years.  Could it be that it to shall become common and an often indispensable technique used on projects for a variety of applications?

Or, did Michal and I just have too many beers?

Like the drawing?  You can get it free from Pictofigo