Holistic Methodologies: Odd bed partners (Six Sigma and PMLC/SDLC), but Harmonious Relatives
Project or Process? That Is the Question!
In a label-centric world where we try to find the right boxes to put things in, there is a tendency to use a label that fits for convenience or other corporate cultural reasons. Perhaps funding, prioritization or staffing models are the drivers, or the perceived nature of the work in the eyes of decision makers.
So who cares if a body of work is called a project or a process? Well, it comes down to how unique the work really is and how we go about getting the work done to deliver the product. At a high level one could argue that the lifecycle of a project is a process and that there are unique paths through even repeatable processes, which we call exceptions. Just how unique does the work need to be before we call it a project? And just how repeatable does the work have to be in order to be a process? There is no silver bullet, just a grey area. As long as you understand the distinctions and differences, you get to decide what you want to call your body of work going forward and what strategies you will use to get it done.
Let's start with the PMBOK Guide definition of a project: "A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. A project is unique in that it is not a routine operation, but a specific set of operations designed to accomplish a singular goal."
A process, according to Merriam-Webster, is "A series of actions that produce something or that lead to a particular result."
Before going too much further, the focus of this article is not the uniqueness of the project or process but the execution and delivery methods, as well as the other heuristics we take for granted when delivering a "project." The definition seems pretty clear cut on the surface; it is "temporary and unique" in nature as well as "designed to accomplish a singular goal." For those of us who perform similar projects where they use analogous estimation methods, or reuse risks that became issues along with other materials from similar "unique" projects, the demarcation may not be so clear.
Is it possible that a project is really a process that is executed only once, with its exceptions making it unique? Is a project a process "that leads to a particular result" where the only thing that is unique is the product itself?
Let's also explore the "temporary" nature of a project. Is it so temporary when projects are bound by releases of a given software/physical product, or even upgrades to an infrastructure OS or hardware component? How much is repeatable between software deployment versions? Isn't there a tendency to repeat best practices from prior projects and learn from risks and root causes experienced in similar projects? Are we also sometimes working with the same team members, stakeholder or customers? All of those things lend themselves to the continuous improvement we think is synonymous with process re-engineering and several of the tools we have discussed in earlier articles. However they also lend themselves to projects where we are striving to do the next project better than the last.
How unique is my project?
How many projects do you work on which are not "routine operations"? Do you develop new software? Upgrade or replace existing software or hardware that has reached end of life or efficacy? Chances are that a lot of the work you do is really not that unique at all, but the risk or diversity profile of the product drives the need to call it a project.
There may be exceptions, such as putting a man on the Moon for the first time, or a purely scientific endeavor like a cure for cancer where the product is research with an unknown outcome. I would argue that those products are truly unique in nature, but even these examples will lend themselves to some repeatable delivery methods using a proven, repeatable methodology lifecycle.
Running an agile project using Scrum or Kanban methods results in an even weaker delineation between project and process in the execution and delivery models. While the work product itself again is unique, the delivery model should be viewed as a process. As I showed in the Design of Experiment article, a core tenet of continuous process improvement is a team becoming more efficient using evolutionary methods. Using Kanban they focus on throughput metrics, whereas with Scrum we measure how many user stories or story points are delivered to calculate velocity or team performance capability. Both Kanban and Scrum are repeatable delivery methods/processes that are performed until the product backlog has been delivered or time/budget has been exhausted.
Processes also use throughput as a core metric, using control charts among other key performance indicators. Even the way work is introduced into the delivery lifecycle is a predictable process based on the capability of the team to "process" the work.
In Agile-Scrum, there is a Scrum Master and not a Project Manager. Could a Scum Master be looked upon as the delivery process owner?
By their nature, waterfall projects have a clear delineation between the phases of the project using stage gates or other methods. These stage gates could also be called swim lanes in a process chart of the steps performed to accomplish the exit criteria for each stage gate. In fact I have quite often seen process maps used to guide the user through phase gate deliverables as part of methodology tutorials.
Below is an illustration of the juxtaposition between project stage gates and how they also contain process-like attributes.
- Initiation -- A process or series of steps to kick off the project to get to a "particular result"; permission to move forward into planning and greater definition around what is to be planned.
- Planning -- A process to lead to the result of a baselined body of work bound by the triple constraint.
- Execution -- From planning the work to working the plan; the plan that you execute against is a baselined process that is only executed once during the temporary time box of the project.
- Monitoring and controlling -- Work quality and throughput. Both lend themselves to managing defect opportunities and execution process capability.
- Closing -- This is truly the only differentiator between a process and a project, however when a team is working on enhancements or releases, typically the team does not disband, but looks at the delivery of a release as a measurement point before embarking on the next release. Closing also controls the temporary nature of the project by definition.
Quality Assurance and Testing
Aren't regression testing methods just a process in disguise? A common set of tests are run expecting "to lead to a particular result." When bug glides are used to predict when a product can be shipped, are we not using yet another process or form of control chart to again to "lead to a particular result"?
Within a project we typically use tools as control points. Consider the following examples:
- Project schedule -- A Gantt chart is a process map for how the work will be scheduled showing the dependencies between tasks or steps and the actors who will perform the work.
- Communications plan -- This is a repeatable set of meetings, status reports and other communication points to govern the transparency of communication to the appropriate stakeholders in the appropriate format.
- Financials -- Budget/forecast variance and actuals, as well as estimates at completion, fit within a larger budget process lifecycle for the sponsoring organization. There is also a process for keeping the spend variance within specific boundaries to determine the financial health of the project.
- Risks management/Exception processing -- The risk responses are the process steps that will be taken to maintain control over things that could go wrong during the planning or execution processes.
- Issue tracking -- This is a clear process where the issue is identified, given an owner, and tracked through to resolution or a "particular result."
- Scope management -- As mentioned, this is the only truly unique component of the project, however scope can be in many ways repeatable when doing upgrades or enhancements of a legacy product or replacing obsolete hardware or software.
Process is by its nature repeatable where the product of the process is not unique. It can be argued that even a process is temporary in nature since each process has a distinct beginning and end point bound by an execution run. However the outcome of the process may not always be predictable when the process is out of control. For example, the product of the process may be unique in its quality as perceived by the customer, with the defect being the difference. The whole concept of the Six Sigma DMAIC lifecycle is to drive defects out of a process and create a reproducible/repeatable high-quality outcome within upper and lower control or specification limits. It can be easier to spot an out-of-control process than an out-of-control project, due to the ability to obtain consistent measures from listening posts within key process steps. Within a project, due to its perceived unique attributes, it is much more difficult to control variance and know when a project needs attention. Labels such as project health are often used in lieu of metrics, which tend to be subjective in nature unless tied to financial or schedule variance targets
Below is an illustration of the juxtaposition between the DMAIC lifecycle phases showing how they also contain project-like (SDLC/PMLC) attributes, which have been the basis for this series of articles on holistic methodologies.
- Charter/problem statement -- Also a core requirement in a project for scope and rationale/justification for the project to be done
- "As is" process map -- Baseline of current capability that can be used in conjunction with a gap analysis to define the to be state or "what success looks like"
- SIPOC -- Covered in an earlier article as a way to identify the role of the stakeholder and process steps in traceability of the requirements
- Performance measurements -- How we measure project execution variances (issues, risks, financial variances etc.)
- Voice of the Customer (VOC) and Kano -- In projects we gather functional requirements and determine what the customer wants the outcome of the project to be
- Value added vs. non value added -- Scoping (in scope, out of scope)
- Value stream mapping -- Another scoping tool for how the product will be operationalized
- Affinity diagrams -- How we build product backlogs and work breakdown structures
- Network diagrams -- Used for scheduling work within a project schedule
- Pareto chart -- Used for root cause analysis or what features will yield the most value from a Big Y perspective
- Process Efficiency --
- Process capability -- In a project case, the execution method for how to get the particular result in a predictable manner
- Process sizing -- How big does the team to execute the project have to be to get the desired result within the lowest cost and highest quality parameters?
- Measurement System Analysis -- Similar to the control points discussed above in project tools to demonstrate project health and progress
- Operational definitions -- Project glossary, definitions around project health and financial variance boundaries and risk triggers
- Fishbone diagrams -- Used for Root cause analysis during execution and post-delivery
- Cause and Effect Matrixes -- Risk and issues management within a project
- Brainstorming -- used for requirements gathering, risk and task identification when building work breakdown structures
- Constraint identification -- a core planning tool when putting together a textual project plan document -- "planning assumptions and constraints"
- Hypothesis testing -- Discussed in a prior article as part of using Design of Experiments; can also be used to conduct root cause analysis and defect analysis
- FMEA -- Another way of looking at risk management
- Regression analysis -- Used in building test harnesses for testing for particular results of known product capability
Note -- As mentioned in the first article in this series, "In a Six Sigma world, the initiation through closure of a PMLC/SDLC project encompasses the Improve and Control phases of the DMAIC lifecycle."
- Benchmarking -- Solution identification; RFI/RFP for vendor selection or a specific engineering tool, method or language chosen for building the product
- TPM or Total Productive Maintenance -- System of maintaining and improving the integrity of production and quality systems through the machines, equipment, processes and employees that add business value to an organization. You can substitute the word "organization" for "project." TPM is also synonymous with what the PM does to effectively manage the team and other control points within the project microcosm. TPM is broader in nature since it is also supported by the business or user community via autonomous maintenance, which is one of the TPM eight pillars.
- Poka-Yoke -- To make your product fault tolerant
- Piloting and simulation -- Prototyping and other agile methods of accreting value to a core product through iterations or user story delivery
- Solution Selection or Payoff Matrix -- RFP or RFI analysis for product selection, another example of this is the "Gartner Magic Quadrant"
- "To Be" process mapping -- Operationalizing; developing SLAs and OLAs as well as run books for deployment and delivery
- Replenishment/Pull systems -- In agile, how work from product backlogs is placed in the team WIP (Work in Progress) bin
- Line balancing -- The process of aligning operations within a specific production line to minimize production fluctuations and operational downtime. Line balancing is often closely associated with the manufacturing sector. However, it also can be applied to any process-based organization that delivers output on a frequent basis. Substitute "production line" with "project product deployment" or another component of Operationalizing and development of SLAs and OLAs as mentioned in "To Be" process mapping.
- Control Charts -- Project health via status reports, forecast variance/actuals, scope control methods, etc.
- SOP or Standard operating procedures -- Examples: How do projects get approved to go through their phase gates? How is change management managed throughout the project lifecycle?
- PDCA, Deming wheel -- Plan, Do, Check, Act (Plan, Execute, Test, and Fix). Does this sound familiar within a QA lifecycle?
- Visual process control -- Project documentation; manuals, data flow diagrams to communicate a common purpose of the product usage and capability as well as any safety concerns around use of the product
Common Tools between Projects and Processes
- Training plan -- Common between process and project specific to the product of the project
- Communication plan -- Common between project and process
- Project commissioning -- Continuous improvement project initiation
- Project replication -- Looking for best practices
- Implementation plan -- Speaks for itself
The only two things that are unique about a project are the processes we use to deliver the product and the product itself. Projects are made up of a series of discrete processes to "lead to a particular result." The more we can take advantage of repeatable process execution within a project the better chance we have for a successful outcome. What you decide to call your body of work is up to you and your performing organization.
As I hope I have illustrated in this series of articles, Holistic Methodologies, while being odd bed partners, are harmonious relatives. Projects and processes have more in common with each other than we have been led to believe by classical project management training and conventional wisdom. I feel there is a strong case for the intermarriage of the tools and methods to control your project or process.
Payoff matrix and Gartner Magic Quadrant™
Measurement Systems Analysis