Many organizations have experienced project managers, established governance processes, and sophisticated delivery tools. Yet projects still enter execution with unclear outcomes, conflicting stakeholder expectations, undefined ownership, and no agreed measure of success.
Once the request has been labeled a “project,” the project manager is often expected to resolve these gaps while also creating the plan, managing delivery, and meeting the original timeline.
Before a request enters delivery, I believe teams should be able to answer several fundamental questions:
What problem or opportunity are we addressing?
What measurable outcome are we expecting?
Who owns the business decision?
Have the affected stakeholders aligned on the need?
What evidence supports the request’s value and urgency?
Do we understand the capacity, risk, and governance implications?
What would indicate that the request is not yet ready?
In your organization, who determines whether a request is sufficiently defined to become a project—the sponsor, PMO, portfolio leadership, business analyst, or project manager?
Which readiness condition is most frequently missing when work reaches your delivery teams?
Disclosure: I created Lean Intake Analysis™, a methodology focused on clarifying and evaluating work before execution, and I am developing LIA Compass™ to support that workflow. I am interested in learning how other practitioners manage this decision point within their organizations.
In my experience, the missing piece is usually a clear owner and a measurable outcome; work gets labeled a "project" before anyone agrees on what success looks like. A simple PMO or sponsor sign-off against those two points before intake would stop most of the confusion later.
...
2 replies by Azana Wiley and Lia Smith
Jul 25, 2026 12:23 PM
Lia Smith
...
Syed, I agree. Ownership and measurable outcomes are often treated as details to be resolved during planning, even though they are foundational to deciding whether the work should proceed at all. A sponsor or PMO sign-off could help, provided it represents an informed decision rather than a procedural approval. The decision owner should be able to explain the expected outcome, how success will be measured, and who has authority to make trade-off decisions once the work begins. Without those conditions, the project manager may be accountable for delivery but lack the business authority needed to resolve the underlying ambiguity. Thank you for highlighting two of the most consequential readiness conditions.
Jul 30, 2026 1:06 PM
Azana Wiley
...
This is so true! We've also run into situations where something has been identified as a project before a funding source was identified.
Saving Changes...
Luis BrancoCEO| Business Insight, Consultores de Gestão, LdªCarcavelos, Lisboa, Portugal
An important question. I would distinguish between being ready for discovery and being ready for delivery. A request does not need every uncertainty resolved before work begins, but it should have enough clarity to justify the next level of commitment, including the problem, intended outcome, decision owner, value hypothesis, key risks, and criteria for continuing or stopping. Readiness may therefore be less a single gate owned by one role and more a governed decision in which business ownership, portfolio capacity, analysis, and delivery feasibility are made explicit. The project manager should contribute to that decision, but should not inherit responsibility for unresolved business ambiguity after execution has already been authorized.
...
1 reply by Lia Smith
Jul 25, 2026 12:24 PM
Lia Smith
...
Luis, this is an excellent distinction. Readiness for discovery should not be confused with readiness for delivery. An organization may appropriately authorize discovery while acknowledging that the solution, scope, or feasibility remains uncertain.
What should be explicit is the level of commitment being made, the questions that discovery must answer, the decision owner, and the criteria for continuing, changing direction, or stopping.
I also agree that readiness should be a governed decision rather than a gate controlled by one role. Business ownership, strategic value, portfolio capacity, risk, analysis, and delivery feasibility all contribute different evidence. The project manager can inform the decision, but should not become the default owner of unresolved business ambiguity after delivery has already been authorized.
It's a really interesting topic. For a sufficiently agile, and largely digitally-run business I would suggest that the "projectization" of work matters very little today in comparison to even a decade ago. Change is a constant. Goals and measurable outcomes matter; governance and risk management matter; flexibility and collaboration matter; but dynamic modern orgs ought to be doing those things well all the time, not just when someone labels the work a "project".
Re PMOs. Management support of that kind is arguably just as valuable with or without invoking the P-word. I think it's getting harder to justify PMO offering a different accountability model in modern organizations however. The controlling/directing PMO is something I see less of today and presumably that's because orgs have greater confidence in their management's ability to handle change as an accepted part of every manager's role.
...
1 reply by Lia Smith
Jul 25, 2026 12:27 PM
Lia Smith
...
David, thank you. I agree that the underlying disciplines should apply to all organizational change, not only to work formally labeled as a project. The “project” label can sometimes distract from the more important questions of outcomes, accountability, risk, capacity, and decision-making.
I would argue, however, that a readiness decision still exists whenever an organization commits meaningful funding, capacity, or cross-functional effort—even when the work is managed as a product initiative, continuous change, or operational improvement.
The relevant question may therefore be less “Is this ready to become a project?” and more “Is this sufficiently understood to justify the next level of organizational commitment?” I n that model, the PMO does not necessarily control the work. It can provide decision transparency, portfolio-level visibility, and consistent evidence standards while accountability remains with business and product leadership.
In my experience, the missing piece is usually a clear owner and a measurable outcome; work gets labeled a "project" before anyone agrees on what success looks like. A simple PMO or sponsor sign-off against those two points before intake would stop most of the confusion later.
Syed, I agree. Ownership and measurable outcomes are often treated as details to be resolved during planning, even though they are foundational to deciding whether the work should proceed at all. A sponsor or PMO sign-off could help, provided it represents an informed decision rather than a procedural approval. The decision owner should be able to explain the expected outcome, how success will be measured, and who has authority to make trade-off decisions once the work begins. Without those conditions, the project manager may be accountable for delivery but lack the business authority needed to resolve the underlying ambiguity. Thank you for highlighting two of the most consequential readiness conditions. Saving Changes...
An important question. I would distinguish between being ready for discovery and being ready for delivery. A request does not need every uncertainty resolved before work begins, but it should have enough clarity to justify the next level of commitment, including the problem, intended outcome, decision owner, value hypothesis, key risks, and criteria for continuing or stopping. Readiness may therefore be less a single gate owned by one role and more a governed decision in which business ownership, portfolio capacity, analysis, and delivery feasibility are made explicit. The project manager should contribute to that decision, but should not inherit responsibility for unresolved business ambiguity after execution has already been authorized.
Luis, this is an excellent distinction. Readiness for discovery should not be confused with readiness for delivery. An organization may appropriately authorize discovery while acknowledging that the solution, scope, or feasibility remains uncertain.
What should be explicit is the level of commitment being made, the questions that discovery must answer, the decision owner, and the criteria for continuing, changing direction, or stopping.
I also agree that readiness should be a governed decision rather than a gate controlled by one role. Business ownership, strategic value, portfolio capacity, risk, analysis, and delivery feasibility all contribute different evidence. The project manager can inform the decision, but should not become the default owner of unresolved business ambiguity after delivery has already been authorized. Saving Changes...
It's a really interesting topic. For a sufficiently agile, and largely digitally-run business I would suggest that the "projectization" of work matters very little today in comparison to even a decade ago. Change is a constant. Goals and measurable outcomes matter; governance and risk management matter; flexibility and collaboration matter; but dynamic modern orgs ought to be doing those things well all the time, not just when someone labels the work a "project".
Re PMOs. Management support of that kind is arguably just as valuable with or without invoking the P-word. I think it's getting harder to justify PMO offering a different accountability model in modern organizations however. The controlling/directing PMO is something I see less of today and presumably that's because orgs have greater confidence in their management's ability to handle change as an accepted part of every manager's role.
David, thank you. I agree that the underlying disciplines should apply to all organizational change, not only to work formally labeled as a project. The “project” label can sometimes distract from the more important questions of outcomes, accountability, risk, capacity, and decision-making.
I would argue, however, that a readiness decision still exists whenever an organization commits meaningful funding, capacity, or cross-functional effort—even when the work is managed as a product initiative, continuous change, or operational improvement.
The relevant question may therefore be less “Is this ready to become a project?” and more “Is this sufficiently understood to justify the next level of organizational commitment?” I n that model, the PMO does not necessarily control the work. It can provide decision transparency, portfolio-level visibility, and consistent evidence standards while accountability remains with business and product leadership. Saving Changes...
In my experience, the most common gap is a lack of clear business outcomes and stakeholder alignment. Before calling something a project, I look for a defined problem, measurable success criteria, an accountable sponsor, and realistic capacity. A strong intake process saves far more time than trying to fix unclear objectives during delivery. Saving Changes...
Project Manager| AWR Development (BD) Ltd. Cox's Bazer , Bangladesh
Great questions, Lia. In my experience, "measurable outcome" is the readiness condition most often missing — teams agree on the problem but skip defining what success actually looks like, which causes scope debates later. On ownership, it usually falls to the PMO or sponsor to give final go-ahead, but the project manager is often the one who ends up surfacing these gaps in practice, even without formal authority to say "not ready yet." Saving Changes...
Robert SnyderFounder & President| Innovation Elegance, LLCChicago, Il, United States
Hi Lia. I recommend partitioning this topic into separate and finite decision “bundles.”
“Requests” belong in a Change Log. ·Teams should align on the Change Log approximately monthly. ·The Change Log stores decisions about approve, reject, defer, etc.
“Projects” belong on the Roadmap. ·Teams should align on the Roadmap approximately monthly. ·The Roadmap stores expectations about project names, their approximate start date, and expected completion date.
Requests might translate to projects the Roadmap 1-for-1, but often “no” on that.
·A single request might translate to multiple projects. ·Multiple requests might translate to a single project.
·The Change Log should hint at the problem or opportunity. ·The Project Charter should exhaustively explain the problem or opportunity.
A scorecard maintains metrics, although certainly the project charter can refer to the relevant metrics and expectations.
·I can justify operational metrics at quarterly, monthly, and weekly ·I can justify team culture metrics monthly
You mention risks.
·I pool barriers, risks, issues, and questions (spells BRIQ) in an asset called “Parking Lot” ·Teams should align on the Parking Lot approximately weekly
The “evidence to support the request’s value and urgency” resides in certain Current State documentation.
“Who owns the business decision?” is a uniquely ambiguous question. 😊
Teams can claim to have an infinite number of decisions, so that construct is difficult to manage, synchronize, standardize, etc.
However, teams willing to formally “bundle” their decisions have a culture advantage, because the team can align on a finite number of “decision bundles.” That finiteness is explicit, never rigid, and every Lessons Learned exercise is prone to tweak a team’s inventory of “decision bundles.”
I believe your post involves the following specific Decision Bundles: Change Log, Roadmap, Scorecard, and Project Charter.
Your reference to “evidence” points to a handful of valuable Current State decision bundles. I count 7 worthwhile decision bundles under the umbrella of Current State.
FWIW, I respect the spirit of all things “lean,” but I’ve seen the term misused to justify shaping a culture of being short-handed … saturation, fatigue, and burnout.
·I think the notion of a “project” is great when the team places value on a sense of closure ·If the team shrugs at a sense of closure, squishiness reigns! 😊
I don’t use the phrase “Change is constant.” I use the phrase, “We are in deep, deep innovation debt.” The term “Innovation Debt” shapes culture and ambition. “Change is constant” leads me to the conclusion, “Minimize expectations.”
If there is ambiguity about an “owner,” govern with verbs … simple verbs … that have interdependencies, duration, boundaries, and a sense of closure.
“Own” is a counterproductive verb in managing because I can’t easily associate dependencies, durations, or a sense of closure.
Competent, benevolent, trustworthy management grasps interdependencies, durations, and a sense of closure. Five such verbs to shape this culture are Draft, Review & Revise, Approve, Distribute. These Five Verbs have plain, unambiguous interdependencies, durations, and a sense of closure. Pretty valuable if you want a low VUCA workplace culture.
If you want a high VUCA workplace culture, I have a list of 100 distinct verbs for you. 😊 There’s a time and place for exotic vocabulary. A project plan is not that place. 😊
These Five Verbs fuse together authority and accountability.
If you want to decouple authority and accountability …
·RACI formalizes accountability without authority (no fun) ·Org Chart formalizes authority without accountability (lucky folks!)
I struggle with the word “Discovery” because I can’t tell if it’s an umbrella for Current State, Future State, or both. Is it Process, Tech, both?
I hope some fraction of this is helpful! To summarize …
·“Decision Bundles” are valuable because we can shape "Finite Productivity" ·Pacing bundles via Five Verbs is high discipline and high empathy. ·Smooth is fast ·Lumpiness is not fast. 😊 Saving Changes...
Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
I think the most important thing to determine if a Request is ready to become a project is a prioritization of the organization's backlog, and where this specific request fits into that priority list. For example of you have a ranked list of say 100 requests and your backlog, and a new request is submitted that fits in a # 70. This would mean that 69 other requests will deliver more value to the organization and should be started before # 70. Saving Changes...
Community Champion
