The Methodology Question

I was halfway out on the 5k when my third brain cell (The Spare) kicked in with a connection between project methods and best practice and how each becomes part of the other. Exciting stuff for 0530, but that is what you get when the two active brain cells are occupied with walking and talking to yourself.

Lately, we have been discussing project methodology.  How the methodology came to be, the best practices contained in the methodology, and where the best practices come from – vendor, individuals, group consensus – or anywhere else.

Our PMO has an established project flow process.  There are several versions of a base model – usually tailored to the type of project: 

This is the delivery model, which at times changes from project to project, based on customer requirements and anticipated project outcomes:

There is a step for “Closure” also, but the base is Define, Develop, Accept, Pilot, Production. Simple and easy to understand, but also easy to skip something like getting acceptance prior to moving to pilot.  However, this model also dovetails with the PMO version.  I will wait right here while you compare.

These models were put together after much introspection by many who have come before and are based on “Best Practice” – a noble sentiment.  In some cases, we can clearly see where the term is derived – vendor specific “BP” is easy to spot.  At other times, the action you and/or your team takes is not governed by a vendor or the PMO, it is the result of aggregate lessons learned and is almost always a small detail point rather than a gross phase.  Lessons like this are most likely learned the hard way.  The hard way to the point where you make an immediate change in behavior to avoid the hard way ever again.

There was a time when I was hot stuff.  I had just been hired by an MIT grad who held multiple technology patents.  He received my name from a big vendor up in Washington.  I was in demand. One day I was assigned to write migration documentation for OCS/OCS R2 to Communications Server (Lync) 2010.  I got this project because I was The SME, so I charged off and got to work.

Six weeks later sees our hero arriving at Building 33 to deliver 147 pages of absolute perfection.  The publication editor took one look at about half of the table of contents and tossed it on the desk.  He added words that added up to “unacceptable dreck you moron” – very politely phrased, but you get the idea. How can that be if Mr. SME wrote it?  It’s the most wonderful deliverable ever!

However, I neglected rule #1: “Ask the customer what they want or expect.” I broke protocol and failed to follow our methodology. I heard one thing and proceeded to accomplish it which resulted in absolutely perfect dreck.  The customer wanted a different format, wanted it done in their tool, with pre-defined content categories and arrangements. Uh oh. 6 weeks of 100% billable straight down the drain. In the words of Bugs Bunny, “What a maroon!”

Now  I always ask the customer about their expectations and how they plan to measure success.  Based on my experience the question needs asking every time!  Ergo, I added asking that question to my personal methodology.

How closely do you follow our established project methodologies? The individual elements of the project methodology are there for a reason.  For instance, do you ALWAYS wait for customer approval before moving forward?  How do you meld your personal methods into the controlling methodology? Have you asked the customer in great detail what they expect as deliverables and how they measure success?  Did you discuss all this with your PM?

I’d rather do all that than walk out of Building 33 again.