The Methodology Question

I was halfway out on the daily 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.

Obit 2

We left our wannabe hero as he prepares to board a bus headed for Memphis. Information gaps acknowledged, but not yet taking responsibility for arrogance.

It seems that my life has been segmented by school or other life learning exercises. The break points in the memory flow have significant tipping points that define the next phase. Memphis was one also.

The bus trip up through Mississippi to Memphis was a learning experience all by itself. That story is best told in a different venue. School in Tennessee was a load of fun, surrounded by airplanes, systems, learning all sorts of things – attempting to resolve the information flow as the firehose was opened. New life, new career, new everything.

But, here is the point in time where learning forever was pushed into my little pea-brain…and it actually stuck the first time through. After checking in and joining the training command as a student, my first day in this new school had a block of orientation to the entire process from day 1 to 3650. They had a 10 year plan mapped out. After my initial training in fundamentals and theory, I would attend a specific course of instruction around electrical systems, power distribution, troubleshooting, and more system theory. Actual aircraft were used for testing skills. Overall process and governance was taught also as the standards were based on Naval Aviation Operations. So a system learned in one unit was transferable to the next unit, aircraft, or operations center.

What a concept.

Like maybe that type of thing should exist at any time there is human interaction with education needs, structures, process and larger organizations?

Bottom line was once I left this “school” environment I could expect to be attending further schools at least once a year. Type specific systems, communications, automatic flight controls, navigation, it just goes on and on. But the true value of this constant education and growth was the leader training that was endemic to the entire process. Each element fit into a larger matrix aimed at preparing the individual to manage technical work groups and eventually entire maintenance departments in extremely high stress environments.

After four or five years of this exposure and daily touching of the systems and technologies the individual is well prepared to start supervising others while they grow up through the system.

So, my value-add lesson was that I needed to accept the idea that I was going to be in a school of one sort or another for my entire military career. You were either going to be in a technical school, deployed, or in a leadership school. In between, you did your “regular job” in your unit.

Just one more nail in the coffin for the excuse of “I didn’t want to be in school anymore.” As it turned out, that is about all you do in the Marines; train, deploy, school. I had taken an action with a major goal of “no more school.” Oops.

And there I thought I knew everything. This error will repeat several times over the years. After a while, you learn to make decisions with imperfect data, but then you manage your risk differently – another lesson I learned the hard way.

Take whatever education is offered – you won’t know you need it until you need it and then it will be too late. Another twist is to be completely open to generic benchmarking – a term I didn’t learn until much later, only to realize I had been doing it all along.

Arrogance was not gone yet, but maybe the information gap lesson was learned.

YMMV