Home » Change Management » The One Perfect Project Management Methodology

Agile. That’s it. Agile. The perfect project management tool or methodology. You can use it in general project management. You can use it in software project management. Don’t Google it as you will get confusing things like agile project management and Scrum. You just want to be agile. Look it up in the dictionary. That is a much better source for the methodology.

So is this a change from my original position in The Ultimate Project Management Tool? No, they are complimentary. You pay attention and based upon that attention you — with agility — make changes as needed.

Agile project management tool jokeOK, yes, this is way too simple and I am being a bit facetious. So, why did I even bring it up? Is there a perfect project management methodology, tool or approach (software, IT, construction, health care, defense, financial, supply, etc.)?

Many people seem to think so. It comes in various names, acronyms and forms (Scrum, XP, PMI, CMMI, TSP, Prince2, Kanban, Lean etc.). If you have been managing for as long as I (30+ years) you’ve seen these come and go. I’ve also seen the hype come and go. I’m intrigued by the current hype around Agile. I’m a software and information technology (IT) guy so I pay the most attention to these fields. I personally love the agile software development approach called Scrum.

I’ve specialized in helping organizations move from late and low quality project deliveries to on time, high quality deliveries. Yet, I’ve never used one method. I’ve never used “my” method. I’ve always taken the current method of the organization and tweaked it to get them up to the next level of performance (usually to on-time with good quality). I’ve never seen the adoption of an all new methodology that then solved the problems of an organization. Never. In almost every case, there were underlying — often cultural and political — problems that undermined the methodology being used and they had to be fixed first. While I was at the Software Engineering Institute, it was an often stated maxim that no tool or technical methodology was going to fix a dysfunctional organization.

So is Agile the perfect solution? I read a great article by Cyndi Mitchell in Software Development Times, March 15, 2010, titled “The half-agile path leads nowhere.” I knew Cyndi and I must be on the same wavelength as she used the term “grok.” We weren’t. Or at least, not yet. I figure in a few years, we will be.

Her article talked about how doing Agile completely will reap all sorts of benefits. How not doing it completely will result in failure. I’ve heard this before. In fact, I’ve heard it from just about every methodology and tool evangelist in the past 30 years. For consultants and vendors it was often the excuse why we didn’t see the 10x improvement (or whatever promise was made) when implementing their tool or methodology. We were told that if we just did a few more things right, the magic would suddenly appear. They were also ready and willing to help us do it, for a price.

Perfect Project Management ToolHowever, I absolutely agree with Cyndi. The only difference is that we can take the word “agile” out of the article and replace it with just about any good methodology of our choice. My experience is that almost any methodology — when understood and executed well — will result in exceptional benefits. I know, because we’ve done it consistently for years.

Yes, I’ve seen techniques and methods that just didn’t have a sound basis. In particular, Theory X types where it assumes people are lazy, untrustworthy and need to be managed closely didn’t work well no matter how hard a group tried. I’ve only rarely seen an organization-wide approach with this problem. Generally we’ve experienced only individual techniques, often associated with individual managers, which had this flaw. Sometimes it was the VP — who asked us to help “fix” the issue — who was the source of the problem. In just about every case where I’ve dug into the failing methodology to understand it, I’ve been pleasantly surprised to find an innovative and interesting approach that had a lot of good reasons behind it (e.g., Motorola’s M-Gates). Using those reasons and “rediscovering” the methodology — while removing dysfunctional practices — were keys to our success.

For methodologies, I’ve seen many diverse approaches work and work well. For specific project and software management tools, not so much. This has been primarily because in trying to learn or adopt a tool, those organizations often get lost in the mechanics of the tool itself. Also, many tools add multiple features to try and make them look competitive or rich. Too often these other added features are just noise and not anything someone would want to use. In the consumer products industry we called these “table stakes.” These were things we had to include to even be considered by a customer. Many of these, we knew, were not great features but our customers insisted we have them because competitive products had them. They also looked good in advertisements.

Project Management Tools Methodology DebateFor those in the Agile versus Waterfall project management debate, I will comment that I’ve never seen a perfect waterfall approach. It was always a goal, a worthy goal we thought, to achieve that perfect waterfall (i.e., once a stage was complete it was done perfectly and it never had to be revisited). I do find the Agile evangelists often talk about “Waterfall” as if there was some perfect canonical form and that anyone doing it was doing the same thing. Just as there is “Scrum … but” in Scrum, there was always “Waterfall … but” in Waterfall.  “Scrum … but” is considered something negative, but for Waterfall, “Waterfall … but” was often an adaptation to make the “falls” more concurrent and iterative for an imperfect world.

I will offer that when we achieved excellence in software development, where we were making few mistakes — increasing productivity and hitting our milestones — the methodology we used inevitably evolved towards pure Waterfall from something that was almost always incremental (some said trial and error). Once a team got good at what they did, they didn’t want to waste time with iterations/increments and all the overhead. Pure Waterfall had almost no overhead — and we usually executed it using a concurrent engineering approach (i.e., if something could be started now, we started, even if we were still planning other areas).

The perfect project management method is the one we make work for us in our unique environment. The insight is that most well known methods, when understood and done well, will result in great project performance. The trick is to take our current approach and incrementally improve it to where we see the full benefits of our chosen methodology. Easy? No, but it is a project management tool that works.

Thank you for sharing!

28 thoughts on “The One Perfect Project Management Methodology

  1. Steve Hart says:

    My experience is that almost any methodology — when understood and executed well — will result in exceptional benefits. I know, because we’ve done it consistently for years.

    I am totally on-board with this statement. This is why our organizations focuses on “filling the gaps” with best practices/techniques. Changing methodologies is liking converting someone’s religion. Too much effort, and very little payback. Great Stuff!!

    Steve

    1. Bruce Benson says:

      Steve,

      Agreed. I’ve also seen too many solutions which were to bring in completely new approaches, and hence never addressed the underlying problems of why the in-place approaches didn’t work. Not surprisingly, the new methods — once they finally got most of the bugs worked out — didn’t perform any better than what had happened in the past.

      Sounds like you have a good approach. Keep it up!

      Bruce

  2. Mary Beth says:

    Excellent points that certainly hit home for me. Especially, the brief sentence of: The perfect project management method is the one we make work for us in our unique environment. In a recent email to me, Bob was sure that my current role would teach me something — definitely correct there! I’ve been thinking about that all week.

    I hadn’t realized how inflexible I could be in using traditional project management methodologies and in the way I like to work (bad me). Hey, the way I like to work is obviously NOT the way others work. And that’s okay – annoying to my obsessive over-documenting, overly organized little self, but okay.

    So yes, my current organization is forcing me to be flexible, negotiate, think more creatively, “sneak” in the best of the particular methodologies or tenets that might work here. Obviously I need to see this as a healthy and happy experience for me.

    I was originally hired to build a PMO. But in a company that wasn’t entirely ready to accept a PMO. So some PM tactics don’t work (and I need to figure out why and come up with alternatives more quickly) — MS Project and Gantt charts for example do NOT work. Formal Change Control – no WAY. I do these for myself only.

    But other things work really really well and are creating a sort of foundation for other incremental future improvements.

    For example, (and yes, this will sound basic and mundane) we actually now have formal business requirements documents — and this year, we actually are able to get business partner sign off on these documents to baseline them. Recently, my IT partner responded in kind with written, detailed IT requirements and resource allocation needs — also signed off and baselined. Yesterday, a core business sponsor on a new project actually READ and UPDATED with me a new BRD to ensure that her impacted business processes were correctly represented. Yup I was shocked and pleased when I got that call and made all the time in the world to coach her through the updates.

    Due diligence, lessons learned sessions, and documenting tasks/owners are all now acceptable. Project status reports are finally being asked for; 4 years ago, I quite literally was called into a VP’s office for providing a basic project status report. How dare I do that and demoralize a team? My only response was “huh, what?”. I was hired to build a PMO, a project status report is a norm. Right? There truly was nothing negative in the report (my reports are always quite black/white and factual) – 2 particular tasks were slightly off due date because of a vendor issue. But putting THAT in writing was an absolute no no. I hadn’t realized that no one had ever actually done a project status report – ever.

    In this environment the perfect PM “WAY” is to be flexible and creative; to create a subtle need for new PM tools. Not quite a method or “methodology” per se since there’s no real system or actual disciplined approach.

    In fact, my new email tag line has gotten some great comments too – and from the same VP who originally complained to me 4 years ago:

    * Show Up * Pay Attention * Tell the truth without blame or judgment * Be open, not attached to the outcome (“The Rules for Life” by Angeles Arrien )

    So I guess my opinion can be summed up as: “build a better mousetrap and the world will beat a path to your door” (Ralph Waldo Emerson), or “supply creates its own demand” (Say’s Law). Eventually, an idea will come alive when the need is realized.

    1. Bruce Benson says:

      Mary Beth,

      Great examples! I often called this kind of thing “guerilla management.” It was different from change management, in that it recognized that we still needed to get the job done, while we also tried to change (improve) the organization.

      I do find that people will support these things, when it helps them get their job done also. Picking and choosing those “this will help” things often provides an initial trajectory different from a classic “let’s implement a PMO” (that then tries to install each layer of methodology, independent of what is needed now to get the job done).

      “Brutal honesty” is often not much more than just black and white statement of facts. Yet to those folks not use to it, it appears “brutal.”

      Thanks for sharing.

      Bruce

  3. Bob Light says:

    Glad to oblige Bruce, and a good trade for the metaphor and additional great advice. It is easy to get caught up in “feature wars” and lose sight of the fact that the whole goal is to deliver real benefits that allow users to become more productive employees, not software experts or gurus….

    I look forward to your future posts!

  4. Bob Light says:

    An excellent holistic vision of the PM world Bruce. Any process is only as good as the people who are implementing and following it. I think that fact is often lost today, as talent, skill and experience are suplanted by technology that in theory guides us to do what is right, or at least someone’s vision of that.

    Admittedly, as a tool vendor, your comments on table stakes and over-featuring hits close to home, but the truth hurts sometimes..;>)

    Great post, thanks for the thought-share!

    1. Bruce Benson says:

      Bob,

      I think we just need to understand that not all features are created equal. There are great products available, it is just that not all features are individually great. Too often the “sound bite” of the feature name or description suggests a lot more than what we can achieve in actual use.

      Tools can be a huge advantage, when used appropriately. In the Air Force, I was helping to evaluate software development tools many years ago. Displayed was a vendor wiring diagram and process flow of how all the modules and functions worked together. It resembled a bowl of spaghetti but still looked very impressive. Nobody had any idea what it meant to us. I walked up to a white board, drew a stick figure of a person, and then assembled the modules (I labeled them capabilities) around the stick figure. To the Air Force team in the room, it now looked like a jet cockpit with a wrap around heads-up display. The modules gave the “pilot” (the programmer) enhanced capabilities in various areas. I drew another stick figure with modules and connected the corresponding and complimentary modules to the other stick figure (along with a “base/HQ” that contained the shared data and views used by the “command and control center” ). By the time I started on the third figure, who all seemed to be flying in “formation” it was almost humorously clear to everyone what this software tool intended to do for us. The key was I showed it centered on and giving “super” capabilities to the individuals – individually and collectively. This is a great metaphor that works outside the military just as well. We should show how the tools enhance individuals.

      Thanks for the comment and giving me the opportunity to share this metaphor!

      Bruce

Comments are closed.