Please login or join to subscribe to this thread
If I understand your question, I'd suggest this is where you would want to provide a ranged estimate for desired outcomes which is aggressive but still allows for unexpected changes and issues.
It is the difference between committing to a single point estimate where the slightest change could spell disaster or a reasonable three point estimate which still means the project outcomes are valuable but is more resilient to shocks.
George, I am unsure if I understand what you mean by 'full project potential', some things went thru my thoughts when I read your post:
1. we are living in times when project efficiency looses weight against effectiveness, represented by product focus, value creation, and finding out WHAT we need on the fly. HOW we do it, the project structure, becomes more flexible and uncertain. Panta Rhei.
2. So the project potential is less important now, defined by trying to be most efficient. We need inefficiency to allow for curiosity and innovation, to save thinking energy, ratio, in creating new things. This BTW was always the case, it just gets more recognized and valid - Tom DeMarco's book Slack from 2002 talks about it in depth.
3. Seeing this pendulum between the WHAT and the HOW, something is missing: the WHY, the purpose or our identity. I think, with AI coming strongly, we will resort to focus on the WHY in the next 10 years. Already companies move away from sole profit orientation, young generations feel the relevance of the why.
"Potential" is a tricky word. It suggests that something that may be developed or improved beyond the project's original baseline or expectations. That is not the purpose of project management; to make things even better than what was expected. It is to meet expectations. Exceeding expectations to the fullest potential might be the domain of business development, sales, marketing, R&D etc.
“Full Project Potential” being the explicit statement of how success is to be measured end-state. For instance, you could have the following goal stated in the charter, “product will be 100% adopted by all 9,245 users.” A lofty goal, especially with the term “adopted” being the bullseye, either way, it’s a statement of how success will be measured.
I’m using the word “potential” in recognition that projects rarely meet their lofty goals, and as such, success gets redefined to meet the realities on the ground or the realities that are recognized through project progression.
So, Kiron’s statement, “It is the difference between committing to a single point estimate where the slightest change could spell disaster or a reasonable three-point estimate which still means the project outcomes are valuable but is more resilient to shocks,” is closely aligned to what I’m referring to.
The “Full Project Potential” may be the lofty unrealizable views of your Sponsor / Stakeholders. You as the PM have a role in managing expectations, what does that look like? Do you accept that which you consider unrealizable and walk the tightrope, or do you ….
George - generally, it seemingly is our responsibility to help others determine the most practical path forward in realizing the overall goals of the project. There could also be opportunity to establish milestone goals to present a growth paradigm. For example, if the overall intent is to gain 62% market share (or 15% growth) by 2025; why not establish a goal ramp by establishing milestone targets - 5% by 2022, 10% by 2024, etc.
I have taken on projects that in retrospect, were basd on unacheivable goals. I was new at the organization and too heavily relied on those around me to have provided a vision and plan (the project had been scoped and budgeted prior to my take over) that was sensible and achievable. If I could have done it all over, I would have pushed back harder.
Is your performance tied to the realized benefits? More often than not, the answer is no. That's because it usually takes time to realize then measure the benefits. As I head into the third year of my project, I am working with the organization to set them up to do just that.
If I undertood well there is a big mistake I have debated with the PMI when I was part of the groups of authors and reviewers of the standards and some things were changed in the last versions of them (obviouly, no because I said that, it is because other people said the same). PMI is still mixing the product and the project and both are quit different things where different roles are accountable for. Business Analyst is accountable for the product while project manager is accountable for the project. From product the project must be defined, including it the project success criteria. Stated "product will be 100% adopted by all 9,245 users" as a project success criteria is totally wrong, it will not be achieved by the project. What the project will assure thanks scope/time/schedule but mainly quality is that alll needed to support that objective will be considered inside the project scope. "product will be 100% adopted by all 9,245 users" is a matter of a non-funcional requirement of the product. Business Analyst is accountable for that. What the project manager will assure is to define all the needed activities as part of the project scope and in the field of project quality to achieve that. If a project manager do not understand that then she/he is DoA (dead on arrive) regarding people to consider the project is successful.
I’ve had a couple of projects where MBO (Management by Obfuscation, I mean Objectives) bonuses were used to keep the project manager and lead’s balanced on the tightrope. Did it work, you better believe it did. With the agreement being 20% or nothing, we all took tightrope and juggling courses before the project began.
Unfortunately, those perks/incentives for most enterprises were sunk to the abyss (along with our pensions) during the 2007-2009 great recession. And although ROV’s (Remotely Operated Vehicles) have recently recovered these valuable artifacts, the pressure at depth reduced their size to meaningless proportions
As a general rule, enterprises want “one throat to choke,” as multiple accountability structures are hard to manage as they create their own ecosystem of political mayhem.
You can have the functional delineation within the project for “Product versus Project,” but the “accountable PM” is still the throat which will be choaked. If I were to report to a steering committee that “x, y, and z” is not in my domain of control, I would see “three X’s” flash on the screen and would find myself sliding down the trapdoor that exists in every executive’s conference room.
I do understand what you are saying, but it doesn’t fit in all organizations.
I believe that the degree of project performance is determined at the beginning rather than on delivery. Ill defined vision, objectives and measurement is sure to result in perceived or real project failure.
The Project Charter should define "Full Project Potential" as well as "acceptable" project performance and "failed" project performance. Otherwise each stakeholder will have a different concept of what is full, acceptable and failed and that concept will be different on delivery than what it was at inception.
This of course is dependent on the project. If you are sending people to Mars technical delivery is without compromise however cost and time may be flexible.
Please login or join to reply