I got a lot of feedback from people after they read of my $17,902 meeting post.  I spoke to a few others in my office and they all agreed that the number sounded plausible. As I’m writing my proposal for corrective action, I will deliver it in the form of a value proposition.

A value proposition is an analysis and quantified review of the benefits, costs and value that “something” an organization can deliver to customers and other constituent groups within and outside of the organization. It is also a positioning of value, where Value = Benefits / Cost (cost includes risk).  (Thank you Wikipedia for basis of that definition)

But, it’s not as simple deliverable.  I use 7 stages of analysis.

• Customer or market – Who am I creating the value proposition for?
• Customer or market value – What do they say they value? (not what I say they value)
• Offering – What is the product or service being proposed?
• Benefits – What are the benefits? (Time, Money, Productivity,…)
• Alternatives – What substitutes or alternatives are there? (like doing nothing)
• Differentiation – How is my proposal different from anything else being offered?
• Proof - What evidence do I have that I can do what you say?

In this case, I’m going to request a formal review of the Communications Plan, modifying it if necessary.  Because this is a status meeting (which is about reporting by one-way communication) not everyone needs to be there in person.  Before I go deep into my analysis, I’m going to bet I can apply the Pareto principle (80-20 rule) to get my point across.

If we do not devalue the benefit of the meeting, we can increase the overall value by decreasing cost.  That decreasing of cost, I would propose, would be asking 32 out of the 40 people to not attend the meeting in person.  By having 8 key linchpins (as defined by Seth Godin) attend this meeting, we could ensure the status is delivered and the message is not lost.

Other indirect communication methods could be used to ensure the information is distributed.  The slide deck and meeting minutes could be posted to a central location, allowing those who didn’t attend the meeting in person to know what happened.  Whatever the final outcome, there is a big opportunity for cost savings.

Graphic: Pictofigo

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.

Due to a wicked sinus infection, I wasn’t at the client site for several days.  I found myself taking pill after pill, trying to get myself back to a condition where I could return to the program and really be effective.  I think I took every colored pill under the rainbow.  I chuckled to myself as I took a blue pill, as I thought about the movie The Matrix.

In a memorable scene, the character Neo is faced with a decision.  By taking a blue pill, he could continue believing what he wanted to believe.  By doing so, he was ignoring reality.  The one who was giving him an opportunity of enlightenment was Morpheus.

Morpheus: This is your last chance. After this, there is no turning back. You take the blue pill – the story ends, you wake up in your bed and believe whatever you want to believe. You take the red pill – you stay in Wonderland and I show you how deep the rabbit-hole goes.

Welcome to the world of project management, Morpheus.  I’ve learned over time, which of my stakeholders to give the red pill to and which to give the blue pill to.  To be truthful, many don’t even want you to offer them a pill.  It’s my job to support and advise stakeholders related to our program.  It’s not my job to tell a stakeholder which pill to take.

When managing stakeholders, you really need to understand their motivations and expectations.  Not all stakeholders want the program or project to succeed.  Of the ones who do want the program to succeed, I’ve witnessed complete polar opposites of figurative pill popping.  On one side of the spectrum, I’ve dealt with a stakeholder who wanted to know every little detail of what was going on with a project.  This micro-manager almost choked on his red pills.  On the complete other side of the spectrum, I’ve had a stakeholder who showed up for a project charter meeting, swallow the blue pill, and just let everything take its course.

For those in the middle, there is a bit of a punchline.  Mix both a red pill and blue pill and you get a purple pill.  “Purple Pill” is a trademark for a heartburn medication, which is exactly what you’ll need at some point of a project.

So, I’m back in the office today.  I sat in a meeting with 50 other people and listened to a monthly status briefing by a vendor.  As I looked around the room and thought about writing this, I muttered to myself.

red-red-blue red-blue-blue….

I was asked a very interesting question today, requiring me to stop and think. How do I believe being an entrepreneur and a business owner differ? It’s a very good question because if you don’t know either an entrepreneur or business owner, I don’t know how any textbook answer would satisfy.

From my perspective, a business owner’s identity is merely the act of having and controlling property.  They could potentially inherit the family business, therefore becoming a business owner.  They could be very excited or could care less, looking for an exit strategy.

Entrepreneurs, on the other hand are passionate, committed, skilled, creators of value.  They create because they have a fire in their belly.  As an entrepreneur, they can’t help themselves.  It’s in their DNA.  They are so laser focused on what they are trying to create, people can either think they are crazy or brilliant.  But, with that charisma, people will be inspired and follow.

These contrasts aren’t too far off from Project Managers and Project Leaders. PMI defines a Project Manager (PMBoK Page 444) as the person assigned by the performing organization to achieve the project objectives. As I wrote in a previous post, there are several contrasts between a manager and a leader (Bennis & Goldsmith 1997)

• Managers administer; leaders innovate.
• Managers ask how and when; leaders ask what and why.
• Managers focus on systems; leaders focus on people.
• Managers do things right; leaders do the right things.
• Managers maintain; leaders develop.
• Managers rely on control; leaders inspire trust.
• Managers have short-term perspective; leaders have long-term perspective.
• Managers accept the status-quo; leaders challenge the status-quo.
• Managers have an eye on the bottom line; leaders have an eye on the horizon.
• Managers imitate; leaders originate.
• Managers emulate the classic good soldier; leaders are their own person.
• Managers copy; leaders show originality.

So, what are you?  Are you happy? Why?

(image by apogeehps.com)

While sitting in a governance meeting the other day, I heard how (before I joined the team) a vendor brought in some high paid six sigma black belts to try to bring the vendor governance workflow in line with my client’s governance workflow.  My client wasn’t sure what they got out of the deal, but if you have a black belt in something, it should be good…right?  Because this venture proved fruitless, the vendor announced, “what you need is kaizen!”  That may be what they said, but it’s not what my client heard.

This was paraphrased by one of my client’s team.  In trying to understand what she was saying, we had a quick back and forth that went a little something like this:

The vendor said there was something that would fix everything.
Cry Pan or Pie Pan or something like that.

I looked at her and ask, do you mean “kaizen”?

She then started to matter-of-factly pointing at me.
That’s it! That’s it! Now, what does it mean?
I said it just means improvement or refinement.

She looked disappointed.  That’s it?

Yep, that’s it.

Now, I know it’s not that simple.  There are no silver bullets.  I do believe in using refactoring or refinement to get you where you need to be, but that’s going to be another post.  This post is more of a shame on you post.  Anyone out there who uses a new term, particularly one in a foreign language without explaining it first, shame on you!  Anyone out there who proposes there are silver bullets in project management, shame on you! And, anyone out there who proposes there are silver bullets in project management, uses a new term to label it, AND charges a lot of money for it, shame on you!

I strongly believe approaches like Agile, Kanban, and others bring a lot of potential value to programs.  Customers don’t need snake-oil nor do they need silver bullets.  What we have here is, a failure to communicate.

I was thinking, maybe I should start a practice that will solve all you’re problems and call it Verbesserung.

Any takers?