Week of the Elephant

I'm not sure of the origin, but as I was watching an adventure race years ago, I heard an awesome quote.  One of the contestants was asked how he was able to trek a 300 mile course, navigating so many obstacles through so much adversity.  His reply was "even an elephant can be eaten, if you do it a bite at a time".   Though I try not to whip that quote out every time one of my colleagues appears stuck on a project, I do like to bring it out for special occasions.  I think this may be one of them. 3 things happened this week, that rate the reference:  Work during the day, school, and work during the night.

By day, I'm an adviser to a Federal Project Management Office.  I'm not in a position to tell government employees what they should or should not do.  It's my job to advise and support them in any way I can.  This week, they asked me to attend an invoice meeting.  This wasn't a surprise.  Upon reviewing the vendor's invoice from last month, I wasn't satisfied the Billing of Materials (BOM).  There was a lot of stuff ordered and I am very particular about asset management.  I recommended a 7 figure short pay.  I don't think it's important to be specific about the amount.  My client decided to do a 6 figure short pay.  At the 2 hour meeting, we went line by line and the vendor offered corrective actions for items I recommended not be paid.  I accepted some of their proposed corrective actions but they still need to deliver on some promised if they want all of the invoice paid.  One month down, another to go.

Our son started Kindergarten this week. We weren't sure how he was going to take to it.  Until Monday of this week, we were convinced he was going to be crying at the bus stop, wanting to say home with Mommy.  We figured he'd come around in time.  Monday arrive and so did the bus.  He ran aboard almost before we could give a hug and a kiss goodbye.  He returned some 8 hours later and ran off the bus with a big smile on his face.  The adventures that boy had!  Here it is Friday night and he's fast asleep.  One week down, 16 years to go.

At night, I find myself reading the PMBOK® or project management blogs and writing PHP, CSS, and JavaScript. Back in March of 2009, I realized I wanted to create something to help project managers on a grand scale.  That's when I started doing mockups and wireframes for what was to become the HueCubed engine and PMPrep Flashcards.  One year later we launched version 1.0.  This week I worked on 2 new jQuery elements and tonight deployed v1.2.12.  The web application has been progressing nicely and both customers and affiliates are signing up.  Though I never thought we'd get to v1.0, I now do an iterative build and deployment at least once a week.

For those interested, I still have plans for a PMPrep Exam Simulator web app and Prince2 Flashcard web app.  And yes, we're going to be doing an iPhone application.

Graphic: South African Tours and Travel

A PMI Dog Pile

Upon reading a piece featured on PM Hut, Certifications Don’t Make Project Managers, I was compelled to comment...twice.  So, what's the short story? I've been reading more and more articles from people who seem to be down right hostile toward the Project Management Institute (PMI). Richard Morreale, the author of the article, wrote

The Project Management Institute (PMI) and the Association of Project Management Group (APMG) are two of the biggest reasons that projects fail.

Dr. PDG added

In short, IMPO, PMI and to a lesser degree, APM and APMG have become nothing more than the AMWAY or Mary Kay Cosmetics of the project management world

Here's the long story.  I enjoyed the article, to include the comments from the likes of Robert Kelly, PMP and Dennis Stevens (fellows I admire).  I'll admit, I've been getting a little incensed recently after hearing stories of people who appeared to have gamed the system and got certification with no real education or experience other than a PMP boot camp.  But, most of this is hearsay.  I have been approached by people, asking for my help, who want the certification for no other reason than to bolster a résumé.  I do believe these cases are extremes and hopefully isolated incidents.

Based on your motivations and character, the outcomes of getting your certification can be completely different.  I got my certification because, at the time, I thought it was the only way I would be taken seriously.  I was dealing with a stakeholder who was being completely unreasonable.  She had a PMP and ignored everything outlined in the PMBOK.  Clearly, she had her own agenda.  Mine was a quest for knowledge in my profession and to hone my skills as a project manager.  This quest has exposed me to several different approaches, to include Scrum and Kanban.  I think I am a better project manager than I was several years ago because I am receptive to new ideas and approaches and don't necessarily walk around preaching one as PM dogma.

So, where am I going with this?  I think if your mind is open to it, you can learn a lot from preparing for the PMP exam.  I also think you can learn a lot from taking a level 400 class in Project Management at a University.  But, you have to be motivated by the desire to learn and satisfy your customer's wants and needs.  Don't think a certification will get you that dream job or make you a PM expert.  It will come back and bite you.  Sometimes being a PM means working on a project with specific knowledge area focus.  But sometimes you will be exposed to full lifecyle management, dealing with every process group.  Either way, it's not all textbook.

I think Dennis Stevens put it very well in his comment:

a PMP is like a recent college grad, a medical resident, or a 16-year old who just got their license. They have some situational awareness from having participated in projects, have been educated in the fundamentals and share a common language. But they are not prepared to be CEO of a business, an emergency room surgeon, or a cross country truck driver.

Some will argue that guns don't kill people, people kill people.  Just the same, PMI and APMG don't cause projects to fail.  Sometimes it's the PM, sometime it's the customer, and sometimes it's something that wasn't on your risk register and should have.  The noble thing to do is to try to fix the problem.  Mentor an associate PM.  Give a talk on your area of expertise.  Tell people how you failed on a project so they don't make the same mistake.  I think if we all put forth a little more effort, in helping each other become better project managers and leaders, the results could be transformative.

PMBOK and detailing leadership

I read an article the other day over at Project Manager Planet. This work by Herman Mehling was titled "Project Manager or Project Leaders - What's in a title?"  It's a simple enough question but can have a complicated answer.  Herman points out that, for some, the titles are virtually synonymous. What can be confusing about the English language, at times, is different words can sometimes have the same meanings. In this instance, that is not the case. These are not synonyms!

Upon reviewing the PMBOK on the word, I found an uncanny absence.   It's really only mentioned a few times in the entire book!

Page 26 Project Managers...this high profile role requires

flexibility, good judgment, strong leadership and negotiation skills, and a solid knowledge of project management practices.

Page 240

Successful projects require strong leadership skills. Leadership is important through all phases of the project life cycle. It is especially important to communicate the vision and inspire the project team to achieve high performance.

Page 417 Appendix G

Leadership involves focusing the efforts of a group of people toward a common goal and enabling them to work as a team. In general terms, leadership is the ability to get things done through others. Respect and trust, rather than fear and submission, are the key elements of effective leadership. Although important throughout all project phases, effective leadership is critical during the beginning phases of the project when the emphasis is on communication vision and motivating and inspiring project participants to achieve high performance....

If it states on page 240 that successful projects require strong leadership skills, why is it not more thoroughly listed in the 4th edition?  If it's critical in the beginning phases, as listed on page 417, why is it not detailed?  Since "expert judgment" is listed as a tool & technique throughout the body of knowledge, I think PMI missed an opportunity to include "acts of leadership".  Perhaps we should start by renaming the 4th PMI process group from Monitoring & Controlling" to maybe include & Inspiring.

Thoughts on the topic?

Image Source: Flickr James @NZ

Expert Judgment and Passing the Sniff Test

Looking for two very informative posts on estimating?  Check out one by Josh Nankivel of pmStudent and Glen Alleman of Herding Cats.  Both are discussing estimating techniques that work for them. I wanted to take a moment to add my two cents. Though I certainly believe estimating should be more science than art, I look at estimates from a different perspective. As a disclosure, I'm not the one doing the estimating on this project, therefore I'm not going to say I agree or disagree with any one technique.  Depending on your situation, one estimating technique may provide more accurate results than the other.

What I would like to add, from my perspective, is the need for expert judgment. If you are an expert in a given estimating technique and it gives you the results you and your customer(s) need, does that not validate it as an acceptable estimating choice?

If the estimating technique does not produce the desired results, wouldn't it fail the metaphorical sniff test?

Recently, I questioned a vendor's estimate based on a different technique.  I used a parametric estimate to see if the vendor's estimate would pass or fail my sniff test.

What exactly is a parametric estimate?

An estimating technique that uses a statistical relationship between historical data and other variables to calculate an estimate for activity parameters, such as scope, cost, budget, and duration.  Source: PMBOK Page 439

So, why did the vendor's estimate not pass my sniff test?  As part of a standard estimating practice, software vendors should include time for fixing bugs. Upon review of a recent status report, I noticed the vendor reporting half as many bugs were discovered in a current build than had been estimated. When asked about this, the vendor was very excited to confirm that they indeed found half as many defects in the code they originally estimated and predicted a cost savings of several hundred thousand dollars to the project.  Going into the current build, I knew what the standard deviation was and considered the possible variance.  This fell way below that.

So, why were they discovering so few bugs?  At first glance, I would predict two possible reasons.  [1] Quality through development improved.  [2] Quality through testing worsened.  Either way, you get the same initial result of fewer defects identified.

We'll know the true answer once initial user acceptance testing begins.  If there were no baselines to compare the actuals to, I might not have given it a second thought.

Graphic source via Flickr: pump

Always have a plan B when negotiating

choiceAB

Too many times people, including project managers, freeze like deer in the headlights when asked what their contingencies are.  Rather than get all dramatic, in the event you may not get your first choice, you should know what your other choices are and assign pre-qualifying criteria to them.  Be prepared to negotiate...EVERYTHING. I hate making emotional decisions.  I do make them but not until after the logical decisions have been exhausted. It doesn't matter if you're trying to negotiate a new salary or deciding where you and a group may have dinner for the evening.  You should know what your options are and negotiate the best outcome.

If given the choice between A or B, when I want C, I commonly abstain.  This frustrates people, maybe because they are used to groupthink and they are trying to avoid conflict.  Some may think I'm being passive-aggressive or an obstructionist.  Actually, if I know what I want, I just won't settle (when I don't think I have to).

The PMBOK offers a few helpful negotiation points in Section G.8.

• Analyze the situation.

• Differentiate between wants and needs - both theirs and yours.

• Focus on interests and issues rather than on positions.

• Ask high and offer low, but be realistic.

• When you make a concession, act as if you are yielding something of value, don't just give in.

• Always make sure both parties feel as if they have won. This is a win-win negotiation. Never let the other party leave feeling as if he or she has been taken advantage of. (I don't always do this)

• Do a good job of listening and articulating.

Know your choices.  Don't settle.

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.

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

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