Brooks' Law

I was looking for something on the SEI website and came across a piece about Brooks' Law that caught my attention.  Brooks’ law is a principle in software development which says that “adding manpower to a late software project makes it later”. It was coined by Frederick P. Brooks, Jr. in his 1975 book The Mythical Man-Month.  You may have already experienced it but never put a name to it. I would fall under that category.  I've seen Brooks' Law happen first hand but didn't know it had a name.

The vendor was doing predictive versus adaptive planning.  They did a very poor job of estimating.  Since the customer accepted the estimate, it was just a matter of time that the house of cards would come crashing down.  As time progressed through the period of performance, we saw the vendor reach each milestone later and later. (They were following a waterfall approach)  At each status meeting the vendor was pressed for an answer to the question of how they were going to recover the schedule.   When it was painfully clear that the vendor could not complete the scope of work (within the alloted time), even if they convinced their people to work nights and weekends, they proposed to bring on more people to take care of the backlog of work.  That's right, they were going to bring on a small army with no experience with the customer, the program, or the product.  They were going to blow the budget, in the hopes to recover the schedule on the currently agreed upon scope of work.

One stakeholder was very candid when he said, during a status review

It sounds like the plan is to throw as much [something] at the wall as you can and see what sticks.

It's rather sad that the vendor looked at this as such a simple equation.

Team A (Input) + Team B (Input) = Team A + Team B (Output)

In reality, the equation looked more like this:

Team A (Input) + Team B (Input) = [(Team A * .75) + (Team B * .50)] Output

Have you seen Brooks' Law on your project?  What was the outcome?

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

Assumptions and Constraints

I turned to my wife last week and asked what our plans were for the weekend. She countered by asking me if there was anything specific I wanted to do.  My answer was I wanted to eat somewhere featured on Food Network's Diners, Drive-Ins, and Dives.  One quick search and a YouTube video later, and we had our Sunday planned. We were headed to Baltimore for lunch at Di Pasquales Marketplace. I could taste it all now. Mmmmm, homemade paste, sausage, and mozzarella.  After lunch, we'd head to the Inner Harbor and enjoy the beautiful weather. This is where my personal story ends and my project management story begins.  As I've said before, everything in life points back to project management.

Imagine our weekend adventure was a project.  We planned our little outing for Sunday.  We assumed Di Pasquales was open on Sunday.  We were wrong.  We discovered if we wanted to go to Di Pasquales, our time constraint was Monday thru Friday: 9 a.m. - 6 p.m. or Saturday: 9 a.m. - 6 p.m.  Fortunately, we had a plan B.  Always have a plan B! I added our trip to the backlog and we picked the next highest priority from the list.

Here's my little read world project management advice for today.

1. Don't start a project, until you know your assumptions and constraints.
2. Get buyin from stakeholders to ensure you are all in agreement on priorities.
3. When making a proposal, always have a plan B.

Since we were not able to go, perhaps we'll go next weekend.  Regardless, if we had not identified our assumptions and constraints, we could have found ourselves eating somewhere less desirable and "wasting" the day.

Passing the Test of All Tests (PMI Audit)

He who pulls the sword from the stone shall be a PMP

So, you just completed all of the paperwork, detailing all of your applicable education and work experience.  PMI has given you the green light to schedule a date to take your PMP® exam.  But what if you are audited?  Wouldn't that just suck!?

Well, you met the requirements.  PMI didn't say anything so you must be in the clear.  Time to sign up to actually take the exam.  Through a link on the PMI website, you pick a testing center in your area and find a time that will work.  You enter your credit card number and click submit.  Surprise!  Instead of getting a confirmation page, saying thank you for paying for the exam, you get a "you've been audited" screen.  What the hell!?

So, as soon as they have your money, you go into audit limbo.  The audit process has started and there are only two ways out.  [1] You withdrawal your application to take the exam.  You will get "most" of your money back. [2] You complete your audit, submit your paperwork, and PMI allows you to take the exam.

With all of the figurative threats PMI publishes about not embellishing your experience, you better not have done it!  I would compare this to going to a job interview.  Your potential employer says they like what they see.  You can continue on in the interview process, as long as you take your resume back to each of the employers you've listed and get them to sign a document agreeing you actually did the work.

What if your application is audited?

PMI answers a group of questions about this. First things first, stay calm. If you didn't lie on your application, you have little to worry about.  You should have honestly detailed all of your work experience during the application process. For every project you submitted, you're going to be sent an audit report in PDF format. (see the 3 graphics to the left)

Page 1:  What you entered during the application process.

audit_page1

Page 2:  Stakeholder information and a line for them to sign, agreeing you did the work that you say you did.

audit_page2

Page 3:  PMI Address information.

audit_page3

The pain of original signatures

For every one of these packets, you're going to need 2 original signatures.  You can have a colleague, peer, client or sponsor who has intimate knowledge of the project sign the audit.  You will then put the signed audit into an envelope (addressed to PMI), seal it, and have the same person sign the sealed envelope seam.  Once you get all of your packets signed, sealed, and signed, you mail all of the envelopes to PMI.

The actual audit by PMI will only take about a week. You will receive an email notifying you if you pass or fail.

What is my advise?

Go into the application process with the expectation of being audited.  Identify the people you want signatures from while doing your application.  Identify a backup (signature) for each project.  I spent more time tracking people down and getting signatures then I did completing the original application.  I had 20 signatures I had to get.  When budgeting the cost of the PMP exam, don't forget the cost of dinners and drinks for people who you need to track down to sign your audits.  I had to manage my audit process like I would a mini-project.

Is it all worth it?

From my personal and professional experience? Yes. Though I do believe the ever-increasing number of PMPs in the market may commoditize the certification, it's still in high demand. Regardless if you're a good PM, if you have a PMP® or CAPM®, there is an assumption you're a good Project Manager.  Because I was audited, I feel everyone should suffer the same scrutiny.  Perhaps there will be fewer paper PMPs, if they knew up front they would be audited.

Thank you to Joseph Gruber for verifying the current audit process.  He also suffered through a PMI audit.  I remember the PMI audit process being a little different, when I went though it back in 2006.  His personal experience was very helpful.

Did I miss anything specific you wanted to know?  Just leave a comment.

(Yes, that's a picture of me pulling the sword from the stone)

Refine Your Process If You Must Deviate From It

As I mentioned in my post yesterday, Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations. Merriam-Webster defines process as a series of actions or operations conducing to an end.  If you are unwilling to modify your process, the deviation is unworthy of being done. I've had a vendor tell me they didn't need to document their processes because they were agile.  (Notice the lack of an uppercase A in Agile).  Leveraging Agile concepts does not mean a lack of documented process.  IF the customer tells me they see the greatest value in delivering documentation, what is this vendor going to respond with?  Sorry, we won't deliver value?  If you use Waterfall, you may be used to generating more paper.  You have to consider documentation on a case by case basis.  Some customers have legitimate needs for documentation and other have wants.  Now go back and read that last sentence again.  Needs...Wants...

I personally like to go light on documentation.  What I need and what the customer needs are usually two different things.  That being said, I like to understand the rules (governance) before I start anything.  The Microsoft Visio document I included in my last post was a good example of a high level governance (functional flowchart) document. After completing the flowchart, I then detail each activity in a separate document.  What is the input and output?  Is there a formal deliverable associated with the activity? The idea behind the separate document is you won't need the flowchart to describe the process.  For those who have successfully navigated a SOX audit, you know what I'm talking about.  But I digress.  The flowchart activities I documented are not groundbreaking.  The process in this case is an Agile Scrum process with a few defined quality assurance decisions points.  You do not need to go into the Nth degree to understand this process.  Identify some touch points where the vendor and customer interface.  Identity some decision points.  That's it!

I've done these flowcharts for several customers.  I've created them for both Waterfall and Agile development approaches.  If you're looking for a free Microsoft Visio template, which you can edit at will, you can download it here. I zipped it to make downloading easier.  If you're looking for other free templates or worksheets to use on your project or program, you can download them there.

What do you think?  To document or not document.  That is the question. I welcome your comments or feedback.

Regards,

Derek

My Merge of GTD and Kanban

I'm not going sit here an boast of being some kind of expert on Kanban or guru of personal productivity.  I'm just a Project Manager/Leader who is always keeping his eyes and ears open for newer or better ways to manage time or work.  I believe you should always try to eliminate non-value-added processes, resulting in a positive impact of customer satisfaction, while reducing support costs.  How do you do that?  You get it done as effectively and efficiently as possible. I recently completed Getting Things Done by David Allen.  It was an interesting book.  Though I use paperless processes to "get things done", David offered one bit of advice that resonated with me.  To advance a task or activity to more of an actionable conclusion, he said to ask "What's the next action?"

This parallels what I do with my Kanban (task) board.  I currently have 4 columns:  Backlog, Work In Progress (WIP), Blocked, Done.  When a prioritized task can not be worked, I put the task card (user story) in the "blocked" column.  I then ask myself the question.  What's the next action? Without asking yourself that simple question, your task may be blocked longer than necessary.  You have to understand there may be 3 or 4 steps you need to complete before you can unblock your task and get it back to WIP.  So, ask the question.

As to not ignore the obvious, I recommend you write your tasks in a standard user story format.As a [perspective], I want to [activity], so I can [desired outcome]

It doesn't matter if you use a physical or virtual Kanban (task) board.  I recommend following 3 simple rules:

1. Keep your tasks visible

2. Keep your tasks limited

3. Keep your tasks actionable

1 of 100 PM Related Questions I Ask Myself

Hmmmmm

Question 1: In the hope to help the Project Management industry mature, should project management related templates and worksheets be freely distributed to the project management community or should there be a reasonable fee charged? I am a strong believer in the wisdom of crowds.  If there was a consortium of types with diverse backgrounds in Waterfall, Spiral, RUP, Agile, Scrum, XP... don't you think they could come up with some pretty good stuff?  In this case, all templates would be freely distributed.  I have to admit, the majority of my traffic is from people looking for free templates and worksheets.  It's tempting at times to put them behind a pay wall and ask for 99 cents.

What do you think?

Image courtesy of misallphoto on Flickr

The Best Kind Of Contract To Manage Is…(3 of 3)

Unfortunately, there is no ONE best type of contract to manage. The risk the vendor and customer share is determined by the contract type. The best thing you can do is understand the risks and benefits of each. There are three categories of contracts: Fixed-Price, Cost-Reimbursable, and Time and Material (T&M). In this 3 part series, I defined the contracts in each category. Hopefully, it will help you on the PMP exam and out in the real world.

Time and Materials (T&M) is a hybrid type of contractual arrangement that contains aspects of both cost-reimbursable and fixed-price contacts.  They are often used for staff augmentation, acquisition of experts, and any outside support when a precise statement of work cannot be quickly prescribed.

These types of contracts resemble cost-reimbursable contracts in that they can be left open ended and may be subject to a cost increase for the buyer.  The full value of the agreement and the exact quantity of items to be delivered may not be defined by the buyer at the time of the contract award.  Thus, T&M contracts can increase in contract value as if they were cost-reimbursable contracts.  Many organizations require not-to-exceed values and time limits placed in all T&M contracts to prevent unlimited cost growth.  Conversely, T&M contracts can also resemble fixed unit price arrangements when certain parameters are specified in the contract.  Unit labor or materials rates can be preset by the buyer and seller, including seller profit, when both parties agree on the values for specific resource categories, such as senior software engineers at specified rates per hour, or categories of materials at specified rates per unit.

Image courtesy of Marc Lemmons via Flickr