Let’s look at some additional data to help shed light on this issue. In another recent study, The Study of Product Team Performance, 2012,  Actuation Consulting and Enterprise Agility found that:
- Only 33% of product teams have daily priorities that are “strongly aligned” with the organization’s business strategies
- Only 12% of respondents report on-time, on-scope, on-budget performance
- Only 28% of respondents report “hit or miss” or “miss more than we hit” performance
This study also discovered that critical gaps exist in many organizations. These organizations lacked elements such as a multi-year product strategy and product portfolio management.
From these findings, one could infer that most product development teams are working on projects that are not strongly aligned with their organizational strategy and have a strong likelihood to miss expectations. Can part of the reason be that teams are working hard to deliver projects but do not truly understand the nature of those expectations?
So often, after being assigned to a project, project managers try to run before they walk. This is especially common when the project is already in progress. You can quickly get caught up in the momentum of work and forget to question whether the work is justified. If this is truly the case, shouldn’t more projects be stopped? Aren’t project managers in the best position to go against this grain and make the recommendation to stop a project even when it’s not the most popular decision? Maybe the question should be: Would a project manager be afraid to stop a bad project even if it was the “right” thing to do but it meant losing his/her job?
What About the Project Management Code of Ethics?
It's well documented that otherwise ethical individuals can be enticed to “bend the rules” because of poorly structured incentives. We’ve all probably seen some form of this behavior playing out in our organizations and product development projects. Whether it’s the business unit head who pushes an inadequately prepared team to reach a project go-live date in the interest of receiving a very large bonus, or a product manager trying to meet a roadmap item date but only delivering 50% of the customer's requirements because incentives were linked to the delivery date and not the scope. Most of the time, this behavior is not meant to be malicious, but let’s face it, poorly aligned priorities linked to financial rewards can encourage individualist behavior in even the most ethical person. I honestly don't think project managers are any more or less susceptible than any other profession to this type of behavior.
However, as a credentialed project manager, our behavioral conduct is governed by our Code of Ethics and Professional Conduct. Our code should provide us the clarity and direction we need when situations get confusing or conflicted — and projects need to be stopped. Let’s look deeper into our project management code for guidance.
Chapter four, Fairness, specifically states the following: “Fairness is our duty to make decisions and act impartially and objectively. Our conduct must be free from competing self interest, prejudice, and favoritism.
4.2.2 We constantly reexamine our impartiality and objectivity, taking corrective action as appropriate.
Comment: Research with practitioners indicated that the subject of conflicts of interest is one of the most challenging faced by our profession. One of the biggest problems practitioners report is not recognizing when we have conflicted loyalties and recognizing when we’re inadvertently placing ourselves or others in a conflict-of-interest situation. We as practitioners must proactively search for potential conflicts and help each other by highlighting each other’s potential conflicts of interest and insisting that they be resolved.
And Chapter five, Honesty, states that:
“5.2.3 We provide accurate information in a timely manner.
Comment: An implication of these provisions is that we take appropriate steps to ensure that the information we’re basing our decisions upon or providing to others is accurate, reliable, and timely. This includes having the courage to share bad news even when it may be poorly received. Also, when outcomes are negative, we avoid burying information or shifting blame to others. When outcomes are positive, we avoid taking credit for the achievements of others. These provisions reinforce our commitment to be both honest and responsible.
One could argue that our code doesn’t explicitly say “stop a project when it is bad” or that in certain cases the code is too aspirational — a topic for another day. But clearly it’s in our code of ethics that we, as project managers, need to make these tough recommendations to our stakeholders. So, why aren’t more projects being stopped?
What criteria do project managers use to determine if the project is off the rails with no sign of recovery? What happens if the project delivery is sound but the overall product strategy is flawed? Is it the job of the project manager to stop the organization from making this investment mistake even if he or she can deliver the project on time, scope, and budget?
If the reason that the project is “bad” can be attributed to tangible areas where the project will not meet stakeholder requirements (e.g., cost, time, scope), then it is the responsibility of the project manager to alert the sponsors so that the scope/requirements can be changed or the project cancelled. This, in fact, is one of the reasons you’re hired into the role of project manager.
However, in the case of a sub-optimal product strategy, some may interpret our loyalty mentioned in our code of ethics as loyalty to the project and the project charter, not necessarily to the common good of the organization. Some might argue that a great strategy executed poorly will almost certainly lead to failure; whereas a poor strategy, executed properly will likely have some measure of success. Once a project has been commissioned, the project manager’s focus is to execute according to the project charter. Presumably the sponsors (organizational management) are aware of strategic alternatives and, for better or worse, have chosen the project you’re working on. The current mantra is to accept this charter and execute it to the best of your ability.
As a project manager, you should be brutally honest when the viability of a project is in question, even if the concerns are regarding the product strategy. The reasons for this are important. For example, if the project no longer aligns with the strategic objectives of the organization, continuation will lead to wasted financial and human resources thereby undermining the organization’s credibility in the market. In this case, look for alternatives that could leverage the investment already made and provide value through a different, better-aligned project initiative.
So How Do You Define Success?
When creating, developing, and delivering a product to the market, we seek to maximize its value. In product development projects, the project manager typically collaborates with the product manager to construct detailed statements (success criteria) that are clear and measurable, focused around the areas of scope, schedule, and cost. Then, during the course of the project, the project manager forces the product manager to make decisions and tradeoffs against the three, but based on what? Does the product manager really understand what they’re being asked to trade-off against? The answer should be value.
Project Managers need to adjust their perspective around scope, schedule, and cost and relate it back to what the overall value is of the project. When you make this adjustment you realize that the balance of scope, schedule, and cost is more of an equation based on deriving value. I call this the project management value equation. It’s designed to give context to “scope, schedule, and cost,” ensuring that you’re weighing all that you do against the overall value of the project and keeping your product manager and product team focused on the prize. Said another way, it’s an equation meant to quantify and assess the value of a project and identify — if value has been decreased — whether the project should be stopped. The equation is (working model identified in book):
Value = Scope ÷ (Schedule + Cost)
By understanding this concept, you bring more depth and meaning to what you really need your product manager to trade off against. By assigning a value to each of your success criterion, you in essence are quantifying the value of the project. Remember, good project managers know that project success is not whether it’s delivered on time and within budget, but whether it delivers value and meets the defined success criteria.
Our project success criteria should then be evaluated using our code of ethics. Ask yourself, “are the intentions of the project feasible and ethical?” “Am I willing to act in an ethical way, to complete the project — even if completion means stopping it?” It’s likely that the project sponsor views this recommendation as a personal attack and the result turns out to be a career-ending move. In a tough economy, stopping a project becomes an extremely difficult decision. However, I still hold the position that, based on our code of ethics, the answer to the question…should a project manager stop a project even if it means losing their job…should be YES! When managing a product development project, our Code of Ethics is the backbone to our credibility — and sacrificing our credibility should never be an option.
Don't forget to leave your comments below.
 Accept Corporation and Association of International Product Marketing and Management (AIPMM). PPM is Dead. Long Live Portfolio: Q2-2011 Study - Portfolio Management Priorities. June, 2011. Retrieved from accept360.com.
About the Author:
Steven Starke is the author of S.T.O.P. – The Project Management Survival Plan. He is currently the VP of Program Management for Thomson Reuters and working with Actuation Consulting on training material focused on product team collaboration. Steve has held leadership positions in Program Management, Product Management, Systems Engineering, Product R&D, and Global IT and has run full-fledged PMOs. His industry experience ranges from consumer products and medical devices to global IT Infrastructure, healthcare analytics, and software development.