project management lifecycle process capability presentation and commentary

©2014 Project Portfolio Excellence, Inc. Distribution of this material is encouraged in its entirety.

A presentation and commentary on the benefits of Project Management Process Capability assessment.

I’ve added notes to convey the ideas that I talk about when I make this presentation.

Feel free to share and socialize this publication. Send me any questions or comments you might have.

Printing for distribution is encouraged as long as the copyright notice is included.

Color printing is advised to best preserve the graphical information.


Every time I have the opportunity to speak to a new client or prospect, at some point I work the following question into the conversation:

I’ve been asking this question for years and the responses are consistent. If I’m speaking with IT, they usually describe the good relationship they have with their Business “partners” and how they consistently deliver quality results and value. If I’m speaking with someone on the Business side of the house, however, the answer is usually quite different. How would you answer my question?

Is your company getting the expected

value and benefits from its enterprise software and software-related projects?


The next question is:

Once again, the answer depends on who you’re speaking with. Senior managers might express that production quality may not be perfect, but for the most part it’s good. However, it should also be noted that recently more executives are expressing concern about poor quality in the production environment, some to the point of being worried for the future of their companies if these quality problems can’t be resolved.

On the other hand, Business Professionals (the people who perform operational processes on a daily basis) will more likely paint a picture filled with applications that don’t work the way that they’re supposed to, with data that is inaccurate or incomplete, with systems containing contradictory data and functionality, and with projects that never seem to get it right when it comes to fulfilling the needs of the business. They tend to blame this on IT. But we’ll see in this presentation that the real problem is larger in scope and scale. Take a moment to think about how you would describe your Production quality.

If your company is like most others, you’re not receiving the value and benefits that are envisioned when projects are approved for funding and execution. It’s been reported that projects fail to achieve scope, budget, and schedule goals and objectives over 65% of the time. Whether that percentage is correct, or even close, isn’t as important as the fact that, for most companies, the lack of value and benefits received from projects calls into question whether many projects should have been approved in the first place. And the poor quality that most companies are experiencing in their production environments results in a huge waste of time, money, and energy devoted to addressing post-implementation quality issues and deficient functionality. Generally speaking, this should be a fairly accurate description of your company’s current situation. If it is, then the final question to be answered is:

How would you describe the level of

quality in your production environment?


If your answer is yes, then the following pages will give you some ideas as to how to start analyzing your process capability in order to correct process weaknesses and increase the value and benefits received from your software-related projects.

Let’s begin with a definition of value:

Would you like to improve the results you’re getting with your enterprise

software and software-related projects?


What is meant by “Process Characteristics?”

- Strategic direction is determined by Senior Management.- Tactics are designed to fulfill the strategy.- Operational Processes are created to support the execution of Tactics.- Projects develop tools to enable Operational Processes to be executed.

The diagram at the bottom of the slide depicts this relationship.

We’ve heard for years about the importance of Strategic Alignment of IT to the Business. The reason alignment falls short is because the majority of projects are proposed, selected, approved, and funded at the departmental level. In these instances projects are aligned to the department, and not necessarily to the enterprise. This creates a risk of sub-optimization of project benefits and apotential waste of time, money, and energy. The remedy to this situation is Portfolio Management with the portfolio being owned and managed at the enterprise level.


What is meant by “Operational Factors?”

When we talk about “Operational Factors” we mean Capabilities, Capacity, and Constraints. If you’re not currently getting the results that you expect from your software and projects, chances are that you’re violating one of these attributes. Each of these factors can be gauged and quantified, although few companies implement formal processes to do so.

As a result, many projects are approved for funding and launched even through:

- The skills and capabilities required for success are not totally present- The capacity (time, money, resources, etc.) is not available- Organizational constraints make success with the project unlikely

(maybe even impossible)

In most cases, deficiencies in operational factors can be determined before the project is launched which can not only prevent project failure, but can allow otherwise lost resources to be redeployed to more value-adding efforts.


Now let’s take a look at the Project Management Lifecycle process and discuss how Process Capability applies.

This is a high-level view of the Project Management Lifecycle (PMLC) process. It’s not concerned with the particular development methodology employed, but is more concerned with displaying the big-box components of the Project Lifecycle and the ownership of each of the components.

Notice that the various process boxes are shaded, either green or red. This shows that more than half of project activities are the responsibility of Business.

I’m a firm believer in the idea that there’s no such thing as an IT Project. I believe that the justification for every project lies in the value and benefits the Business will gain through the investment of its resources. Project justification is critical since company resources, especially time, are all limited, and there are always many promising initiatives competing for funding.


Consider:

Vision, Justification, Selection, and Prioritization are all Strategic functions in the PMLC and should be managed at the portfolio level. When these are managed at the departmental level, there’s a greater risk that decisions will be made that benefit the department at the expense of other departments or the enterprise.

This possibility, coupled with the limitation of resources that was noted earlier, substantiates the need that these critical decisions be managed at the enterprise level, either by Senior Management or by delegates who can be trusted to understand and act in the best interests of the enterprise.

The Vision, Justification, Selection, and Prioritization processes should rely heavily on input from Business and Technology Professionals since these folks are most familiar with operational constraints and process requirements. Senior Managers create and direct the Strategy, but Business and Technology Professionals should be consulted when it comes to Tactical and Technical considerations.

Senior Managers understand strategic direction


Consider:

Defining, designing, and validating the tactical elements that will support the achievement of strategic directives must be overseen by the people in the company who have the greatest understanding of the business processes that are executed every day – the Business Professionals. Their knowledge needs to go beyond simple “happy-path” understanding, and include knowledge of how exceptions to normal processes are handled. It’s the exceptions that are most often missed when project requirements and specifications are documented.

These folks are the ones who everyone goes to when weird things happen. They’re also the ones who spend much of their time dealing with the “crisis of the day.” It’s hard to get on their calendars, and it’s hard to get them into project meetings. But, make no mistake – when you build project teams based on who’s available instead of who needs to be in the room, you greatly increase the probability of project failure.

Project expectations should always reflect the availability of critical resources.

Business Professionals understand operational processes


Consider:

Technology Professionals build the tools that enable the operational processes that support the tactics that fulfill the strategic directives (kind of like the house that Jack built). Unfortunately, there’s a communications gap between Business and Technology Professionals that contributes greatly to the frustration and dissatisfaction many companies experience with software-related projects. Neither Business nor Technology Professionals have a complete understanding of the big picture that would allow them to succeed with projects on their own. Therefore, effective collaboration is necessary for project success. This is why the Agile methodology can be successful when properly practiced.

In our attempts to decouple the stages in the PMLC, we’ve created a condition where requirements are thrown over the wall to IT. By the time User Acceptance Testing happens any mistakes, oversights, and miscommunicationshave been baked into the product. Greater success occurs when Business and Technology Professionals work together throughout the project lifecycle.

Technology Professionals understand systems development


The preceding three pages offer validation that Senior Managers, Business Professionals, and Technology Professionals all have critical roles to fulfill if we are to succeed with software-related projects. I refer to the three groups collectively as The Project Triad. If any of the groups of the Triad is unwilling or unable to fulfill their responsibilities, the probability of project failure is greatly increased.

So how does this pertain to Project Management Lifecycle Process Capability? Well, if these three different perspectives aren’t adequately represented in your project management lifecycle methodology, it’s impossible to have a capable process. Without the proper balance and appreciation of strategic, tactical, and technical concerns, projects can’t successfully enable the operational processes needed to support tactics that fulfill the strategic directives of the organization.

Strategy without Tactics is wishful thinking. Tactics without Strategy is chaos. Strategy and Tactics with sub-optimized Technology are feeble.


What is “Process Capability?”

If your manufacturing processes resulted in 65% of your products not meeting specifications, you would surely conduct an investigation. If your order fulfillment process resulted in customer orders being filled incorrectly 65% of the time, you would undoubtedly have to figure out what was going wrong.

If, as has been reported, projects fail to meet expectations 65% of the time or more, why is it that companies don’t question the methodology that is being used for project execution and management? Too much time is being spent assigning blame for failures and not enough time determining why we fail.

The Project Management Lifecycle is an enterprise-spanning process. We previously illustrated the need for involvement by the three groups of The Project Triad. This substantiates the idea that the PMLC process is owned by everyone. Therefore, when a project fails, it’s EVERYBODY’s responsibility.

We need to stop worrying about whom to blame and start working to figure out why the current approach and methodology is failing to return the expected results. We can start this investigation with an assessment of our Project Management Lifecycle Process Capability.


The value and benefits that are expected from a project play a large part in the project selection and approval processes. But if Process Capability is lacking, any attempt to forecast value and benefits from projects is guesswork.

Many companies face an ever-increasing number of project requests, and they’re looking for ways to increase throughput and decrease costs.

Increasing the velocity of a bad process just creates poor quality faster (something many companies are increasingly experiencing in their Production environments).

If your current process is incapable of creating results of acceptable quality, how can you make any meaningful decisions regarding the cost of that process? You can’t control the cost of quality until you understand what quality costs. And until you can consistently achieve quality, you can’t measure what it costs.

Until you can perform a process effectively and consistently, any initiatives to improve efficiency or reduce costs will be useless.


You can see from the statement above that there are two components that determine Process Capability:

1) Having a process that is capable of producing quality results2) Being able to effectively execute the process

You have to be able to execute the process effectively and consistently beforeyou’ll be able to determine whether the process is capable of producing quality results and value.

It’s also important to point out that the process we’re talking about is not thediagram on the wall, it’s the process in real life. Often, when I ask if there’s a formal PMLC process I’m shown a detailed process map that, upon further investigation, bears little resemblance to the way in which project work is actually performed.

If you find that you’re consistently disregarding your formal, written process in order to get work done on time, the process is incapable and needs to be fixed.


If your process is perfect but you’re unable to execute it effectively, no matter what the reason, you won’t achieve the value and benefits that you expect from your projects.

If your process is flawed, then no matter how faithfully you execute it you won’t get the expected value and benefits.

If you ineffectively execute a process that’s flawed in the first place, then I guess you have the worst of all worlds. But, until you develop the ability to consistently execute the process, you won’t be able to meaningfully measure and analyze it to see if it’s capable of giving you the expected results, and you won’t be able to determine where the weaknesses are. The order of events is:

CONSISTENCY of execution enables the analysis of theEFFECTIVENESS of the process, which reveals opportunities forEFFICIENCY improvement initiatives.


The picture above displays three elements that are critical for Process Capability. I refer to them collectively as The Project Trinity.

“It doesn’t matter how badly you want it or how desperately you need it,

if you don’t have the skill, the will, and the capacity to achieve it.”

Too often, it’s assumed that we have the skill, it’s taken for granted that we have the will, and the concept of available capacity is totally misunderstood.

Underestimating the importance of any of these factors leads to poor project results and wasted time, money, and energy.


By now you should understand the importance of PMLC Process Capability for successful projects. Next we’ll look at how Process Capability can be evaluated.

There are three main points within the PMLC where evaluation can be made. These are illustrated by the blue arrows in the picture above. The three areas are:

1) During the various levels of testing that occur during the Software Development Lifecycle (Unit, System, Integration, etc.)

2) During User Acceptance Testing3) After implementation, when deliverables are used and supported in

production and quality-related issues are discovered and reported

When issues relating to Process Capability occur, it’s important to conduct Root Cause Analysis to determine where in the process the error happened and what caused it to occur.


When we first looked at the PMLC diagram, we noted that it’s comprised of strategic, tactical, and technical elements. Process weaknesses can occur in any of these elements. For example, we just talked about the importance of Capacity for project success. If, during Project Selection and Prioritization (a Strategic element) capacity is not properly considered, more projects may be approved for execution than the organization can successfully manage, resulting in negative consequences (project failures, poor quality results).

When Root Cause Analysis pinpoints the where, how, and why of a breakdown in the process, that information can be used to improve the process so that the same mistakes are less likely to happen again in the future. We want to build a feedback loop into the process, as is depicted in the picture above.

Also, consider that just because we’re aware of a process flaw doesn’t necessarily mean that we have to fix it (after all it could be an expensive problem to fix). But knowing our weaknesses allows us to plan for the future with a greater understanding of our true capabilities and constraints.


We illustrated the three points during the PMLC process where a lack of Process Capability can be identified. To reiterate:

1. Defects found during testing are not simply an indication of incompetence or human error. Many times they are the symptoms of an incapable or broken process.

2. Poor quality in the production environment indicates a lack of capability of the PMLC process to produce the results (value and benefits) that were envisioned for the project.

3. Customer or Sponsor dissatisfaction with project results shows that somewhere between receiving and understanding the vision for the project, and creating a product to fulfill that vision, the process broke down.

You can’t improve project results until you figure out why you’re getting the results you’re getting.


Quality-related issues, whether detected in testing or reported in Production, are symptoms of the lack of Process Capability. Although, most of the time, these issues are treated as simply problems to be fixed, they represent opportunities for investigation into the flaws in project-related processes.

It was mentioned earlier that being aware of a problem doesn’t mean you have to fix it, at least not right away. But the better you understand your organizational capabilities, capacity, and constraints, the greater your chances of successfully planning projects and initiatives that don’t exceed your abilities.

Every time a project comes up short, in terms of meeting plans and expectations, it can be considered an indication that the plan exceeded the ability of the team in some way.

You can’t blame every project failure on bad luck, or “Acts of God,” and if you blame your failures on the people involved you’re way off base.


Just as there are real gains that can be achieved with improved PMLC ProcessCapability, there are real penalties that will be suffered if Process Capability is ignored. The consequences listed in the above slide will translate into actual time, money, and energy lost… forever.

We hear a lot about making the most of limited resources. But, when it comes to PMLC processes, there doesn’t seem to be much improvement happening. When you consider the resources that are wasted directly on projects that don’t return expected benefits, plus the ongoing costs that most companies face in addressing quality-related issues in Production, it seems obvious that something needs to be done. Also, consider that for many projects:

Scope is becoming more complex,Schedules are becoming more aggressive, andResources are becoming more overloaded. It’s easy to see that SUCCESS WITH PROJECTS WILL BECOME EVEN MORE DIFFICULT


When we design or adopt a process we assume that when it’s executed, desired results will be attained. We can’t know this for sure until we verify the results after executing the process. Here’s how to verify process results:

Step 1 – confirm that we’re able to execute the process according to design. (If we can’t, we need to adjust the process or improve our capabilities.)

Step 2 – confirm that we’re actually executing the process according to design. (If we’re not, we can’t analyze the results in a meaningful way.)

Step 3 – confirm that the process produces the expected results when executed according to design. (If it doesn’t, figure out why our expectations were off.)

Step 4 – confirm that the expected results do, indeed, deliver the expected value and benefits. (Once again, if not, what did we miss in our thinking?)

In order to validate the effectiveness of your process and, therefore, its capability, these four steps must all be carried out in the given sequence.


Another way to think about the levels of Process Capability measurement.

Dimension 1 – Adherence: The equivalent of a checklist. This would assume that if the action items on the list are performed, the expected benefits will be realized. In many companies, this is as far as Quality Assurance goes.

Dimension 2 – Compliance: Taking it a step further and confirming that the items on our checklist are being performed according to predefined methods. This promotes standardization, which is good. However it doesn’t enable analysis of value and benefits attainment. We’re not yet where we need to be.

Dimension 3 – Effectiveness: Analyzing and confirming that the process, when executed according to design, produces the expected results, value, and benefits. Achieving this level of process understanding is necessary in order to meaningfully manage and pursue continuous process improvement activities.

If you don’t understand your PMLC processes well enough to improve them, you’ll continue to suffer the same mistakes and frustration over and over.


How do we start? Operational:

From an operational standpoint here are some things that can be done:

1. Stop thinking of defects in testing and quality issues in Production as simply problems to be fixed, and recognize that these represent valuable opportunities to gain knowledge into PMLC Process Capability.

2. Institute a formal process of post-implementation (or post-warranty) interviews with project sponsors and major stakeholders (especially product users) to determine how well the end results met their vision, expectations, and business needs. Information gathered in these sessions can provide insight not only into design and developmentcapabilities, but also into vision and justification processes that drive project approval in the first place.

3. Most importantly, as a better understanding of your true Process Capability is gained, adjust expectations of the process accordingly. As you discover areas of weakness, you can proactively decide to improve them or manage around them. But you should no longer be helpless to unwittingly fail because of them.


How do we start? Educational:

From an educational standpoint, here are some things to consider:

1. Everyone who is involved in project work (all three groups of The Project Triad) needs to be educated and given a common framework of the importance of Process Capability, the Value of Quality, and the tremendous costs of waste when it comes to the Project Management Lifecycle process.

2. Any current checklist processes should be further defined to include the specific steps to be taken during process execution. Make sure that anyone performing processes is trained appropriately.

3. Employ metrics that cover all three dimensions of Process Capability measurement (the “Whats,” the “Hows,” and the Reality.)

4. Remember the four steps in assessing Process Capability:1) That you have the ability to execute the process as defined2) That the process is actually being executed as defined3) That execution to definition leads to expected results4) That expected results provide expected value and benefits


How do we start? Organizational:

Some organizational considerations:

1. Knowledge Management, Training (including cross-training), and Continuous Improvement are all enterprise-level considerations. If they’re not promoted and supported from the top, they will not be sustainable. Therefore, as new faces enter the ranks of top management, make sure they understand the organizational valuesthat they are expected to nurture and cultivate.

2. The lack of formal Knowledge Management and Training processes leaves open the possibility that when critical employees leave the company, their valuable knowledge and experience is lost with them. Proper Knowledge Management protects against this danger and provides the foundation for continuous process improvement.

3. Organizations that display higher process maturity also benefit from lower turnover, higher morale, and greater ongoing success.


In summary:

Ask yourself the question. If your results are unsatisfactory is it because your Project Management Lifecycle processes are:

1. poorly defined?2. poorly designed?3. poorly executed?4. or just incapable of returning the value and benefits that are expected?

It’s definitely one of the choices above. So the next question is:

Are you ready to do something about it?

Is your company getting the expected

value and benefits from its enterprise

software and software-related projects?


I hope this presentation has moved you to consider whether your current Project Management Lifecycle processes are adequate and, if not, whether an assessment of your Project Capability could be valuable.

Feel free to contact me with any questions, comments or suggestions you haveabout these ideas. You can keep up with news about PMLC Process Capability through the Project Capability blog, the monthly newsletter and on Twitter.

Visit the website for information about the several ways you can start assessing and improving your software and project results:

Project Portfolio Excellence, Inc. And remember,

Project failure is a process problem, not a people problem!

http://www.projectcapability.com

http://eepurl.com/Ls4_H

http://www.twitter.com/PM_Capability

http://www.projectportfolioexcellence.com

project management lifecycle process capability presentation and commentary

Business

production quality

project portfolio excellence

majority of projects

softwarerelated projects

instances projects

softwarerelated projects

level of quality

quality results