Let's do what makes sense

I sat in a meeting Friday afternoon to meet the new guy over at the vendor's office and give my assessment to my client.  It never gets boring, listening to rhetoric from a vendor.  They usually speak to my client, not with my client.  A few months ago, after I asked the vendor a very specific question about the sloppiness of a metric, the vendor replied  Do you have a problem with that!? Well, actually, I think both of us (the vendor and I) have a problem.  We're both here to ensure this client gets quality work.  It doesn't matter if it's a software build, documentation, or even a graph is a slide deck.  The vendor lamented and the metric actually makes sense now. The new guy, though perhaps giving us lip service, actually established himself as a bridge builder and communicator.  He said he wanted to know our concerns so we'll all be in step.  He gave us his email address and mobile telephone number, telling us not be hesitate contacting him.  When we pressured him on a request we've been demanding from the previous leadership, he said they would figure out a way to get it done.  When asked of our first steps going forward, his response was...

Let's do what makes sense.

What a refreshing response. No "let me get back to you". No "let me check with my boss".  It was a direct answer.  It was ambiguous but I thought it was acceptable considering the situation.  Compared to hearing traditional responses like "Ya, we can do that" when asked to if the vendor could make a change or deliver something, this guy actually said Let's do it.  If we can be in agreement as to what makes sense, we're golden.

At the end of the day, I don't care what they can do.  I care what they will do.  Let's hope we're turning over a new leaf.

Listen to your Customer on her Birthday

In celebration of my wife's birthday, I figured I would make her a homemade birthday cake.  I haven't done that since before we got married 5+ years ago.  This time, however, I actually asked her what she wanted.  That's right.  The first birthday cake that I made for her, I didn't even ask what she would like.  If you were the customer, wouldn't that kind of tick you off?  Thanks for the cake but... I don't like that kind. Getting input (and listening) to your customer goes a long way.

Sure, I could have ordered a cake from the local (and now famous) Charm City Cakes but she didn't ask for that.  She wanted a chocolate cake with butter cream frosting.  So, last night, our 4-year-old son and I made her a chocolate cake with butter cream frosting.  We even cleaned up the mess after!  But, it wasn't completely uneventful.  All I can say is I'm glad there were well documented instructions.

Me: Are we a pair of knuckleheads or what? My son:  I think we're a pair of clowns, Daddy.

Here is my Project Management Spin

1. Find out what your customer wants.
2. Deliver what your customer wants, not what you want.
3. You'll spend more money if you want a chef to bake and decorate your cake.
4. You'll save more time if you want a chef to bake and decorate your cake.
5. Even a pair of clowns can bake and decorate a cake (if instructions are good).
6. You should expect lower quality from a pair of clowns.

Product Delivery

• Both cake and frosting passed unit testing. (Mmmmmm)
• We did a little beta testing last night before the final build.
• The final build was successful.
• We delivered on time.
• We delivered below budget.
• The good news is, I'm pretty sure we'll pass user acceptance testing.

Happy Birthday to my beautiful and wonderful wife!

Meeting Acceptance Criteria Implies Customer Satisfaction

checklist

It doesn't matter if your model is Kanban, Agile, Waterfall, or RUP.  You can't close out a project or task without first identifying the Acceptance Criteria.  Acceptance criteria begins to take shape during the first moments of a project or task. If you are utilizing Kanban or Agile, everything pertaining to your deliverable should be captured on your story cards.  This includes story details and acceptance (testing) criteria.  Satisfying all acceptance criteria implies the needs of the customer have been met.

If you following Waterfall, RUP, or similar model, you would expect to identify acceptance criteria, along with scope description and project deliverables, in the project scope statement.  (These are each components of a scope baseline)

It all goes back to requirements and stakeholders' satisfaction.  Remember each requirement should add business value by linking to a business or project objective(s).

Those criteria, including performance requirements and essential conditions, must be met before project deliverables are accepted. Regardless of your model, spare yourself a lot of wasted time AND money by documenting acceptance criteria early.

Responsibility Assignment Matrix

As a graphical depiction of a more detailed perspective of responsibilities, the responsibility assignment matrix should reflect assigned responsibility by functional role for key project deliverables.  An example of roles detailed below could include (1) Project Manager, (2) Project Sponsor, (3) Implementation Manager, (N) Team Lead

Project Deliverables	Role 1	Role 2	Role 3	Role N
WBS 1.15.10.1300 - Project Charter	E	A	C	I
WBS 1.15.10.1301 - Project Schedule	E	A,C	A	I
WBS 1.15.10.1302 - Project Budget	E	A,C	E	I
WBS 1.15.10.1303 - Status Reports	C	C	A	E
Legend E = responsible for execution (may be shared) A = final approval for authority C = must be consulted I = must be informed

I use this matrix in a few of my project artifacts, to include the Lessons Learned. You can download a free copy here