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?

Chinese_character_採_cai3_pick

Just Pick 3

Fast away the old year passes, as the song goes.

It’s that introspective time when we all review the victories and defeats of the last twelve months and come up with a list of resolutions.

How long was your list last year?
How many of those goals did you attain?
Did you come out of the gate in January with a bang, and light a fire under 10 or more action plans, or did you attack your list in a prioritized sequence?
How did that work out for you?

In any year where I made a lengthy list, I ended up frustrated before February rolled around, and never looked at my list again. I just couldn’t achieve the progress I envisioned.

This year, I am going to do something different, and I think you should too.

By January 1, I will pick 3 areas to focus on in my work and personal resolutions. When I have achieved the desired results there I will pick 3 more.

The best way to do this is to pick 3 goals phrased as metrics you can measure.

Start your list. What do you want to change? How will you measure it?

Decide what is  most important.

Then, just pick 3.

homer_simpson_doh_02

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.

fear

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.

Are You an Effective Leader?

Edgewater ConsultingI’m a bit of a history buff and I recently finished reading Jeff Shaara’s new book “The Smoke at Dawn” which focuses on the Civil War battle for Chattanooga.

The book has me thinking about what makes an effective leader. At the beginning of the novel, one general has every advantage, but focuses on the wrong things. While the other general begins at a major disadvantage, focuses on the right things, and ends up winning the battle.

The novel reinforced some core leadership principles that were good reminders for me.

  • First and foremost – where you decide to focus your energy matters. You can allow your attention to be distracted and squandered on the petty minutia or you can keep yourself focused on key goals. An effective leader doesn’t ignore the details, but does know what is important and what is not. An effective leader actively chooses to spend most of his or her energy on what is important.
  • Second, you need to identify a goal to be accomplished and share that vision. An effective leader ensures that everyone on the team understands what the goal is, why the goal is important, and the part they play in making the goal a reality. Even the “reserve forces” play an important role, and they need to be told what it is.
  • Third, you need to listen to and trust the people in the trenches. An effective leader listens to the team’s problems and removes roadblocks. He or she also listens to their ideas and lets them experiment with different ways to reach the goal.
  • Fourth, you need to recognize and acknowledge the efforts of the team, even when they don’t succeed. An effective leader holds people accountable, but also helps them learn from mistakes.
  • Finally, you need to recognize, acknowledge, and act to correct your own mis-steps.

So in brief, the refresher leadership course I gained from reading a novel. It seems that others have found similar inspiration:   http://blogs.hbr.org/2014/07/what-made-a-great-leader-in-1776/  http://theweek.com/article/index/259151/lessons-from-lincoln-5-leadership-tips-history-and-science-agree-on

So — What leadership lessons have you drawn from unexpected sources?

 

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.

 

Diagnose Your Inefficiency Potholes

potholesMany employees tend to complain about work-related inefficiencies as much as Wisconsinites bemoan the craters (aka potholes) left in the roads each winter. In response, companies usually acknowledge that making improvements is critical, and do their part in researching Enterprise Resource Planning (ERP) options. But, are all work-related inefficiencies exclusively due to a legacy system? Are people jumping the gun in assuming so, or are they misidentifying a process problem? Could some of these issues disappear by making a few simple process adjustments? Without empowerment and support, all the technology in the world won’t move your business forward.

There is no exact formula to determine if a problem stems from a bad system or a bad process; but asking yourself some basic questions could help you figure out where the problem lies. For example:

  • Would implementing new process improvements really resolve the problem?
  • Could implementing new system functionality resolve the problem and also provide a competitive edge?
  • Do the system benefits outweigh process benefits?

The following steps should aid you in your diagnosis and decision-making:

Create a problem Inventory 

Interview Subject Matter Experts (SME’s) from the various departments affected to develop a problem inventory list.

Identify process-related problems

Identify all process-related issues from your inventory list. Ask yourself: What is the root cause of the problem? Is there a lack of communication, lack of enforcement, or lack of an actual process? If you answered yes to any of these questions, the problem likely stems from a process issue.

Examples of process-related problems include:

  • A customer is upset that they’re getting bounced around
  • Sales Agents aren’t required to track or manage lead information
  • No official process for returns exists. (If an actual documented process cannot be provided, there probably isn’t one.)

These items may also range in severity. While going through this process, consider assigning priority levels or at least identify quick fixes.

Make process improvements where possible

This step is important because it improves overall business processes and productivity by making identified improvements. It also validates problems that can be resolved realistically. This step may take a few weeks to a few months to transpire, but it provides important insight and brings the process to the next step.

Focus on system-related problems

Once process-related problems are identified and resolved, one is able to ascertain that the remaining problems are system-related and decide if a new ERP system would be advantageous.

Examples of system-related problems include:

  • No visibility to inventory availability
  • Multiple customer masters, item masters, and vendor masters
  • Manipulation applied to reports (current system lacks reporting functionality)

This step will not completely resolve a company’s problems and inefficiencies, nor will it guarantee employee satisfaction. It will, however, allow for a more focused approach when considering solutions. It also provides the added benefit of some inexpensive process improvements along the way.