In the Agile Manifesto it says, “We are uncovering better ways of developing software by doing it and helping others do it.” I have been paying attention to the conversations between the BUFD traditionalists, the Agilists, and now the Kanban communities. This conversation has not always been friendly – and some members of each community certainly aren’t looking to learn about better ways of developing software. In fact, the contentious debates are creating obstacles to helping others do it.

I find that there are valuable capabilities in each of the practice areas. Agile was never completely different than BUFD. It was 20-30% different. And that difference, when done well in the right context, dramatically improved the value of the software being developed and the velocity that it was delivered. Kanban is probably 10-20% different than Scrum, the most prominent instance of Agile. XP doesn’t really come into the discussion because XP practices will be applied in both of the situation. In the right context, Kanban will deliver dramatically improved value and velocity over explicit Scrum. After all, some companies have moved to single-unit engineer-to-order flow over small batches and realized dramatic improvements.

As I have been wrapping my brain around the distinctions and benefits, I keep coming back to Gerald Nadler’s book from the mid 1990’s, Breakthrough Thinking: The Seven Principles of Creative Problem Solving. Nadler had developed a meta-model for problem solving (solution finding) that has consistently delivered dramatic results. I am going to share the seven principles with you and then use them to talk about why I think the principles in Kanban can deliver results that are better than teams doing Scrum.

1. Uniqueness: Every problem is unique. You can’t directly copy a solution from elsewhere. Only if the context of the purposes shows it is useful should some available solution be considered.

2. Purposes: Always and continually ask the purpose. Then ask the purpose of that purpose. Expand as far as possible with this exercise. Focusing on purpose lets the uniqueness of the situation become clear and strips away nonessential aspects of the problem context.

3. Solution-after-next: Find solutions today that achieve the focus purpose, based on what might be the solution of the future. Having a target solution I the future gives direction to near-term solutions and infuses them with larger purposes.

4. Systems: Employ a format that includes all elements and interrelationships that the target solution will entail. Every solution or system is part of a larger system, and solving one problem inevitably leads to another. Understanding the elements and dimensions that comprise a solution lets you determine in advance the complexities you must incorporate into the implementation of the solution.

5. Limited Information Collection: Before taking the time and wasting the effort to collect and analyze extensive data, determine what purposes would be achieved by gathering the data. Study the solution, not the problem.

6. People Design: Throughout the process of finding a solution, give everyone who will be affected by that solution the opportunity to take part in its development. People are willing to explore purposes and solutions-after-next, rather than to gather data about what is wrong with the current system. Those who carry out and use the solution should be intimately and continuously involved in its development. Also, the proposed solution should include only the critical details, in order to allow flexibility for those who must apply the solution.

7. Betterment Timeline: Even as you design today’s solution, schedule future changes necessary to its continuous success. The only way to preserve the vitality of a solution is to build in and then monitor a program of continual change. A sequence of purpose-directed solutions and knowledge of the solution-after-next are bridges to a better future.

Scrum explicitly calls out several of these principles, particularly uniqueness, purposes, and people design. It provides direction that you should be looking for a way to remove impediments. It doesn’t explicitly provide guidance for doing that and a good, experienced manager is already applying many of the other principles. As I was telling Mike Cottmeyer this morning, a Scrum team in the right context will (and have) evolve into (many of) the Kanban practices.

Kanban explicitly calls out the rest of these principles. The Kanban itself becomes a framework for understanding the System and focusing on just enough information. The operations review is specifically in place to establish a betterment timeline and the solution after next.

Most of the Scrum teams dislike management and the other functional groups they interface with. The concept of pigs and chickens and the common perception that management causes obstacles for the team lead to conflict and distrust. Kanban focuses on how the development team can work better across the organization. From a purposes focus and people design standpoint, the Kanban perspective leads to greater trust and a shared focus on the solution-after-next.

Finally, many Scrum teams struggle with how to schedule defects and rework into their iterations. In the iteration world, QA gets the release after the end of the iteration for acceptance testing – this creates delay in feedback. This delay leads to all the relearning problems that we all have discussing. The enforced reduction in work in process and the single-unit flow reduces rework and shortens the time to feedback on defects and acceptance issues.

According to most reports, we still aren’t great a reliably delivering technology. No one has an answer yet that works for everyone. There is a lot of room for improvement and I believe we need to keep an open mind as we uncover better ways of developing software by doing it and helping others do it.

Last week I became an OPM3® Certified Consultant. After spending almost three years as the Deputy Project Manager with the volunteer team developing OPM3 Second Edition, I spent a week taking the OPM3 Certified Consultant course and passed the final exam. I have received a lot of questions about what that means and whether there is any value in it. There are about 100 OPM3 Certified Consultants in the world. I want to talk about OPM3, project management standards, getting organizationally mature, and what being an OPM3 Certified Consultant means. This might not sound exciting, but hang with me. There are very few organizations that won’t benefit from getting better at implementing strategy.

What is OPM3?

OPM3 is a standard that was first published in December of 2003 by the Project Management Institute. OPM3 stands for Organizational Project Management Maturity Model. Per PMI, “Organizational project management is the systematic management of projects, programs, and portfolios in alignment with the achievement of strategic goals. The concept of organizational project management is based on the idea that there is a correlation between an organization’s capabilities in Project Management, Program Management, and Portfolio Management, and the organizations effectiveness in implementing strategy.”

[There is some conflict in the terms process and capability. I will use the term capability consistently through my discussion. A capability describes “what you do and why you do it”. A process describes “how”. PMI doesn’t describe “how” in their standards even though they call them processes.]

To put this simply, organization’s have to implement changes in their structure, processes, management practices, and/or technology to implement a strategy. This is difficult but there are some capabilities that have been show to support them in consistently implementing these changes.  These capabilities can be categorized into effectively and efficiently executing projects, the coordination of multiple projects to optimize resource utilization and project performance, and deciding which projects are the best ones for the organization to invest in based on the organizations strategy. These are Project Management, Program Management, and Portfolio Management respectively. OPM3 uses the capabilities identified in PMI’s Project Management Body of Knowledge-4^th Edition, The Standard for Program Management-Second Edition, and The Standard for Portfolio Management-Second Edition. More on standards in a minute.

OPM3 wraps a continuous process improvement approach around these capabilities. For example, when implementing a project you probably want to manage the scope of the project. Within most organizations -most of the time, that means you have to gather requirements, define the scope of the project, and create a work plan when planning a project. There are a lot of different ways to do this. It may make sense on some projects to do this once at the start of the project and on other projects, you should do it iteratively and in progressively more detail. What organizations that are good at executing strategy do is they define how they are going to manage scope. Then they pay attention to how well this works continue to improve their method over time. This is organizationally mature.  OPM3 breaks the capabilities down into Standardize, Measure, Control, and Improve.

OPM3 also includes a set of Organizational Enablers. These are the capabilities that must exist in an organization to support the implementation and ongoing existence of Project Management capabilities. These include things like project management training, project management sponsorship, and other structural, cultural, technological and human resource practices.

You can pick up a copy of the OPM3 standard from PMI’s website for about $100. This standard describes the approach in detail, lists all the capabilities, and includes a nice Self Assessment tool in the appendix.

Project Management Standards

The Project Management Body of Knowledge (PMBoK) is a catalog of capabilities (called “processes” by PMI)  related to the management of projects. When the first OPM3 standard was published, PMI had not published standards for Portfolio Management or Program Management.  These first versions came out in 2006 and have been significantly updated with the simultaneous release of new Editions of the standards for Project, Program, Portfolio, and OPM3 in December of 2008.

The new standards provide a comprehensive catalogue of the capabilities that cover Project, Program, and Portfolio Management. These standards show the capabilities that will work in most organizations most of the time. They are based on years of research and the input of thousands of volunteers. They give examples of existing practices within the capabilities.  Despite what some critics claim, they don’t tell you “how” to implement those capabilities, just “what” you should be thinking about. They also don’t tell you to do all the capabilities whether they make sense for you or not, follow a high ceremony waterfall process, or make the purpose of the organization about project management.

Getting Mature

Maturity is an interesting concept. It has a lot of meanings. Mature can be a show you wouldn’t like your kids to watch, a bill of exchange that is due, or a ripe or fully aged piece of fruit. The definition of maturity I am using here is fully developed. What makes organizational project management maturity an interesting concept in business is that fully developed is different in almost every business. It can also change over time within an organization as the needs for project management change.  The key to organizational project management maturity is not to try to implement every capability with a robust set of process maturity. But to implement the capabilities that are right for helping a specific organization implement their specific strategy. This includes implementing an appropriate level of continuous improvement and only the necessary organizational enablers.

I have written about this focused approach to improving project management performance here and here. Invest when it improves the organizations ability to drive value. The goal is not to get better at project management, it is to get better at profitably delivering value to your customers. Project Management maturity efforts should be tied directly to business results.

 OPM3 Certified Consultant

An OPM3 Certified Consultant isn’t just someone who understands the OPM3 standard. Just to get into the course OPM3 Certified Consultant course you must demonstrate comprehensive knowledge of the OPM3 standard through completion of a SAM assessment or an OPM3 fundamentals course. An OPM3 Certified Consultant has demonstrated significant program or project management experience, since a PMP or PgMP is an eligibility requirement. An OPM3 Certified Consultant also has significant assessing and/or consulting experience.

Once in the course, the consultant is trained on the OPM3 assessment methodology and tool set, and the improvement methodology and tool set. This is during an intense four day training course. The consultant must successfully complete an exam.  The handbook that walks you through this process can be found at the PMI website.

The Value of OPM3 Certified Consultants

Most businesses can benefit from getting better at executing their strategy. Improving Organizational Project Management Maturity is a method of improving the organization ability to execute their strategy. OPM3 provides a systematic approach to identify and implement Organizational Project Management improvements appropriate to each business. Project Management Maturity is a tricky thing – it requires insight and experience to focus improvements in project management so it improves the organizations ability to deliver value to its customers. An OPM3 Certified Consultant has an assessment and improvement methodology, a robust tool set, and has demonstrated the experience with identifying and implementing improvements based on PMI’s standards.

For me, the value of the certification includes the assessment and improvement methodology training I received, the time I have spent with other experienced Organization Project leaders, access to the assessment and improvement tools provided by PMI, and some branding. I can combine this with my experience in software development and IT Operations excellence and cost optimization to rapidly deliver value to organizations. For organizations looking for a way to rapidly improve the performance of thier projects, an OPM3 certified consultant with proven experience and expertise in your domain is a good option. Guided by a proven systematic approach, they can perform an assessment and create an improvement roadmap and tie the improvements to your business results. 

There is a lot of interesting conversation going on within the project management, product management, and agile software development communities. There is contention between (and within) the different communities regarding the value and benefit from the other domains. Sometimes one community is vying to prove their domain is superior to the others. Other times, a community is casting blame for limitations in their ability to perform to another domain. Much of the conversation is based on a limited understanding of what the other domains actually do. They also fall into the trap of generalizing a specific unpleasant experience to encompass the intent of the other community.

I believe this debate is counterproductive. At the end of the day, everyone’s interest should be to improve their organization’s ability to profitably create value for the customer. Each of these areas has something critical to contribute to this goal – but the benefits are only realized when the communities work together. I want to define a few terms, identify the overlap, and then suggest why this discussion is not just an academic exercise, but it an important part of the maturing of each domain.

First, some definitions:

Project Management

Let’s start with Project Management. The Project Management Institute has the following definitions of project, project management and project manager.

Project: A temporary endeavor undertaken to create a uique product, service or result.

Project Management: The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.

Project Manager: Person assigned by the performing organization to achieve the project objectives.

Project Management is not meant to be an obstacle to getting work done. In fact, the project manager is responsible for ensuring the project is successful.

Product Management

The Product Development and Management Association define product, product management and product manager.

Product: A term used to describe all goods, services, and knowledge sold. Products are bundles of attributes (features, functions, benefits, and uses) and can be either tangible, as in the case of physical goods, or intangible, as in the case of those associated with service benefits, or can be a combination of the two.

Product Management: Ensuring over time that a product or service profitably meets the needs of customers by continually monitoring and modifying the elements of the marketing mix, including: the product and its features, the communications strategy, distribution channels and price.

Product Manager: The person assigned responsibility for overseeing all of the various activities that concern a particular product.

So the Product has an ongoing aspect to it that the Project doesn’t. The Product Manager decides what needs to be built and also how the organization will sell it and support it.

A product has a life that lasts beyond any individual project.  The ongoing thing over at PMI is called a Program. Here is the PMI definition for Program and Program Management. Interestingly, PMI doesn’t define Program Manager in the Program Management standard.

Program: A group of related projects managed in a coordinated way to obtain benefits and control not available from managing them individually, Programs may include elements of related work outside of the scope of the discrete projects in the program.

Program Management: The centralized coordinated management of a program to achieve the program’s strategic objectives.

Project Management Isn’t Product Management

So project management isn’t product management. Neither is Program Management, However, there are projects to execute in the modifying of the product, so project management processes matter in product management.  Here is a Venn diagram that describes the relationship.

If you aren’t good at making changes to your product or the capabilities in your organization that relate to your product, you won’t be a successful company. So project management isn’t product management, but there is overlap in practices and both are important to your organization. Great ideas with no execution aren’t valuable.

Agile Software Development

Finally, let’s go with the Agile Manifesto as a definition of Agile.

Manifest for Agile Software Development

• Individual and Interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Despite the perspective of many in the project management and product management communities, Agile is also not intended to be no planning, no documentation, irresponsible software development. According to http://agilemanifesto.org/history.html :

 “The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”

Agile is not Product Management

Agile is specifically about software development. In fact, the Agile Manifesto is short for the proper title of Manifesto for Agile Software Development. Agile is an approach to software development that includes practices and principles that can result in dramatically faster and higher quality (therefore less expensive) development of software. But the product is not just software. If the right features, communications strategy, distribution channels and price are established being faster, cheaper, and better at software development doesn’t matter. Product Management is critical to getting value from Agile Software Development.

Agile is not Project Management

 In very few cases is the product that is being sold to an organization’s customers just software. We’ve discussed the relationship of Project and Product Management above.  You need to be good at Project Managing all aspects of change to the product and the capabilities in the organization that support and are affected in any way by the sale, delivery, billing, and support of the product to the customer. Also, Agile isn’t concerned with Procurement – but procurement is important to the profitability of the company. And while iterations are a Risk Mitigation tool, Agile does not have a specific Risk Mitigation aspect to it.

Why this discussion matters

The following Venn diagram depicts the interdependency between these three domains.  Value is not delivered by any one of these domains. It is through an effective coordination between these domains that value is delivered to the customer. Value is identified, shaped, and then communicated to the customer by Product Management. Much value is created by the Agile development team itself. Value is created through aligning the other capabilities within the organization and often actually delivering the product to the customer through Project Management.

Let me quote Jim Highsmith from http://agilemanifesto.org/history.html again.

“In order to succeed in the new economy, to move aggressively into the era of e-business, e-commerce, and the web, companies have to rid themselves of their Dilbert manifestations of make-work and arcane policies. “

Most of the organization’s that I have been involved with that are failing to deliver software to the business or the business’ customers are failing to receive value because of deficiencies in one or all of the domains in this discussion. Often, the deficiencies are the result of conflict and lack of coordination with another domain. Becoming great at one area, while remaining poor in another, is not value to the customer, the business, or ultimately to the members of the organization. 

The discussion we need to be having is not about how each domain contributes to problems for the other domain.  This is an interdependent problem, not one that has its roots in any one domain. Bunkering down, defending incompatible practices, focusing on local optimization at the expense of the business is not going to work. We need to work together to answer this question. How do we align the product management and project management practices with the rapid, incremental delivery of working software to optimize benefits for our customers and profitability for our businesses?

I come from a big project, high ceromony background. I learned Software Engineering as contractor at IBM in the 80’s, was a Marine, and believe in the PMBoK (Deputy PM on OPM3® Second Edition). Over the last 10 years I have studied and learned Agile from books and through mentoring relationships. I have applied what I understood and have experienced improved performance. But I still thought of Agile/Scrum as a less than responsible way to do work.  I have heard a lot of push back on Agile and Scrum in blogs and on Twitter lately. “Scrum doesn’t work”, they are saying. “Scrum makes the devleopers life easier but hurts the customer”, is another one. “The lack of overall budget/timeline is a killer (only look 1 sprint forward, really)”, is a charge hurled this week. 

Last week, I went to the source and completed Jeff Sutherland’s Certified Scrum Master course. During the training with Jeff Sutherland last week, he presented a ScrumBut test. We are doing Scrum but… means you aren’t doing Scrum. Not doing Scrum means you likely won’t get the benefits other teams that are doing Scrum have claimed. Scrum, when done well, is a responsible way to develop software and if positioned maturly is a benefit to management. With permission from Jeff, here is the ScrumBut test. Take the test, add up your scores and divide the result by 9. 

Question 1 – Iterations

- No Iterations – 0
- Iterations > 6 weeks – 1
- Variable Length < 6 weeks – 2
- Fixed iteration length 6 weeks – 3
- Fixed iteration length 5 weeks – 4
- Fixed iteration length 4 weeks or less – 10

Question 2 – Testing within the Sprint

- No dedicated QA – 0
- Unit tested – 1
- Feature tested – 5
- Feature tested as soon as completed – 7 
- Software passes acceptance testing – 8
- Software is deployed – 10

Question 3 – Agile Specification

-No requirements – 0
- Big requirements documents – 1
- Poor user stories – 4
- Good requirements – 5
- Good user stories – 7
- Just enough, just in time specifications – 8
- Good user stories tied to specification as needed – 10

Question 4 – Product Owner

- No Product Owner – 0
- Product Owner who doesn’t understand Scrum – 1
- Product Owner who disrupts team – 2
- Product Owner not involved in team – 2
- Product Owner with clear product backlog estimated by team before Sprint Planning meeting (READY) – 5
- Product Owner with a release roadmap with data based on team velocity – 8
- Product Owner who motivates the team – 10

Question 5 – Product Backlog

- No Product Backlog – 0
- Multiple Product Backlogs – 1
- Single Product Backlog – 3
- Product Backlog clearly specified and prioritized by ROI (business value) before Sprint Planning (READY) – 5
- Product Owner has release plan based on Produce Backlog – 7
- Product Owner can measure ROI (business value) based on real revenue, cost per story point, or other metrics – 10

Question 6 – Estimates

- Product Backlog not estimated – 0
- Estimates not produced by team – 1
- Estimates not produced by planning poker – 5
- Estimates produced by planning poker by team – 8
- Estimate error < 10% – 10

Question 7 – Burndown Chart

- No burndown chart – 0
- Burndown chart no updated by team – 1
- Burndown chart in hours/days not accounting for work in progress (partial tasks burn down) – 2
- Burndown chart only burns down when task is done (TrackDone pattern) – 4
- Burndown only burns down when story is done – 5
- Add 3 points of team knows velocity
- Add two points if Product Owner release plan based on known velocity

 Question 8 – Team Disruption

- Manager or Project Leader disrupts team – 0
- Product Owner disrupts team – 1
- Managers, Project Leaders or Team Leaders telling people what to do – 3
- Have Project Leader and Scrum roles – 5
- No one disrupting team, only Scrum roles – 10

Question 9 – Team

- Tasks assigned to individual during Sprint Planning – 0
- Team members do not have any overlap in their area of expertise – 0
- No emergent leadership – one or more team members designated as a directive authority – 1
- Team does not have the necessary competency – 2
- Team commits collectively to Sprint goal and backlog – 7
- Team members collectively fight impediments during the sprint – 9
- Team is in hyperproductive state – 10 

My best recent project scored a 6.7 on this test and we didn’t call it Scrum – we just considered it responsible management of an analytics projecyt. We did perform really well in a tough situation though. If you score less than a 6 on average, you probably aren’t doing Scrum. That may be good or bad – but if you aren’t doing Scrum, don’t call it Scrum. If you aren’t performing at a hyperproductive level, look at the areas where you didn’t score as well. It is likely they will highlight the next most important impediment for you to focus on removing. Fix that and move forward.

This is a slightly updated presentation of a talk I gave at Atlanta’s Project Developer Days a few years ago. After attending a two day training session with Jeff Sutherland, I believe that this concept is relevant to the Agile and SCRUM Project Management conversation.  From my experience, improving the performance of the conversations on your projects greatly improves the performance of the project team. When we say we want to get better at communications, I believe we want to improve the quality and effectiveness of the project conversations. The project managers job in leading projects requires us to be good at recognizing what conversations need to take place, and facilitating them to a successful conclusion.

If you aren’t familiar with the story of The Blind Men and The Elephant it is about six blind men that go to study an elephant. When they come back, they all report on the elephant in different ways. They variously report they found a wall, a spear, a snake, a tree, a fan, and a length of rope. They argue to defend their perspective. The discrepancy lies in the fact that each studied a different part of the elephant. The poem and the related illustrations at the link above demonstrate the story very well. The story is a metaphor about how we see the world from our individual perspective and have a difficult time understanding the bigger picture.

Delivering software and technology is a lot like that elephant. Over my career, I have been the blind man trying to figure that elephant out. I wrote code for the first decade, then began to study what great code and then architecture looked like. I joined user groups and associations and studied the engineering practices around software development. I studied function point counting and became a member of IFPUG. In the mid 1990’s Senge and Ackoff seeded my Systems Thinking perspective. My work at Perot Systems shaped my Business Process Re-engineering perspective. My degree is in Organizational Psychology and Development and I have been fascinated with the role language, knowledge creation, and team dynamics play in this area. I first read “The Goal” and “Critical Chain” in 1998 and have studied and applied the TOC thinking processes and CCPM to project scheduling. I have been greatly influenced by Theory of Constraints thinking. I have been around Agile development for over 10 years. I have a bookshelf full of eXtreme Programming and Agile books. I am also very involved with the project management institute as well, earning my PMP in 1998 and I spent the last couple years as the Deputy Project Manager of the Organizational Project Management Maturity Model - OPM3®.   I earned my Lean Value Stream Mapping certification from the Lean Enterprise Institute in 1999.

In each of these cases I went into the community trying to learn what they had to offer and figuring out how to responsibly help companies profitably deliver technology. One of the interesting things I have consistently observed is the disdain these communities hold for most of the other communities.  I was at an Architecture conference in 1991 where the various OOAD people were actually yelling about the best way to identify objects for a system. The TOC and Agile people really dislike the PMI people. Even inside the Agile community, the Lean and Agile groups are at each other’s throats. Engineers discount the human elements and the softer side of team dynamics.  Everyone is arguing for the importance of their view of the elephant. High ceromony scoff at the lack of maturity of the low ceromony while the low ceromony ridicule the waste of heavy and useless process and artifacts.

The problem is that the answer is not one particular part of the elephant. No one is completely right. We need to optimize the entire elephant and turn it into a sleek and agile race-horse. The battles between whether the elephant is a tree or a fan or a snake are not productive. They obscure the path to improving the ways that we can responsibly and profitably deliver value to our customers.

I spent last week at a course with Jeff Sutherland, one of the creators of SCRUM. The SCRUM he talks about is different than what I have seen on many SCRUM teams or read in books. Jeff incorporates aspects from Theory of Constraints, and Lean, and Knowledge Management. He promotes the items in the Agile Manifesto but incorporates elements from everything he has learned and observed. Jeff is trying to build a “big-tent” approach that brings responsible practices together while increasing performance and developing hyper-productive teams.

I encourage each of us to recognize our myopia in understanding this elephant. Try to understand the basic principles behind each practice and idea. Let’s agree that the way organization’s identify, manage, create, and deliver technology to organizations and customers is insufficient and put a lot more energy into improving. Technology plays a very important role in our economy today. We can’t get good enough fast enough right now, and dogmatic wars are too costly. What can we be doing to rapidly cross-pollinate and greatly improve our ability to profitably deliver value to our customers?

How much project management investment should be made in a down economy? In many organizations there is cost cutting taking place that is neccessary for the survival of the organization. Should you cut project management investment or should you increase project management investment? Is it reasonable to perform an across the board cut of project management capabilities?

I have been reviewing several books on the business value of Project Management, including Quanitifying the Value of Project Management by Ibbs and Reginato and Researching the Value of Project Management by Thomas, PhD and Mullaly, PMP.  The goal has been to create a framework for businesses to use to see how much they should be spending on project management. I have a simple framework a company could use to build a business case for investing in project management and am ready for some feedback.

Each company has projects or programs where they need to invest to achieve the organizations business strategy. At a high level both the cost of the projects and the expected benefit (increased revenue, reduced costs, improved customer retention, reduction of risk, etc.) can be quantified into an expected return for the organization.  The net of these numbers is the expected return on the project portfolio investment.

Risks arise from poor or missing Project Management practices in organizations. These are risks to the project schedule, risks to project scope and quality, and risks to project cost and risks to the success the project itself. For example, a delay in the project can result in greater than anticipated costs and missed business opportunity (lower business benefit).  Lower quality or missing scope can result in lower business benefit realization. A project failure results in cost equal to the expense of the entire project and all the lost business benefit. Based on the amount of Project Management that will be applied to each project these risks can be quantified at a high level by estimating the likelihood of an occurance and the impact (cost) of its occurance.

Improved Project Management can deliver additional benefits – improved financial results, better governance, better predictability, and improved organizational coordination. These benefits can be quantified by estimating the likelihood of their occurance if you have improved project management practices and assigning a financial benefit. Identify the specific capability improvements that need to exist to achieve specific benefits and then quantify the benefit.

You can determine the benefit of project management by combining the amount by which risk is reduced plus the additional benefit of improved project management. This is the gross benefit of project management. This benefit will be different for every business and for every project.

Project Management comes with a cost. These costs include the cost to perform project management and the cost of improving your project management capabilities. Identify the specific capabilities that need to exist or be improved and estimate a cost of delivering those capabilities. How much is the project manager going to cost? How much is it going to cost to improve specific processes to achieve the benefits and reduce the costs? This number shows the cost of project management.

Deduct this cost from the gross benefit of project management and you have a net benefit of project management.

Every project is different and every company is different. It makes sense to invest in project management in the capabilities and amount where project benefit realization is improved more than the cost of the project management. If project management isn’t increasing the value of your projects, it should be reduced. Almost no-one needs every project management capability to be robustly deployed. But almost all projects benefit from some level of project management. The following graph shows this relationship between investment into PM and the benefit ot PM.

Remember, each project is undertaken to deliver some benefit to the organization. Project Management can help reduce the risk of failing to achieve this benefit and actually improve the potential benefit. But project management always comes at a cost. When the Project value + (benefit of project management – cost of providing project management) is greater than the Project value – the cost of poor project management, you should invest in PM.  This business case approach to determing how much PM should exist should be undertaken as part of your budgeting process for each project. The goal of project management is to improve the organizations ability to deliver value to its stakeholders. To the point that Project Management is doing that, it is a good investment.

I would like you thoughts on this approach and how practical it would be to calculate this equation at your organization or on your projects.

I was reading a post by http://pauldrasmussen.blogspot.com/2009/02/project-management-so-what-is-project.html. While I don’t agree with everything in the post, I like the point made that project management is an art and a science.  There is art in being effective when you have a temporary role and you are responsible for the leadership of change within an organization

My Dad is a physicist. Back in the mid 1960’s he worked at NASA as a contractor. They hired physicists to do engineering work because there weren’t clearly understood engineering principles around building rocket ships to go to outer space. They were figuring these out as they went. So Rocket Science at the time was part science and part art. I think we are pretty good at engineering rocket ships now. In fact, you can get a degree in engineering that teaches the principles they were proving in the 1960’s.

Project Management is where rocket science was back in the 1960’s. Theoretically we can get complex organizational projects done. Some people have even done them well.  But many of them have not been successful and the practices are not fully proven. Project Management is a science and an art.  It took 20-30 years for rocket science to move from theory to science to engineering.  Where are we on the spectrum in project management for organizations today?

I have decided that my five keys to reducing project failure are in the wrong order. The first point has to be Focus on the right projects. In Organizational Project Management, this is accomplished through Project Portfolio Management. Today, there are limited dollars to spend on improving the business. How do we decide which project’s are the next best place to spend a dollar?

Within a business, there are many things that can be improved. In fact, most managers are interested in improving the processes within their area of responsibility. However, not every improvement, even when it will return a local benefit, is worth doing. For example, you can probably get better at the cleaning the office at your location. Maybe fancier vacuum cleaners or trash compactors at every desk would improve the quality and performance of this capability. However, in this case, we can clearly identify what is good enough and therefore don’t invest in improving this capability. Within a business we need to determine which projects to even consider – then we can do a portfolio analysis to pick the ones we are going to pursue.

 Strategic Opportunity.

Too often, projects are handed out based on some project ROI (which may only exist within the business) or based on political ability. It is important to understand how the business creates value for its customers, and where the constraints in the organization exist. If it doesn’t meet one of the following criteria, then it probably isn’t a project you need to pursue on a strategic basis.

·         Does it remove a constraint on a key value stream in the organizations ability to deliver value to the customer?

·         Does it add value to the customer that increases profit for the company in a way that is aligned with the company strategy?

·         Does it close a key performance gap in the organizations ability to achieve its standard operating objectives?

·         Does it reduce costs in the near term more than the cost of the project?

Once the project has met one of these criteria, it is important to identify exactly what capabilities in the business must be affected to complete the project. Then the project needs to be scoped distinctly to include specifically which capabilities will change, and in what way, and how they meet a strategic objective. Now, an order of magnitude estimate of cost and benefit can be determined and this project can be included in a portfolio analysis.

Business Risk Mitigation.

Some projects are necessary but don’t advance the organization’s strategy. Y2K projects and Sarbanes-Oxley are examples of these types of projects. These are typically about avoiding a risk.

·         Does it address a threat to the existence of the company?

·         Does it enable the business to respond to changes in the business environment?

·         Executive mandate.

For these projects, you again need to understand an order of magnitude impact and likelihood of occurrence of the risk being mitigated. You need to define exactly what capabilities in the business will change, and in what way. Now you can determine an order of magnitude value and cost and include this project a portfolio analysis.

Once all the projects are in the portfolio, they can be evaluated against some additional criteria such as ability to execute and business impact to identify those that should be pursued first. In future posts, I will go into more detail about how to answer each of the questions above.

The critical concepts are to select projects based on clearly articulated strategic opportunities or business risk mitigation. The strategic alignment piece is really important, because if strategic objectives change, we need to know which projects to consider stopping. The same is true for the business risk mitigation. If the likelihood of a risk increases, the business impact of the project changes. Improving something just because you can improve it is a bad investment. Have a cohesive approach to selecting projects to make sure resources are being invested in the best interest of the company.

Going to be in Philadelphia on the 15th-17th of this month with the Project Management Institute to review all the standards just released and how they fit into PMI’s strategy. I am very excited about these new standards, particularly OPM3® and the approach to the organizational market. I’ll update you next week.