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.

Know who you are and what you represent

The other day I met Scott Simko, who I "knew" through This Week In Startups and Thomas Kiblin, CEO and Founder of Virtacore.  I met them as the founder of HueCubed, a web startup company offering a flashcard engine that we plan to scale like Weblogs, Inc. or Stackoverflow. (Create a niche product and then scale it in other vertical markets)  Our flagship product, PMPrep Flashcards, was released in March and I wanted to meet the people who are hosting our product(s). Up to this point, I have introduced myself as Derek Huether, Project Management Professional® and adviser.  But these people don't know me as that.  They were meeting me as Derek Huether, entrepreneur and founder of a web startup.  As a result, I stumbled when it was time to introduce myself.  Don't make this mistake!

If you wear multiple hats in your organization, you may need to know who you are to different stakeholders.  Is your specialty in Waterfall, Agile, or Kanban?  Take a moment and imagine you are being introduced to someone.  What are you going to say?  This is part personal branding and part stakeholder management.  What I needed was a solid 30 second elevator pitch.  What's the takeaway from this post? Know who you are and what you represent.  It may be different, based on the company you keep.

And The Best Methodology Is

The question is always asked, which Methodology is best?  It is interesting to see or read the responses from people and their reasoning behind their opinion.  I actually don't like to use the term Methodology. I would prefer to use the term Approach.  Merriam-Webster defines methodology as a body of methods, rules, and postulates employed by a discipline; a particular procedure or set of procedures.  An approach is the taking of preliminary steps toward a particular purpose.  THAT is what people do.  If you review the PMBoK or the Agile Manifesto, neither are going to say in the event of A-B-C, in this sequence, do D-E-F.  Life, application development, and project management are complicated enough.  You don't need to write an algorithm to know the next step needed to accomplish goals. There is a pain point in the industry that I've seen ongoing for several years now.  In this post, I'm not going to say which approach I think is better and why.  It's really kind of irrelevant.  I think what is important is we ask ourselves and our stakeholder. What IS important?

A while ago, commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It's an insightful post and I would recommend you go and read it.

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings.

My bridge to both blog posts is identifying Wants and Needs.  Both drive motivations.  Once you understand the motivation, you can answer the question "why?"

Before analyzing why one team likes one approach or has disdain for another, you have to question their motivations. We assume we all desire the delivery of value. That’s not necessarily true. Some are more motivated at protecting the status quo or their position in the program.

The hierarchy of wants, not needs, will commonly differ between teams, if we want to admit it or not.

Image courtesy of quickandirty

Ask Derek - Peanut Butter and Jelly Interview Question

peanut-butter-jelly

I received a question in the comments as to what possible answer(s) I expect to hear from job applicants, if I ask them how to make a peanut butter and jelly sandwich.  First, I would like to point out, I didn't think of the interview question.  A colleague recommended I ask it, when I told her how I found interviewing challenging.  You don't need to give a lot of background to get someone's perspective on how they would do it.

Everyone knows what a peanut butter and jelly sandwich is. They can wrap their heads around the concept.

How to make a PB&J

I'm going to go really high level on this because interviews are all about brevity.  I would first expect the applicant ask me which approach our organization traditionally utilizes.  (Organizational Process)  I would then respond waterfall or agile.  I would expect the applicant to know both.

Let's start with Waterfall

As a Project Manager, I would expect to read a statement of work, business case, or contract.  I need to know what need the project will address.  Do we need to feed one person or 1,000?  Do we need to ship the sandwich(es) somewhere?  I expect there to be a project charter.  I need to know the goals and objectives, scope, success factors, assumptions/constraints of the project.  I want to know project authority and I want to know organizational structure, so I know who is responsible for what and where everyone sits in the chain of command.

From there, we can go as heavy or light as deemed appropriate by the scope of work, budget, and schedule.  I'm going to assume the project is in order.  There will be a WBS, a schedule, and a budget.  We'll know what level of quality we must meet.  We'll know what resources we have available.  We'll know approved methods of communication.  We'll have plans to address any risks.  I'm not saying you need a formal plans for each.  Go as heavy or light on these as appropriate, but don't ignore them!  Keep the communication flowing, get the sandwich(es) made.  Continually verify you're within scope, schedule, and cost.  Make sure the sandwich(es) meet the quality standards of the customer.  Have the customer accept the sandwich(es), and go through project closeout procedures.  That will include getting paid, do lessons learned, and disbanding the team.  Let's eat!

So that I don't bore you too much, I'm going to break this post into two parts.  My next post will be if I had followed the Agile approach.  If anything, I think this should make for good comment fodder.

Regards,

Derek

Green Eggs and Ham are…

Last night I read Green Eggs and Ham to my Son.  Because nothing is sacred in my world of blogging and project management, I drew a parallel between Sam and myself. If you don't know the story, Sam offers Green Eggs and Ham to an unnamed character.  This character adamantly states he does not like them.

Sam looks for different opportunities and scenarios where the character may enjoy the green eggs and ham.  Every time, he's dismissed.  I will not eat them here or there.  I will not eat them anywhere!

Still, Sam persists.

You do not like them.  So you say.  Try them!  Try them!  And you may.  Try them and you may, I say.

The character finally laments and tries the green eggs and ham.  Guess what?  He likes them.  He likes them a lot!  All of a sudden, he realized all of the scenarios Sam recommended really are perfect opportunities to enjoy green eggs and ham.

So, what are green eggs and ham?  I think they are ideas and opportunities. Yes, the same ones your colleagues had that got shot down.  The same ones you had but were also dismissed.  It's Agile, Scrum, Kanban, or some other approach the customer has never tried before, therefore, they don't even want to try it.

Next time someone has an idea or opportunity, try it!  Try it! And you may.  Deliver value in that way.

Image courtesy of themouseforless

If you liked this post, check out Compassion is the “Killer App” over at the Guerrilla Project Management website.

I also recommend reading Chug, Chug, Vroom, and Expectancy Theory, a blog post by Todd Williams, who explains its applicability in The Little Engine That Could.

The Critical Path Week in Review

This week I really wanted to turn up the volume of things I wrote about.  I have a lot to say (and write) about project management and if you missed reading my blog on a given day and don't have an RSS feed or follow me on Twitter, you'd have to go searching in the archives to find it.  I don't think that's good enough.  I should make it easy for you to read what I write.  Hopefully, this week in review will help you find something new while you enjoy your coffee or tea.

1/28/2010

Seeing Value From The Customer Perspective

I don’t care if you’re using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.  Just because a process does not appear valuable to you, it does not mean the process does not provide value...

1/29/2010

Refine Your Process If You Must Deviate From It

If you’re looking for a free Microsoft Visio template of a Sprint process workflow, which you can edit at will, you can download it here.  As I mentioned in my post Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations...

1/30/2010

The Impact Of Social Networking On Project Management

Good leaders do not operate in a vacuum. They exchange ideas and information with people. Offer free information and it will come back to you tenfold. Listen to knowledgeable people and then make a more educated leadership decision... In this post I compared the traditional communication paths and how that process is turned on its ear, thanks to social networking...

1/31/2010

This Is How You Know When To Kill A Project

A personal rant about paper telephone books and how I never realized, until now, who the real customer was. There is a very similar parallel between the newspaper industry and the printed phone book industry.  They both believe or promote the scarcity of information.  That scarcity justifies cost.  To the contrary, we now live with an abundance of information.  That information is freely distributed and reaches a broader audience...

2/1/2010

The December Numbers Are In For PMPs

Yes, the December numbers are in.  December 2009 numbers for Project Management Professional (PMP®) certifications were published and it looks like there will be over 400,000 holding the certification in 2010...

	December Totals
New PMPs (December 2009)	5,403
New PMPs (YTD)	75,107
Total Active PMPs	361,238

2/2/2010

And The Best Methodology Is

I recently commented on two blogs that address similar topics.  Jesse Fewell wants to empower teams to succeed, equip managers to lead, and enable executives to unlock the secrets of high performing organizations.  Jesse wrote a blog post offering the real reasons behind the methodology wars.  It’s an insightful post and I would recommend you go and read it...

The other blog post was from Mike Cottmeyer, someone I turn to on a regular basis to find inspiration and wisdom within the industry.  Mike wrote a blog post asking Why is Agile so hard to sell? Again, it is a very good read and you should set aside some time to read some of his writings...

The Pain Of IE6 And Application Development

There are legacy applications out there that were built on IE6 and it’s not an easy migration.  There are some Agencies which ONLY use IE6 and the users don’t have permissions to install a new browser.  So, what do you do?...

2/3/2010

Updated 10 Step Help To Submit PMP PDUs

All PMPs need 60 PDUs during a CCR cycle so don’t put it off until the last minute.  I document the process on how to claim your require 60 PDUs...

2/4/2010

Using Common Sense With Documentation

Though I really love good documentation, going heavy on it does not guarantee a successful project.  My recommendation is you spend a little time identifying documentation that truly meets your needs.  More importantly, identify documentation that truly meets your customer’s needs...

2/5/2010

Managing Risks and Opportunities

Washington DC is in the process of getting 20-30 inches of snow, over the next 24 hours.  Though I know you can’t foresee all possible issues which may occur over the course of a project, you should make an honest attempt to identify them in order to open a dialog with your stakeholders.  Has weather ever delayed your project or pushed it over budget?...

Refine Your Process If You Must Deviate From It

As I mentioned in my post yesterday, Seeing Value From The Customer Perspective, if you think you need to deviate from a documented or understood process, rewrite or refine your process to account for the deviations. Merriam-Webster defines process as a series of actions or operations conducing to an end.  If you are unwilling to modify your process, the deviation is unworthy of being done. I've had a vendor tell me they didn't need to document their processes because they were agile.  (Notice the lack of an uppercase A in Agile).  Leveraging Agile concepts does not mean a lack of documented process.  IF the customer tells me they see the greatest value in delivering documentation, what is this vendor going to respond with?  Sorry, we won't deliver value?  If you use Waterfall, you may be used to generating more paper.  You have to consider documentation on a case by case basis.  Some customers have legitimate needs for documentation and other have wants.  Now go back and read that last sentence again.  Needs...Wants...

I personally like to go light on documentation.  What I need and what the customer needs are usually two different things.  That being said, I like to understand the rules (governance) before I start anything.  The Microsoft Visio document I included in my last post was a good example of a high level governance (functional flowchart) document. After completing the flowchart, I then detail each activity in a separate document.  What is the input and output?  Is there a formal deliverable associated with the activity? The idea behind the separate document is you won't need the flowchart to describe the process.  For those who have successfully navigated a SOX audit, you know what I'm talking about.  But I digress.  The flowchart activities I documented are not groundbreaking.  The process in this case is an Agile Scrum process with a few defined quality assurance decisions points.  You do not need to go into the Nth degree to understand this process.  Identify some touch points where the vendor and customer interface.  Identity some decision points.  That's it!

I've done these flowcharts for several customers.  I've created them for both Waterfall and Agile development approaches.  If you're looking for a free Microsoft Visio template, which you can edit at will, you can download it here. I zipped it to make downloading easier.  If you're looking for other free templates or worksheets to use on your project or program, you can download them there.

What do you think?  To document or not document.  That is the question. I welcome your comments or feedback.

Regards,

Derek

Seeing Value From The Customer Perspective

I recently sat in a meeting between a vendor and client, where the client was attempting to communicate their need to route new work deliverables to an existing Change Control Board (CCB). The contractor came back and said they believed the CCB in this case would not provide value and perhaps it should be bypassed.

Note to all vendors: Just because a process does not appear valuable to you, it does not mean the process does not provide value. The use of the CCB provides a (formal) control point helping to prevent unauthorized work and cost overruns. This goes further then just having a client billed for unauthorized work. Any work done without prior authorization has a risk of negatively impacting project schedule, cost, or quality. The mere act of doing unauthorized work impacts the scope.

I don't care if you're using Agile, Waterfall, or other methods to deliver value.  What is important is you understand your process and what mechanisms provide the greatest value to the customer.

If you think you need to deviate from a documented or understood process, rewrite your process to account for the deviations. If you are unwilling to change your documented process, the deviation is unworthy of being done.

I created the Visio diagram (above) a few months back to help both the customer and vendor visualize what we were trying to accomplish.  The challenge was implementing Scrum in a very formal and controlled environment.

I certainly recognize many don't have such a formal process.  Instead of CCBs, you may call them Product Backlog Review Meetings.  Counter to this, you may have a very fluid and simple software development life cycle (SDLC).  If so, you still need to understand your process and you still need to communicate with your customer.  Understand what their highest priorities are and deliver.