Know Your Customer

Communications with your customer(s) and team(s) is key to your success.  Knowing what they want is just as important as what you plan to deliver.  I laughed out loud (uncomfortably) when I saw the graphic to the left.  Though I'm not Jewish, I've worked with a lot of people from around the world.  I've grown to appreciate the things that make us all unique.  Trying to sell some Jews a ham on Chanukah is almost as bad as offering an all-you-can-eat meat buffet to a vegetarian.  It doesn't matter how good of a deal you can offer, the product itself must meet the needs (and wants) of the customer.  Perhaps if the vendor of the boneless smoked ham had the list below, they could have avoided this embarrassing (and potentially costly) situation. Problem Statement

Describe the business reason(s) for initiating the project or building a product, specifically stating the business problem.  Identify the high level goal it relates to.

Description

Describe the approach the project or product will use to address the business problem.

Goals and Objectives

Describe the business goals and objectives of the project or product. (I like user stories)

Scope

Describe the project or product scope. The scope defines limits and identifies what is delivered (inclusive). The scope establishes boundaries and should describe products and/or services that are outside of the scope (exclusive).

Critical Success Factors (Acceptance Criteria)

Describe the factors or characteristics that are deemed critical to the success of a project or product, such that, in their absence the it will fail.

Assumptions

Describe any assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints

Describe any constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the constraints based on the current knowledge today.

I want to thank my wife for sending me the image.

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.

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

Free Project Initiation Worksheet

Project Initiation Worksheet

When you are about to initiate a new project, you should capture the basics of project information.  If you don't, you're walking into a minefield.  Even before you write up a charter, you should be able to answer the following: Problem (or Opportunity) Statement -Describe the business reason(s) for initiating the project, specifically stating the key business problem or opportunity

Project Description - Describe the approach the project will use to address the business problem

Project Goals and Objectives - Describe the business goals and objectives of the project. Refine the goals and objectives stated in the Business Case (which you should also have)

Project Scope (Requirements) - Describe the project scope. The scope defines project limits and identifies the products and/or services delivered by the project. The scope establishes the boundaries of the project and should describe products and/or services that are outside of the project scope.

Critical Success Factors -Describe the factors or characteristics that are deemed critical to the success of a project, such that, in their absence the project will fail.

Assumptions - Describe any project assumptions related to business, technology, resources, scope, expectations, or schedules.

Constraints - Describe any project constraints being imposed in areas such as schedule, budget, resources, products to be reused, technology to be employed, products to be acquired, and interfaces to other products. List the project constraints based on the current knowledge today.

If you can articulate these seven areas, you've proven you have at least a basic understanding of what you're up against.  If you can not, you better go back and find the answers.  It is a lot cheaper to answer a question when the project is still initiating, compared to deep in executing.

[Click here to download a free Project Initiation Worksheet]