Methods or Madness?

Have you ever heard the phrase, “Never discuss religion or politics with your coworkers?”  After meeting with a group of peers for drinks and gossip the other day, I would like to add one more item to that piece of contemporary wisdom: methodology.  Nothing seems to fire up a group of project managers quite like the topic of project management methodology. 

 It all started innocently enough.  Someone made the offhanded comment that they were struggling to complete scoping out a project because “The business can’t seem to land on a set of detailed requirements for their software.”  This of course elicited the response from across the table, “Why are you gathering detailed requirements in the scoping phase of a project?  You should be focusing on defining the objectives in the scoping phase.”  The rest of the discussion felt a bit like a tag-team cage match in which the last one standing was the winner.  The debate raged on… “What should be done when?”  “How much effort should be put into project scoping, planning, executing, controlling?”  On and on and on.  By the end of it, our waitress was studiously avoiding our table (which was bad because by then I could really have used another round!)

 In addition to confirming what geeks my friends and I are, the discussion did get me thinking about the types of PMO methods I’d encountered, and even built over my career.  I’ve been blessed with the opportunity to see a number of different ways to plan and manage projects, and I’ve learned from some of the best in the industry and the real answer, I believe, is there is no single answer to what is the best method to manage a project, program or portfolio.

 Project Management was born to manage the triple constraints: Time, Cost and Scope (or Quality if you prefer).  Depending on what business function the methodology grew up in, it seems to often contain not only the discipline necessary to scope, plan and manage an initiative, but also includes tools, templates and artifacts that are  specific to developing a product of some kind.  Let me explain.

 One of my earlier attempts at developing and documenting a project management methodology was for an IT organization within a manufacturing company.   My Sponsor, the CIO wanted an end-to-end methodology that could be used by his entire team to ensure the work the “business” asked them to do was sized, planned, resourced, and implemented correctly.  The methodology we built in this case was a blend of project management, business and technical requirements writing, waterfall software development life cycle, and a touch of organizational change management, all thrown together in a spiffy flow chart and a binder of templates that could be used for anything the business threw at IT.  And it worked!  It worked so well that other functions within the business wanted to use it.  The only problem was, Finance didn’t develop software, nor did Marketing or human resources.   You see because we blended Project Management AND Software Development methods into one… we actually limited ourselves in our ability to utilize common methods across the entire enterprise.  BUMMER!

 Later in my career, I was able to work with a retailer to implement more of an Enterprise level PMO and Project Management Methodology.  Guess what the first task was...  Yep, we had to “decouple” project management from a whole bunch of other “methodologies” being used around the organization.  Instead, we developed and rolled out a Project Management framework that every function used to scope out ideas and to work with their cross-functional partners to plan and manage approved projects.  In the end, IT focused on SDLC, Finance had financial planning and budgeting, Marketing had a method for creative development, campaigns and events, etc…  All operating under a common framework to scope, plan, execute and control initiatives, regardless of what function it was initiated by.  Painful to transition?  You bet.  Worth it?  Absolutely!  What we ended up with was:

•  a single, standard, cross-functional way for the organization to scope out ideas and decide which ideas would move forward
• a common way to articulate across the organization what initiatives were priorities and which ones weren’t, and
• a standard way to articulate schedules, resource requirements, changes, risks, budgets and status that anyone in the organization could understand.

 An additional benefit to this particular way to set up a project management discipline was each function could determine what “workflow” or method would work best for their group.  For example IT could decide on waterfall or agile, depending on the needs of the individual initiative.  HR didn’t necessarily need to turn in a blank “Technical Spec” document for a training initiative simply because the project management binder said they needed one.    The Project Management process and templates were “owned” by a single group that resided within business operations, with input from each of the other functions that would be using the tools and techniques.  Changes to the methods were released, communicated and trained to all project managers and leaders so everyone was on the same page.  In the end, everyone was pleased that we had a corporate standard for project management, and separate methods that could be used by individual functions depending on what product needed to be created. 

 If you’re still reading after all of this, you probably would have fit right in to the discussion the other night.  My point is this, methods are often created from the perspective of the primary sponsor, and to fulfill the needs of that particular function.  It’s absolutely NOT a one-size-fits-all answer. 

 Are the methods YOU use to mange projects at your organization able to cross boundaries to be used on ANY type of project, or are they specific to your function?  Maybe it’s time to end this debate and let Project Management be used as it was intended, to be a cross-functional way to manage expectations, and be used to support a TEMPORARY effort to create something UNIQUE, regardless of which function starts it!

Daniel Estby is an expert in program and project management, change management and communication with broad experience helping companies of all sizes to define, plan and achieve their objectives.  He can be reached at [email protected].