Project Management Methodology

Projects are like a box of chocolates

How many of us remember the famous quote from Forrest Gump, “Life is like a box of chocolates. You never know what you’re gonna get.”? Being assigned a project is a little like that box of chocolates – you never know what you are getting until you take that first bite. A project is like taking that first bite of chocolate – unique, but having enough similarities to fit inside the chocolate box.

  • How do you determine the best methodology when you start a project?
  • Do you have a PMO that dictates the methodology?
  • Are you in a company that has adopted Agile as its methodology?
  • Are you using Waterfall?
  • Or, as the project manager, do you have the authority to determine the best methodology for the project based on its assigned team, scope, timeline and cost?

Like that box of chocolates, each project might be unique, but it still needs to work within an agreed upon methodology that is flexible enough to support small to large, complex projects. If the methodology cannot handle the flexibility, it needs to be re-evaluated to support all project types within the organization.

Create a project methodology that supports all project types by defining the critical project artifacts for each project type (e.g., small, medium, large). At the end of the project, perform an analysis of the project and determine what worked \ did not work, and adjust the project artifacts to suit the project.

How?

  1. Determine the methodology framework – Agile, Waterfall, WaterScrumFall (blend of Agile & Waterfall).
  2. Define what artifacts are needed for each project type – then map the processes using a tool such as Visio and share the process with others.
  3. Projects are more than producing documentation because that is what the PMO dictates – involve and evolve your PMO to a strategic partner.
  4. Provide feedback to continuously improve the process.

Projects are like those chocolates. We can savor each project’s unique flavor and make each a success if we follow a standardized approach that can also flex to support the uniqueness of each project. The approach should be like the chocolate box, able to accommodate each unique shape within a larger, coherent framework. Our job is to understand the uniqueness of the chocolate while appreciate the box in which it sits.

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?

Does your PMO get in the way of your Agile Development Teams?

Do your agile teams have your PMO pulling their collective hair out in frustration?

A family in harmony will prosper in everything. ~ Chinese Proverb

Does this sound familiar:

We value face-to-face conversation We need formal, written documents
Working software is our primary measure of progress Where is your status report?
How are you progressing against your project plan?
Self-Organizing Teams Defined Roles and Responsibilities
Individuals and Interactions Processes and Tools
Respond to Change Follow a Plan
Culture of Change Culture of Order

You’ve embraced an agile development methodology, empowered your teams, and they are eager to move forward.  They want to deliver a quality product to the organization as quickly as possible.  They want to add value and make a difference.

Your project management office (PMO) understands and supports the agile development approach, but they still need to manage the overall project portfolio and they want to be sure that the agile teams deliver in alignment with the organization’s strategic objectives.  They want to add value and make a difference.

Both groups have the organization’s best interests in mind, but there is a definite culture clash.

Agile teams can be dismissive of the PMO. Their approach is different, they don’t need to worry about those processes and frameworks; they just need to focus on their own project.  The PMO should get out of their way.  It reminds me of a teenager who wants their parents to just leave them alone – until the parent is needed.

PMOs can act like a dictatorial parent.  They can demand process and procedure from agile teams because that is what they’ve always done.  But process and procedure that doesn’t add value does get in the way.

Both groups need to respect each other and adapt.

Just like the parent of a teenager, the PMO should be loosening the rules and allowing greater freedom while demanding accountability (and standing by with a safety net). The PMO has to adapt itself to the agile world,  working with the agile teams to understand the tools that they are using to manage and control the agile project.  It should adapt these tools to their use rather than making the agile team use the same old PMO provided reports and templates.

The agile team, like the teenager, also needs to acknowledge and respect the role of the PMO.  The project and the project team aren’t operating in a vacuum.  It needs to fit into the larger organizational plan and processes.  So the agile team needs to fit itself into the framework that the PMO has established.  That may mean complying with certain project checkpoints or processes, such as conducting a formal risk analysis or establishing a milestone-level, project plan, budget, and scope.

If each can recognize that the other is not purposely trying to obstruct them and understand the value of the other to the organization, they should be able to leverage on another’s strengths.  While there may still be friction and areas of disagreement, the end result should be a set of processes that improve project outcomes and ensure alignment with overall organizational objectives.

How Life Insurance Companies Can Use the PMO to Improve Outcomes of Agile Projects

The Agile approach used in software development helps projects respond to unpredictability.

What? Unpredictability?

Life insurance companies are founded on predictability! How can Agile work at insurance companies, the reigning rulers of predictability?

In an informal examination of multiple large life insurance provider websites, the following key words were found (multiple times/places):

  • Preserve
  • Long tradition
  • Security
  • Base for building
  • Permanent
  • Fixed
  • Deeply committed
  • Dependable

So how can we, as project managers and program managers, fuse the “traditional” insurance corporate cultures with Agile projects that are based on evolving, iterating and changing?

A PMO initiative can help manage the point where predictability has to meet unpredictability, and blend as peacefully as possible in the project world:

  • Work with project teams and vendors to ensure agile terms, practices and goals are understood and met
  • Instill a level of commitment for agile projects that meet and align with overall project goals
  • Help set up or enhance proper Agile governance for projects and vendors
  • Assure that all integration points between multiple projects are identified, efficient and manageable
  • Perform ongoing scope analysis while adhering to the Agile philosophy of shifting and reprioritizing as necessary
  • Initiate risk analysis and align with the Agile methodology
  • Provide long term, short term or interim leadership in overall project work and Agile core competencies
  • Supplement resources to help with project and business area gaps
  • Guide project managers, sponsors and stakeholders throughout the agile process and provide ownership and stability with this methodology
  • Keep a balance of traditional project reporting and documentation while managing everyday Agile shifts and changes

As daunting as it may be for “old school” companies, exposure to Agile projects is inevitable. Managing Agile in a predictable way allows insurance companies to understand what it will take to adapt to the Agile project mindset and advocate the change.

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.

 

Avoiding Agile Anarchy

Agile project management

Conventional Agile Methodology Wisdom lists three factors that define an Agile-ready project:

  1. High Uniqueness
  2. High Complexity
  3. Aggressive Deadlines

After using these three parameters to select your first agile project, there is still legwork to be done before sprints are humming along.

Many agile initiatives are announced by fiat with the team structure, sprint length and other basic rules of the road mandated by the Agile Initiative Sponsor. They dive right into development sprints, gathering user stories along the way to build a backlog. Here are some ways this approach could backfire:

  • In a rigid, hierarchical organization, the ability of teams to self-organize is often historically non-existent, and the change management hurdle might be a gap too big to jump. There are many ways that interoffice personalities and politics can sink an agile initiative in its early stages, or at any point along the way.
  • Complex, unique projects require some upfront work on architecture before the development sprints can begin. Agile teams can best manage this by making the first few sprints architecture sprints. Time and again, we have seen horror stories when the overall design or architecture is glossed over:
    • Parallel agile teams within a business design disparate UI’s to enable functionality that is essentially the same, but serves the needs of one particular product group. Before long, it’s obvious that external stakeholders are confused and put off by having to remember two different ways of interacting with the same company
    • User stories are taken down as the basis for development sprints, but they fail to consider the secondary stakeholders. BI reporting needs are often missed.
    • Prioritization of the backlog is driven by business need, without any attention to building foundational pieces first, then layering on transactions.

In short, Agile without Architecture leads to Anarchy, and a lasting bad impression that will taint future Agile efforts. It’s best to look before you leap and take time to address any Agile readiness gaps.