PM Articles > PM Perspectives > Holistic Methodologies: Six Sigma and PMLC/SDLC Are Odd Partners, But Harmonious Relatives

Holistic Methodologies: Six Sigma and PMLC/SDLC Are Odd Partners, But Harmonious Relatives


Have you ever wondered how challenging it is for a movie star to be thought of as anything but a movie star? I can think of two movie stars who stepped out of their screen roles and used their talents to become notable politicians -- Ronald Reagan and Arnold Schwarzenegger. During this transition they were able to use many of their skills as actors to present their platforms in a very eloquent and convincing fashion. For them to change their roles as actors and to be taken seriously on the political stage was an uphill battle, which they eventually overcame.

I think the same can be said for tools that we tend to stereotype as belonging to a specific methodology such as Waterfall, Agile, or Six Sigma. It is almost sacrilegious to think of them being used in other methodologies, especially by methodology zealots. I think more holistically of tools and use them when appropriate, regardless of their origin.

In this series of articles, we will explore the opportunities that exist with adapting some Six Sigma tools for your toolbox and applying them to your projects. Along the way you will also get an introduction to what Six Sigma is all about, and why some organizations embrace it and feel it is so important to their DNA.

Think about these three questions as you read on. Think holistically!!

  1. Why do we manage projects?
  2. Why are there projects to begin with?
  3. Does the customer always know what they want or what is best for their processes?

Why Do We Manage Projects?

Have you ever thought about whether Risk Management is a subset of Project Management or vice versa? If you think of Project Management as a subset of Risk Management you got it right. It is an interesting juxtaposition to think about as you manage your projects going forward. The use of a project management methodology is a risk mitigation strategy, as you are using tools, industry best practices, and the most important asset, common sense, to control the risk inherent in the project. While it is important to manage risk as a subset within the project, holistically risk management is the reason we manage projects. Risks are present due to the project's uniqueness and expected constraints on time and costs, and project management helps us mitigate those risks.

Why Are There Projects to Begin With?

This sounds a little existential, but I remember a comment the Queen of England once made: "We exist at the sufferance of our subjects." Only with the will and sustenance of the people can they maintain their position and reign.

The same can be said for many of our projects. Think of several of the projects you work on or have worked on in the past and what role the product of those projects has had in the organization. I would hazard a guess that they are either to support the shareholder value, strategy, or mission, or to enhance core business processes that provide an invaluable service to the business customer. Once these projects no longer support those primary goals the organization should no longer suffer their existence.

Does the Customer Always Know What They Want (Or What Is Best for Their Processes)?

If it seems like a loaded question, well, it is. As individuals, how do we make decisions? We may use intuition, emotion, political gain/power, facts and data, or in some ways all of the above. How many times have you managed a project when you have felt it was the wrong thing to do, then found out afterwards that it did not solve the problem or created other problems that were unforeseen at the time of inception? If we are honest, we have all experienced that nagging doubt in the past, even in a successful project. Solutions driven by Voice of the Customer (VOC) sometimes are myopic when they are also missing the Voice of the Process (VOP). Are the metrics coming out of the process telling a different story? Here's one example of VOP vs. VOC:

  • VOC –Our packages are arriving at our destination 2 days later than expected.
  • VOP –Approvals to create shipping labels are taking 24 hours and are created at the end of the day (after the last pickup).

As illustrated above, the actor (VOC) in the process is reacting to a symptom and not the root cause. In a later article we will explore how other tools can be used to ensure the project is addressing the root cause.

Why Do These Questions Matter?

These three questions strike at the heart of why companies embrace Six Sigma and use the VOC and the VOP to validate the reasons, scope, and priority for the projects they initiate. Quite often, project scope is created based upon gut feel or seemingly "obvious" solutions. While many project needs are obvious (such as compliance, specific platform/toolset, or other financial/regulatory drivers), many projects are driven by reacting to the symptoms or executive whims.

Organizations that have matured to Level 4 in the Capability Maturity Model consistently and effectively use data from core processes to drive decision making along with prioritization for continuous improvement. These data can then be used to confirm the validity of the project scope. Starting with a problem statement vs. a scope statement will help identify success criteria vs. what will be delivered.

A question we should also be asking when we initiate a project is "What does success look like and how can it be measured?" We often overlook the need to analyze how the product of the project will impact the associated core business process(es), resulting in projects that only resolve symptomatic problems or create other problems.

When teams start with a problem statement and incorporate VOP alongside VOC they are implementing the technology to improve capacity, reduce defect levels, and improve process capability. The solution can be clarified and validated, especially since the data from the VOP is without emotion or bias. Another point to consider is if the data gathering provides data that can drive decisions about the process capability. It is important to ensure that data variance is eliminated from the way the data is gathered. Care in data gathering will rule out data collection variance, so what remains will be variances from the execution of the process from a "normalized data set" which is what you will need to drive root cause analysis and improvement options. Failure to do this can result in incorrect conclusions deriving the root cause of the problem. You must be prepared to look objectively at the VOP data, which may result in the product not being as "obvious" when taking all the functional and non-functional requirements into account. Typical business and technical requirements documents may not expose this gap, but VOP and a normalized data set can.

So What Is Six Sigma?

Six Sigma is a set of tools and techniques designed for process improvement. I am not going to cover Six Sigma in a technical manner as it is not important to this topic, but there are several excellent resources online if you're interested. As with project scope identification, it is important to know where a process starts and where it ends to identify if the improvement is in or out of scope.

Below is a layman's description of the Process Re-engineering phases within a Six Sigma DMAIC lifecycle -- one of the primary Six Sigma methodologies.

DMAIC –Process Re-engineering (Evolutionary Change)

  • Define –Problem statement and operational definition of the limited scope using SMART parameters
  • Measure –Identify the start/end (domain) of the process and document the "as is" process to determine where measurements will be made and how the measurements will be made ("Listening post" and "Measurement System Analysis and Calibration" concepts)
  • Analyze –Analysis of the normalized data received from the listening posts identified from Measure to draw conclusions on what decisions can be derived from the data, including root cause analysis
  • Improve –Using a Payout Matrix and Design of Experiment to create the basis for a PMLC/SDLC initiation through close, and documentation of the "to be" process
  • Control –Did the improvement made in the PMLC/SDLC project make the expected difference to the core process? Is the process still in control after the improvement? (Retrospective ROI from the VOP standpoint)

People who initiate projects have a tendency to jump to solutions instead of doing some due diligence when the risk or cost of error are significant. One approach that comes to mind when in this position is the 5 Whys -- asking why we are doing this five times, drilling down each time to determine if there is a fundamental reason why we are doing this or why we have chosen this solution. Some of you may know that this technique is used in root cause analysis also (both are Six Sigma (Analyze) tools). In any case, sometimes it pays to be a kindergartner.

In a Six Sigma world, the initiation through closure of a PMLC/SDLC project encompasses the Improve and Control phases of the DMAIC lifecycle. It also controls when a project is over, since you know you have met your success criteria by your metrics, operationalization through your SLA/OLA documentation, or certification cycle leading to shipping of your product.

Even when companies use Six Sigma methods in the problem resolution lifecycle, prior to a PMLC/SDLC project there is still a tendency to stereotype tools as belonging only within their distinct methodology, "Keeping the movie stars as movie stars." This can lead to the tools not being used to their full potential across methodologies. For example:

  • Requirements gathering and prioritization: Are there gaps between the VOC and VOP (juxtaposition between what the customer wants and what the process wants)?
  • Scope and risk validation: What can go wrong with accepting scope into the project (failure modes of scope and feature delivery)?
  • Retrospective ROI: In addition to looking at the financial benefits realization, did the retrospective also examine the functional benefits realization (improving process capability or performance or workplace health and wellbeing -- often intangible)?
  • Is the process still in control after implementation? Did the product create other process instability or make it more error prone?
  • Did the product of the project create unexpected consequences? Did it break something else?

All of these and many more concepts we will explore together as we look at creating and using holistic methodologies to deliver value to the customers and processes that we exist in sufferance of.



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

Post a comment




(Not displayed with comment.)









©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 info@projectconnections.com
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

Got a Question?
Drop us an email or call us toll free:
888-722-5235
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.