Measuring Success in NYC

When you have a project, you need to find out from the customer how they will judge the success of the project.  Don't go off giving the team high 5's and leave the customer scratching their head looking at the bill.  At the inception of the project and at the identification of each deliverable, get agreement from the customer as to success criteria. I just returned from a trip to New York.  Let's use that trip to illustrate my point.  My wife and I will represent the customers.  Both of us had a different measurement of success.

For my wife, the trip would be a success if we made it to the Gershwin on time to see Wicked.  For me, the trip would be a success if I got to have dinner at John's Pizzeria.

We identified contingency plans, so we could have different levels of success.  [1] Drive almost an hour and a half to Union Station in Washington DC.

Milestone 1 - Success

[2] Take the train to Penn Station in New York.

Milestone 2 - Success

[3] Get to the W Hotel in Time Square and check in.

Milestone 3 - Success

[4] Get to the Gershwin Theater

Milestone 4 - Success (Customer #1 is 100% satisfied)

The show was really good.  If you haven't seen it, I would recommend it.  It was odd seeing some people not dressed up.  Call me old fashioned but if you're going to the theater, it wouldn't hurt you to dress up.

[5] The next milestone was get to John's Pizzeria.  I just wanted a pie and a beer.

Milestone 5 - Success (Customer #2 is 100% satisfied)

After dinner, we returned to the hotel and then spent the evening in Time Square.  Last time we were in there, I proposed.  Not a coincidence, our hotel room was right over the spot where I popped the question. Since I take everything so seriously, we then went to a toy store, where I was promptly attacked by a Transformer.  Needless to say, that was not on my risk register.

Thank you to my wife for allowing me to check in via Foursquare and Gowalla.  I didn't do it a lot.

How was your weekend?

A Schedule More Complicated Than a Rube Goldberg

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

Agile is in the PMBOK so it must be true

Yesterday, I was having coffee with Jesse Fewell and we discussed, among other topics, how the PMP® or Certified ScrumMaster (CSM) credentials legitimize many in the eyes of stakeholders. This is a sore spot for many, particularly for me.  Experience and project leadership trumps a certification any day of the week.  But, for those of us who believe we know what we're talking about, a credential is sometimes a necessary evil.  As I advise a Federal PMO on a multi-year project, I have grown to accept that progress can be slow and expensive. Things can be so slow and expensive, we rarely get to see actual value delivered.  Rather, successes are measured with earned value. Sometimes, I think it's just the nature of the beast. But, it doesn't have to be that way.

You can only imagine my excitement when a vendor proposed using Agile to deliver the next (year) software increment. The PMO I advise has many PMPs but only one CSM...me.  I'm not going to go into the details of the project.  But, how could the opportunity be seized to leverage Agile?  Rather than answer that directly, I'll ask a question.  If you believe in the Agile Manifesto, how would you convince people with no experience with Agile or Scrum (but lots of experience with the PMBOK and Waterfall) that you know what you're talking about and that Agile is a viable option? I would propose that you make sure you can communicate with stakeholders in a language they understand. If you start using terms like Sprint, ScrumMaster, and Burndowns, when they understand contract periods of performance, project managers, and EVM reports, you may lose that essential stakeholder buy-in.

One of the first things I would recommend you say is "Agile is actually in the PMBOK". If your stakeholders are PMPs and they believe the dogma of the PMBOK, you'll have their attention. It's not called Agile but it is there. In Chapter 2 (Project Life Cycle and Organization) of the PMBOK, you'll read about Project Phases, specifically phase-to-phase relationships, and then even more specifically the iterative relationship.

...only one phase is planned at any given time and the planning for the next is carried out as work progresses on the current phase and deliverables.  This approach is useful in largely undefined, uncertain, or rapidly changing environments such as research , but it can reduce the ability to provide long term planning.  The scope is then managed by continuously delivering increments of the product and prioritizing requirements to minimize project risks and maximize product business value.  It also can entail having all of the project team members (e.g. designers, developers, etc.) available throughout the project or, at a minimum, for two consecutive phases.

For the Agile pundits out there, does that sound a little familiar?  For those who believe the gospel of the PMBOK, is it reasonable to believe Agile is an approach that can be considered?  Agile is not a bunch of voodoo for the wild and undisciplined.  It's an excellent opportunity to deliver value.

April 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. The trend continues, with the new number of PMPs in April totaling 4,718. Year-To-Date total is 19,596. There are a total of 381,111 active PMPs. The current trend predicts PMI will hit 400,000 active PMP credential holders this year.

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

Of those 4,718, 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.

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

Team Building Techniques - 5 Stages

Ladder

When I think of team building techniques, the one place I didn't think to look was the PMBOK®. In chapter 9, specifically 9.3.2, the PMBOK details Tools and Techniques of Developing Project Teams. For those out there studying for the PMP®, this might be a good time to write this down or print the blog post. The PMBOK lists 5 stages of development that teams may go through, usually occurring in order.  What PMBOK lists is relatively academic.  It won't actually help you with team building.

Those stages, with the exception of the last are based on the Tuckman ladder[1].  Forming – Storming – Norming – Performing. It's a model of group development, first proposed by Bruce Tuckman in 1965, who maintained that these phases are all necessary and inevitable in order for the team to grow, to face up to challenges, to tackle problems, to find solutions, to plan work, and to deliver results.

Why PMI found it necessary to add the last one, I can't tell you.  But, in the event you think it may appear on the PMP exam, here is what PMI thinks you should know.

Forming. This phase is where the team meets and learns about the project and what their formal roles and responsibilities are. Team members tend to be independent and not open in this phase.

Storming. During this phase, the team begins to address the project work, technical decisions, and the project management approach.  If team members are not collaborative and open to differing ideas and perspectives the environment can be destructive.

Norming. In the norming phase, team members begin to work together and adjust work habits and behaviors that support the team. The team begins to trust each other.

Performing. Teams that reach the performing stage function as a well-organized unit.  They are interdependent and work through issues smoothly and effectively.

Adjourning. In the adjourning phase, the team completes the work and moves on from the project.

The PMBOK concludes by saying a Project Manager should have a good understanding of team dynamics in order to move their team members through all stages in an effective manner.

Two stages I think they missed include  Empowering and Supporting.  If PMI can insert Adjourning into this list, with the sounds of One of these things is not like the others in my head, I think I can add my two stages.  Still, if you want to pass the PMP, perhaps you should just stick to their list.

[1] Tuckman, Bruce, 1965. Developmental Sequence in Small Groups. Psychological Bulletin No. 63. Bethesda, MD: Naval Medical Research Institute.

Image source: Orange Country Register

See Dick See Dick the PM Run

dick_jane_sally

See Dick.See Dick run. Run Dick run.

See Jane. See Jane run. Run Jane run.

You get the idea.

When I was in the first grade, those were the first sentences I remember reading.  I remember being frustrated by this because this isn't really how we talk.  Well, actually, it isn't how I talk.

I suffer from a self-described affliction called over-descriptivitis.  I can't help but elaborate on any and every idea I'm trying to articulate.  I never thought it was a problem.  I merely communicate the greatest level of granular detail to my recipient and allowed them to filter out the extraneous information.  If my wife asks me what I did at work today, I will tell her everything in chronological order.  TMI?

My wife is very forgiving when it comes to me offering more than she asks for.  Sometimes she just puts her hand up and asks, "can I have the abridged version?"  My over-descriptivitis was even addressed in our wedding vows.

I promise I will tell you the time, not how the clock was built.

So,what's the point I'm trying to get across? It's about articulating requirements.  It doesn't matter if you're using shall statements or user stories.  You need to go into enough detail that the person reading it understands your need(s).  After you decide on your format, try to be consistent.

Formal shall statement format: The [activity] shall [desired outcome]

Standard user story format: As a [perspective], I want to [activity], so I can [desired outcome]

Though it may be my over-descriptivitis acting up, I prefer using user stories.  I like the fact that it paints a clearer picture.

How about you?  Do you prefer formal shall statements or user stories? Why?

Why You Should Use Common PM Language

I don't normally drink coffee from Starbucks but someone gave me a gift card.  I like black coffee, with no cream or sugar.  I like my coffee fresh so I order a small size.  So, why on Earth did the person behind the counter not listen to me? I ordered a small Caffè Americano. For those who do not drink coffee, that's nothing more than a small espresso and water.  My expectation was I would get a small cup of coffee.  When I looked at my receipt it said Tall.  I brought this to their attention and I was dismissed.  "Oh, it's the same thing."

Well, no, it's not.  Line up the cups and this is what you will see.  Extra-Small, Small, Medium, Large, and Extra-Large.  What does Starbucks call them? Tiny, Small, Tall, Grande, Venti. So, what I got was a medium.  I'm not going to split hairs here.  I'm trying to make a point.  There needs to be a common understanding between the vendor and the customer when you both define the same thing differently.  This is a financial transaction.  I want what I paid for.

How does this apply to Project Management?  From the customer's perspective, what is the definition of done.  From the vendor's perspective, what is the definition?  From every stakeholder perspective, do you all have the same definition of done?  You should!

It's important to note, it doesn't matter which approach you use.  Waterfall, RUP, Agile, or Kanban.  Everyone needs to understand and agree to what done means.

Help Me Understand What I am Seeing Here

Things seemed to get a little heated in the meeting yesterday.  Upon reviewing the vendor-supplied PowerPoint deck, we noticed graphs illustrating the quantity of issues found and when the vendor planned to fix them.  So, we flipped back a few slides and noticed a table detailing the quantity of requirements that passed or failed, during the last build.  What we didn't get was something that illustrated the relationship between the two.  Since it wasn't included in the packet, we wanted an explanation. Never ask a question in an accusatory manner.  Don't be condescending.  Make sure the other party hears what you say and understands.  I started with something like this

So help me understand what I'm seeing here. I see....  ...Is that what you see?

I'm looking for the relationship between the issues found and the work you were authorized to complete.  Can you help me with this?

What was missing here was a Requirements Traceability Matrix. It would have answered everything. During this build, only work pertaining to agreed upon requirements should have been done. Only work pertaining to agreed upon requirements should have been tested. Therefore, we should have known immediately which requirements had passed and which failed.  That didn't happen.

It doesn't matter if you're using user stories or requirements.  There are documented expectations that need to be met.  User acceptance criteria should be known.

Any questions?