blended project management

Have you tried to blend agile methodologies into your traditional waterfall world?

Did you get a tasty stew?

….Or a culinary disaster?

I like to cook, but I’m not exactly a purist.  By that I mean that I almost never follow a recipe exactly.  Instead I treat a recipe as more of a guide.  Sometimes I omit ingredients that my family doesn’t like; other times I add in ingredients to see what the affect will be. I often combine a couple of recipes together, mixing and blending ideas from several sources.  Sometimes the result is a wonderful creation that suits the tastes of my family.  Other times, we take a bite and reach for the pile of take-out menus.

I find myself taking the same approach to development methodologies.  Like most of you, I find traditional, waterfall methodologies to be too rigid, too slow, and too removed from reality.  Their assumption that everything about a project can be known and documented up front has always struck me as laughable.

But when I look at pure agile methodologies, I find them too rigid and idealistic as well.  Successful projects need a framework around them; they can’t be driven simply by empowering a team to prioritize a backlog and deliver chunks of code.  Project components need to be fit into a larger vision and architecture; organizations need to have a sense of scope, plan, and budget.  Large, complex systems can’t always be nicely packaged in 2 or 3 week sprints.

So I find myself mixing and blending.  Take a few waterfall concepts like a defined project scope, written business requirements, defined technical architecture, and a project plan.  Blend with an agile development window where the project team can work through detailed requirements, development, and testing together; shifting priorities as business needs change.  Garnish with some user testing, training, and release planning.

Maybe this is agile book-ended by just enough waterfall to frame the work that the agile teams will take-on and integrate their work with the organization’s larger planning processes.  Maybe this is diluting agile precepts by subjugating them to overreaching controls.  Some call these approaches “waterscrumfall”; some call them an abomination.

My experience (and the experience of at least one of my colleagues) has been that a pragmatic blending better suits the needs of most projects and most organizations. It creates just enough structure to tame the chaos while recognizing that projects can’t be and shouldn’t be totally defined up-front.  It ensures that project deliverables fit into the larger enterprise architecture and meet strategic objectives.  Yet it takes advantage of the agile team’s strengths, allowing them to drive the project’s pace and details.

What has your experience been?  Have you tried more blended approaches?  Have they been successful?  Or have they resulted in the equivalent of a culinary disaster?

One Size Does Not Fit All

One size fits allHave you been to the mall and purchased a shirt that says “one size fits all” for the size?  While the shirt may fit some of us perfectly, it might be too large or too small for others.  The same goes for a project.  This “one size fits all” mentality for all projects can put your smaller projects at great risk by bogging them down in a project management methodology that is too rigorous for the size of these projects.

 So what can you do?

Establish a flexible project management methodology framework

  1. Define what a “small” and “large” project is in your organization (e.g., a small project can be between 6 – 12 weeks and a large project is anything greater than 12 weeks)
  2. Identify the deliverables or documents needed for each project type
  3. Monitor smaller projects to validate the success/failure rate of these projects and adjust the deliverables within the framework as necessary

The key point to remember is that the project management methodology is a framework for all projects, not a straitjacket.  The framework needs flexibility to support all projects, no matter their size, while producing results.

One size really does not fit all, so find the size that fits your needs to successfully manage your small project.

5 Warning signs that your methodology needs a reset

Project methodologies tend to grow dysfunctional as time goes on.  The breadth of their standardization increases until the only person who really knows how to use it is the methodology owner.

Too many templates, too many standards, too many hours required for initial training and training on new templates and standards, and perhaps too many good resources moving on to other employers with a less rigid approach.

To find out if your project management methodology is heading down the wrong path, look for these warning signs:

  1. You have a full time position dedicated to policing methodology compliance
  2. Your methodology manages by standard and template instead of by desired outcome and requirements
  3. Your methodology continues to get bigger over time, and details with little or minor influence on success have never been pared away
  4. Your projects are taking longer to implement
  5. Your project sponsors are growing more frustrated with each project you attempt to implement

resetThe methodology should be a guideline, not a noose, for organizational projects  – supporting the strategic goals of the organizational ecosystem instead of drowning in a pool of standardization. If you see any of these warning signs, maybe it’s time to hit the reset button.