We didn't learn our lesson

As the project I support enters a new period of performance, I reviewed the lessons learned documented a year ago and compared them to the documented lessons learned from a few weeks ago. To be identified at any point of a project lifecycle (PMBOK page 437), all project managers should collect and document lessons learned.  In reality, everyone on the project should be collecting and documenting lessons learned.  But, as many will attest, you need to be able to implement approved process improvement activities (PMBOK page 83) or you will just continue to revisit history at the end of each cycle or project.  If that is the case, you really didn't learn your lessons.

Do you learn from your mistakes?  You should be able to at least be aware of them.  Document your mistakes and revisit them at the beginning of the next project or cycle.  Group them into three categories: Correct Actions, Preventive Actions, and Defect Repair.

Corrective Action: Document your direction for executing future project work. Bring expected performance of the project work in line with the project management plan.

Preventive Action: Document your direction to reduce the probability of negative outcomes associated with project risks.

Defect Repair: Document a defect in a project component with the recommendation to either repair it or completely replace the component.

Though the process of documenting, reviewing, and implementing lessons learned may differ between Waterfall and Agile projects, the process still needs to happen.

Again, don't just document lessons learned.  Act on them!

Graphic: Flickr: sopheava

Awesome Scrum Intro Video

As I was reading tweets over the weekend, I discovered an awesome video by Hamid Shojaee, Founder and CEO of Axosoft. It's an 8 minute introduction video on Scrum.  With background music sounding a bit like Block Rockin' Beats by The Chemical Brothers, this video is to the point and completely awesome.

I think this type of video is necessary to show to stakeholders, who have not had an introduction to Agile or Scrum.  In this ADD world we live in, I think we need to deliver some information in the same way we would deliver features in a Sprint.  Go for the items of highest value and deliver them in a short period of time.  Additionally, deliver the information is a way that it can stand on its own.

I remember getting 50 government people in a room with an experienced Scrum Trainer, to introduce them to Scrum.  After several hours, some still didn't grasp the basics.  If they were forced to watch this video in the first 8 minutes of the training, I bet the day would have gone a lot differently.

Looking for Partnerships in Project Management

We are happy to announce, upon partnering with a London-based project management firm, that we launched the future site for Prince2 Flashcards.  Currently, there is just a sign up form, for those who wish to be informed when our product is about to launch.  Additionally, we launched the future site for our PMP Exam Simulator. Again, sign up if you want to be informed when our product is about to launch.  Both the Prince2 and the PMP Exam Simulator sites are project management exam preparation websites that should help us expand our reach in the market. So, what makes this blog post different from others?  Back in March, we launched our PMP Flashcards site.  This was the first site to use our HueCubed flashcard engine.  We've gone through several iterations of the engine and it just gets better and better.

What we're looking for now are some affiliate partners for the PMP Flashcard website.  Do you like what we have created? Want to make some extra money, along with us?

Sign up as a HueCubed affiliate!  As we launch each of the sites, we'll make affiliate links and buttons available.  All affiliate accounts will paid by HueCubed.

Disclaimer:  The Critical Path, HueCubed, and all of the mentioned product sites were designed and developed by me and my development team.

Thank you to everyone for your support,

Derek

Graphic from Flickr: Spring Stone

Expert Judgment and Passing the Sniff Test

Looking for two very informative posts on estimating?  Check out one by Josh Nankivel of pmStudent and Glen Alleman of Herding Cats.  Both are discussing estimating techniques that work for them. I wanted to take a moment to add my two cents. Though I certainly believe estimating should be more science than art, I look at estimates from a different perspective. As a disclosure, I'm not the one doing the estimating on this project, therefore I'm not going to say I agree or disagree with any one technique.  Depending on your situation, one estimating technique may provide more accurate results than the other.

What I would like to add, from my perspective, is the need for expert judgment. If you are an expert in a given estimating technique and it gives you the results you and your customer(s) need, does that not validate it as an acceptable estimating choice?

If the estimating technique does not produce the desired results, wouldn't it fail the metaphorical sniff test?

Recently, I questioned a vendor's estimate based on a different technique.  I used a parametric estimate to see if the vendor's estimate would pass or fail my sniff test.

What exactly is a parametric estimate?

An estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.  Source: PMBOK Page 439

So, why did the vendor's estimate not pass my sniff test?  As part of a standard estimating practice, software vendors should include time for fixing bugs. Upon review of a recent status report, I noticed the vendor reporting half as many bugs were discovered in a current build than had been estimated. When asked about this, the vendor was very excited to confirm that they indeed found half as many defects in the code they originally estimated and predicted a cost savings of several hundred thousand dollars to the project.  Going into the current build, I knew what the standard deviation was and considered the possible variance.  This fell way below that.

So, why were they discovering so few bugs?  At first glance, I would predict two possible reasons.  [1] Quality through development improved.  [2] Quality through testing worsened.  Either way, you get the same initial result of fewer defects identified.

We'll know the true answer once initial user acceptance testing begins.  If there were no baselines to compare the actuals to, I might not have given it a second thought.

Graphic source via Flickr: pump

Dr. Seuss Inspired by Personal Kanban

I met Jim Benson about a year or so ago.  He was in Washington DC and I met him for lunch down in Chinatown.  Jim's a pretty smart cookie.  I like what he does.  I sometimes wish I could do what he does but it requires a little more of a balanced mind than I possess.  In the Star Wars universe, Jim would be a Kanban Jedi and I would be a mere Padawan. I used kanban and limited my work-in-progress (WIP) at a previous job but don't have the buyin from my current client to implement the practice here.  I still have a Kanban board hanging on my wall but it's there for me to manage my own work.

Today I read an article on the Personal Kanban website titled "Would You, Could You on a Plane?" It was about a quick offline kanban for in-flight work.  It was informative, as always.  But, the mere title inspired me to write a bit of a ridiculous comment.  Perhaps I read too much Dr. Seuss during my off-time.

Say! I like Kanban! I do! I like it, Sam-I-am! And I would limit WIP in a boat. And I would limit WIP with a goat. And I will limit WIP in the rain. And in the dark. And on a train. And in a car. And in a tree. Limiting WIP is so good so good you see!

So I will limit WIP in a box. And I will limit WIP with a fox. And I will limit WIP in a house. And I will limit WIP with a mouse. And I will limit WIP here and there. Say! I will limit WIP ANYWHERE!

I do so like Limiting WIP and Kanban! Thank you! Thank you, Sam-I-am

Strange how a simple title can get me started.  Thank you Jim for doing what you do, even if that means reading ridiculousness comments that I write.

Occam's razor and my project management approach

Occam's razor (or Ockham's razor) is the principle that "entities must not be multiplied beyond necessity". The popular interpretation of this principle is that the simplest explanation is usually the correct one. It has inspired numerous expressions including "parsimony of postulates", the "principle of simplicity", the "KISS principle" (Keep It Simple, Stupid).

Though most of Occam's principles are enrooted in philosophy, many approaches (especially the principle of simplicity) can be found in the basics of design principles.

Given a choice between functionally equivalent designs, the simplest design should be selected. Implicit in Ockham’s razor is the idea that unnecessary elements decrease a design’s efficiency, and increase the probability of unanticipated consequences. [¹]

When comparing technologies that perform the same function, a technology that is simpler in design will tend to be simpler to construct and repair, but will tend to require greater skill to use, whereas a technology that requires less skill to use will tend to be more complex in design and more complex to construct and repair. For example, a straight razor is relatively simple in design and construction, but requires considerable skill to use, whereas an electric razor is relatively complex in design and construction but requires little skill to use. [²]

Now, go back and reread the two referenced passages, substituting

design

and

technology

with

project management approach

.  I particularly like the straight razor analogy, mostly because I shave using a straight razor.  I only had to cut myself once (badly) before I realized I needed real skills to use such a simple tool.

So, what's my transition?  Just because you may know a lot about project management, doesn't mean you need to make things complicated.  At the end of the day, very few customers care how it got done.  They just care that the product or service was delivered on time and within budget.  If you're looking to add project management control points, look for what will lower risk and increase value throughput.  The idea is to make your process as simple as possible, allowing things to get done.  Don't add control points to a process for no other reason than to make work for everyone.  Don't simplify too much either, resulting in the wild wild west.  I'm always looking for that happy medium.  So, go forth.  Study your craft and learn everything you can about project management.  Just be careful not to cut yourself.

[¹] http://www.visualgui.com

[²]  http://www.omick.net

Image source: suddenimpactmedia

May PMP Certification Numbers Are In

Every month I get a copy of PMI Today and I annotate 3 data points: New PMP® for the month, new PMPs year-to-date (YTD), and total number of active PMPs. This month was a little interesting because PMI stopped reporting the New PMP monthly numbers and the YTD total, opting to report just the overall number of active credential holders. This is not a problem since I have been tracking the PMP data for over a year.

The trend continues, with the new number of PMPs in May totaling 3,985. Year-To-Date total is 23,581. There are a total of 385,096 active PMPs.

The current trend predicts PMI will hit 400,000 active PMP credential holders this year.

	December (2009)	January	February	March	April	May
New PMPs (Monthly)	5,403	3,714	3,713	5,344	4,718	3,985
New PMPs (YTD)		3,714	7,429	12,779	19,596	23,581
Total Active PMPs	361,238	367,619	371,014	375,959	381,111	385,096

Though I'm still worried we're rapidly reaching a tipping point, I want to congratulate those 3,985 out there who passed the exam. It's no cakewalk and I recognize your efforts and achievement.

Of those 3,985, I've been in contact with several who passed the exam with the aid of my new product PMPrepFlashcards.com. Yes, I know, gratuitous plug.

The new data PMI did include in this months PMI Today was very enlightening.  It's about the other credentials.  As of May 2010, there were 385,096 active PMP credential holders.  In comparison, there were only 11,458 Certified Associates in Project Management (CAPMs)®, 421 Program Management Professionals (PgMPs)®, 357 PMI Risk Management Professionals (PMI-RMPs)®, and 320 PMI Scheduling Professionals (PMI-SPs)®.

With the industry dominance of the PMP® credential, it makes me question if these other certifications have the staying power.  Is there a demand for them or are they just a possible revenue stream for PMI?  Will there other certifications for the other knowledge areas?  Is Certified Scope Professional and Certified Communications Professional not far behind?  If I would PMI, I would go for it.  You don't know what the market will find valuable unless you try it.

Social constraints for your meetings

One rule that I have about meetings is it should start on time so it can end on time.  We all know that is easier said than done.  If you have a daily stand-up meeting, which is timeboxed at 5 to 15 minutes, you can not afford to have people showing up late.  They need to show up on time. But what if there is that one person on the team who does show up late... every... meeting?  Do you punish him or her?  Let's make them pay a dollar every time they are late.  Do you think that is a good idea or a bad idea?  Have you tried it?  I have.  It surprised me when it didn't change that person's behavior.  If anything, it just ensured they would be late.  Why?

By paying me the dollar, that person no longer felt obligated to arrive on time.  Everyone else, while still adhering to the culture of acceptable behavior, arrived on time.  Everyone else on the team, felt equally obligated to arrive on time because I was on time.  They felt that they owed it to me to be there on time.

So, how do you correct this negative behavior?  I like to zone in on something that makes the violator uncomfortable.  I've made them sing.  I've made them dance.  I've stopped the meeting when they've arrived late and then made them go from person to person on the team and say "I'm sorry for wasting your time".  This may sound a little over-the-top but they slighted everyone on my team.  Everyone else was there on time; they should be as well.

I'm including a link to a TED video with Clay Shirky.  You don't need to watch the whole thing.  What 4 minutes starting at 6 minutes 50 seconds.   He mentions the study A Fine Is A Price by Uri Gneezy and Alfredo Rstichini in 2000.  It is exactly what I'm talking about.  It defined the difference between social constraints versus contractual constraints.  Nothing like a research study to spice up the next meeting.

http://www.youtube.com/watch?v=qu7ZpWecIS8#t=6m50s