The painful reality of many meetings

I'm rereading (listening) to Rework for the 3rd time.  It's been about a month since I last absorbed this artfully crafted piece of wisdom from Jason Fried and David Heinemeier Hansson of 37Signals.  People who read my blog know that I hate meetings.  I'm ok with the 5 minute stand-ups.  I'm ok with the 22 minute meeting, when necessary.

The painful reality is one poorly organized meeting can suck more time and energy than a week of good meetings. How many meetings do you go to in a week? Do you really need to be there? Is there a published goal-based agenda?  Not going to meetings is like not watching CNN for a week.  If it's really important, someone will tell you the news.  Otherwise, you find yourself commonly hearing the same old thing over and over again.  Your time is more valuable than that.  Go do something else.

Know how to say no in negotiations

We've all had it happen to us. We were able to get a signed agreement in hand, identifying agreed upon scope of work. Everything for a fleeting moment is right in the world. Then it happens. That one stakeholder (you know who they are) comes to your desk and asks. "Can we add this one little tiny feature?" or "Can we make this one tiny little change?" Are you kidding me? This reminds me of when my son asks if he can have dessert when he hasn't eaten his dinner. Though you can't be as abrupt with a stakeholder like you can with a 4-year-old, the answer should still be the same. No.

Though you should not be an obstructionist, we could all learn a little from Dr. Cox in this case.  His (command) mitigated speech is all he needed.  In the real world, stride to be a win-win negotiator and be aware of the mitigated speech being used to conduct your negotiations.

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