The Twelve Ps (maybe more) of Process Improvement

Often when I provide initial consulting for an organization I am shown procedures when I ask for processes, or shown a schedule when I ask for a project plan. As a result, this blog presents some of the basic terminology of process improvement. I’ve tried to write this in plain English, steering clear of specific model jargon.

Process Improvement, Purpose, Program Management Office (PMO), Project Portfolio Management (PPM), Policy, Process, Procedure, Program, Project, Plan, Product, People

Huh????? What's with all the words that start with P? Don't be fooled by simple alliteration. This is complex stuff and can lead to long, boring and unproductive meetings if you try to wing it. As a consultant, of course, I encourage any of you wishing to attempt process improvement to seek professional help (and I only mean that in the nicest way). For those brave souls out there charged with doing this on your own, here are some definitions to help clear the fog.

Process Improvement (PI) – You must have standardized ways of doing the things you do, else how would you get anything done. PI addresses three main concepts: process enablement, process implementation and process governance. Simply put, PI is a multi-step way of formalizing how to do the things you do.

The basic steps of process enablement are:

• Find a process reference model or framework that addresses your industry
• Get everyone on board
• Provide training
• Compare your current state against the reference
• Identify the gaps, prioritize them
• Assign a project manager to develop action plans to close the gaps, in priority order
• Assign a project manager to work the action plan(s) to closure
• Run the action plans
• Create the necessary process artifacts to support, enforce, enhance the new processes 

The basic steps of process implementation are:

• Decide which processes and steps are appropriate to the project under consideration
• Make appropriate process tailoring or waiver decisions and get them approved
• Follow the process for creating the project plan
• Execute the project in accordance with the plans for all the project lifecycle phases

The basic steps of process governance are:

• Use gentle audits of processes to ensure they are being followed
• Use gentle audits of the project work products to ensure they are fit for use
• Collect data (measures) that allow you to determine, objectively, if it’s working
• Ensure all project work products are placed under specified levels of configuration control

Purpose - People generally fear the unknown and resist change. In order to give yourself the best chance of making process improvement work, you’ve got to let the people know the whys and whats of this new process improvement initiative. We are doing this to enhance our ability to bid on new work, deliver excellent value to our customer, be more streamlined, productive, etc.  We're going to do this by soliciting your feedback on how you currently perform your job.  We will document that as the initial process, and we'll make incremental improvements as necessary, etc.

Program Management Office - The PMO is typically the group that defines and maintains the standards of process, within the organization. The PMO strives to standardize and introduce economies of scale and repeatability in the execution of projects. The PMO is the source of documentation, guidance and metrics on the practices of project management and execution.

Project Portfolio Management - PPM is a discipline for describing methods for analyzing and collectively managing a group of current or proposed projects based on key characteristics. The fundamental objective of the PPM process is to determine the optimal mix and sequencing of proposed projects to best achieve the organization's overall goals - typically expressed in terms of hard economic measures, business strategy goals, or technical strategy goals - while honoring risks, constraints and barriers imposed by management or external real-world factors. Typical attributes of projects being analyzed in a PPM process include each project's total expected cost, consumption of scarce resources (human or otherwise) expected timeline and schedule of investment, expected nature, magnitude and timing of benefits to be realized, and relationship or inter-dependencies with other projects in the portfolio.

Policy - Policy is the vehicle whereby senior management communicates their commitment to the way the organization will do business from this time forth. Policies emphasize the connection between the organization, its business goals and objectives, the individual projects within the organization, and how they all work together. They also put forth a guiding principle that the organization can follow and achieve. One overarching policy statement is usually sufficient if it references an organizational process document. Try to avoid writing a separate policy for each process.

Sample Policy Statement - We are committed to the effective management of our software development activities as the key to improving quality, productivity, and predictability for the benefit of ourselves, our business partners and our clients, customers and users. To support this goal, all software projects are required to comply with the Company's Software Process Framework (SPF), which outlines our software project development and management processes. Reviews, audits and assessments will be used to verify compliance and as the basis for improvement. Training and tools will be provided as needed to enable and assist in compliance.

Process - Process is a tool whose purpose is to assist an organization in improving its performance in critical business areas. The process is the means by which you achieve a business end; it is not an end in and of itself. The process is not the product. Too often an organization will set up a large process improvement group and this group becomes a goal for the organization and they lose sight of the fact that the organization needs to perform the work, and the process is just a tool. Processes should be written at such a level that a skilled practitioner in the art should be able to pick up the process and have a good idea of how the organization does business. Processes are the ordered steps followed by people, using tools, in accordance with standards, to convert inputs (either given to them or derived by them) into expected outputs.

Procedure - Procedures are the lower level steps that guide practitioners in how to perform a specific task. For Example: the process might instruct the analyst to perform analysis using one of the acceptable Object Oriented techniques. The supporting procedures might explain how to select from among the various acceptable techniques based on the complexity and criticality of the project, and might then further specify how to perform that technique or refer the practitioner to the textbook wherein the technique is further described.

Program - A program is a group of related projects or subsequent versions of a single project. When thinking of conducting an appraisal of an organization’s processes, it is essential that the appraisal looks at process compliance and effectiveness at the project level, as that’s where the work gets done.

Project - A project is the means by which an organization accomplishes its primary objective of producing goods or services in exchange for money (usually). Projects have a specific start and end and are undertaken for a specific purpose. A project is a temporary endeavor undertaken to provide a unique product or service.

Plan - Plans are the glue that binds all of the components of an organization into a roadmap for accomplishing a project. A plan essentially states who will do what, by when, for how much, to what degree of quality, and in accordance with what standards, procedures and practices. Other nice to haves are a statement of purpose, a description of the organization (including detailed contact information) and its geographic distribution, a description of the roles and responsibilities of the personnel who will be participating on the project team, various subordinate plans (risk, quality assurance, configuration management, measurement, communication) and a waivers, variances, exceptions, and escalation mechanisms. If you take all of the processes required to execute a particular project and put people’s roles and names to them and lay them out against a schedule, you have the beginning of a pretty good plan.

Product - Products are those entities, artifacts, documents, etc. that are produced as a result of following a process or procedure (e.g. doing work). Products are the result of executing a series of task steps or transforms on inputs. There is no sense in performing work that does not result in some sort of product/artifact that can be examined for quality or usefulness and, upon a satisfactory finding, used for a purpose. A product is a tangible artifact that you or your customer (either internal or external) expects you to make available by a particular date so they can use it (implies time, budget and quality conditions and constraints).

People - It is essential that all participants on the project team know what roles they will be fulfilling, how long they will be fulfilling them and for what percentage of their time they will play each role. There are many roles on a project and all contribute to the successful outcome. Some roles to consider are: senior manager, resource manager, project manager, architect, analyst, designer, coder, tester (many flavors), quality assurance, configuration management, trainer, measurement specialist, process specialist, customer, user, client, marketing, sales, accounting, help desk, field service personnel, installers, repair staff, system engineering, hardware engineering, etc. It is easily imaginable that all of these roles and more could be involved in a single software project. It is also easily imaginable that one person could be playing several roles on a single project. People are the resources that provide the energy that propels the project toward completion.