Project Practitioners > How can one size fit all?

How can one size fit all?

By Margaret de Haan

I've been discussing a lot of development philosophies lately, and I find it amazing how many people think that one methodology (theirs) is superior to all others in all situations. I agree that in the interest of efficiency and effectiveness there needs to be known structure throughout an organization, but is there really a methodology that is a "one size fits all"? I don't think there is.

So, if we take a look at a number of Project methodologies (of which we have a quite few to choose from), let's consider Waterfall, Agile & RAD, Six Sigma, and JAD to name a few. When we peel back the layers of the onion on these process structures, we see that there are a variety of differences with: durations for deliverables; approval gateways; and documentation standards. So how can there be one methodology that would be a perfect match for all situations? Looking further, we also need to consider that there are different needs represented by different Project types in an organization – just think of the differences between the needs of a support Project versus that of a custom web application? And what about the differences in external clients’ needs and expectations versus those of your internal Marketing department? If we utilized Six Sigma for a small Support Project, isn’t that a square peg in a round hole using a large amount of time to do tons of analysis in the front end (Define, MEASURE…Analyze……), and what about Waterfall in the same situation? Isn’t that a bad fit as well?

I have recently had a long conversation (OK, more like a debate), with another IT professional that believes that Agile can be modified for every situation. Of course what he described to me for a long-term software development Project was a Waterfall hybrid! Yes it still had morning "Scrum Master" meetings, but it was still attached to the daily tasks on the (Long Term) Project Plan, and the "releases" were just minor groups of functions that were sent over to QA for testing. So was this Waterfall with phased testing, or Agile? Tomato or tomahto, right?

Well, my thoughts are that one-size-does NOT fit-all. So what is a possible solution to this conundrum? How do we take something that is inherently rigid in nature (process) and make it flexible enough to fit most, if not all types of Projects? My answer is to put in guidelines with ranges of effort and length of deliverables as a guide to determine how the Projects are to be managed. There are commonalities that all of these Projects have that can be utilized, with the core driver being the expertise of the Project Manager leading the team. Instead of organizations placing an inflexible process in place, let’s start allowing Project Managers to not just follow an existing Project process blindly, but to use their knowledge and skills to define both the necessary process steps and the documentation required to get the job done as efficiently as possible. One of my earliest Projects when I was working as a Sr. Process Change Analyst was to review and revamp a company’s development methodology that had become out of control. Once the existing process had been mapped, it was discovered that there were over 70 separate documents required to complete every Project, and over 30 of those required some level of signoff from client representatives. Yikes! Talk about analysis paralysis! Every Project required a very serious amount of effort before anything of value was ever accomplished, and the company was wondering why their "methodology" hadn’t increased productivity, and had actually slowed development down to a crawl. Once it was thoroughly reviewed it became pretty obvious. Recommendations made by our team were to define a core set of necessary documentation (with specialized document templates available if needed) and only those stage gates required client signoff. Prior to the Scope, and once the Project was approved and funded, the assigned PM would define what the Project flow would be, and would present that to the stakeholders, with an opportunity for their input. This flexibility increased productivity, and made a huge difference in the PMO’s bottom line. The take-away is that flexibility and a knowledgeable Project Leader WILL save time and money.

Now I know that there are 800 pound gorillas out there that are set in their ways, and where this type of thought process will be a hard sell, but my suggestion is to start small, and get the powers-that-be exposed to the idea of some flexibility in documentation requirements. You really don’t have anything to lose but some bureaucracy, right? Give it a shot and start thinking about how we can change our processes to make them better and more efficient – as we all want the ability to make a major impact to productivity as well as make our jobs better. It could be that I’m missing something here, but most (if not all) of the companies that I have worked for have created rigid practices that in many instances just don’t fit certain Projects. Let’s think flexible instead.

Lean, Mean and Flexible, that my new mantra.

Margaret de Haan

Not all comments are posted. Posted comments are subject to editing for clarity and length.

Good advice! Thank you for sharing...

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.