Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
Have you ever had a project where you completed a project charter that included the original project requirements, yet during the project there was a surprise and the details that these requirements changed? Any suggestions as to how we can avoid these types of surprises during project execution?
First, I've rarely used charters as a home for any type of mid or low-level requirements as their main value is in authorizing a project's existence and getting alignment on major concerns from key stakeholders.
And it is always good to check with all key players as early as possible to get a feel as to how flexible requirements might be over the life of the project and then to pick a suitable requirements management approach based on that.
Senior IS Project Manager| Baycare Health SystemsClearwater, Fl, United States
Thanks for the great feedback Kiron. Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Michael,
agree with Kiron, I use charters merely to assign authority to the PM from the sponsor for a given project. It could be a one-pager; the project can be identified by a number or name.
Yes, some say that a charter should include much more, including the PMBoK Guide, and for small projects with small changes, that works.
Parameters that are known at the point of initiating a project are often documented in a business case, contract, or other artifacts. A project manager may want to transfer this to artifacts governed by the project management plan, for example, the requirements register. Most of them are 'progressively elaborated,' and change thresholds may apply, triggering decisions by the Change Control Board.
And yes, this adds to complexity. Saving Changes...
Sergio Luis ConteHelping to create solutions for everyone| Worldwide based OrganizationsBuenos Aires, Argentina
The point is: product scope determines the project scope. Why? Because you are part of solution where solution is equal to product plus project. Project Charter is the "contract" to engage all the interested and impacted parts but with focus on the basement, on the foundation. You will find more key points for your are asking when take a look to Barry Boehm "Cone of Uncertainty" Saving Changes...
PMO Leader | Speaker & Mentor | Content Leader – PMOGA Latin America
Hub| Catholic University of UruguayMontevideo, Montevideo, Uruguay
Yes, requirements often change during execution. To reduce surprises, the most effective approach is to maintain active stakeholder management, periodic scope reviews, and a formal change control process that allows you to quickly detect and adjust any deviations.
...
1 reply by Jeff Panning
Apr 09, 2026 5:07 PM
Jeff Panning
...
If requirements are changing during execution, there's a good chance the discovery process of needs based requirements was hurried or that the team shifted too quickly from the problem definition mode into solution mode. Another outcome of hurried discovery work is potentially missing key stakeholders.
If requirements change frequently, adopting an agile approach for delivering the project can be beneficial. Agile enables requirements to be gathered, prioritized, implemented and then validated with the stakeholders through regular review cycles and feedback allowing the solution to evolve and reducing surprises in the requirements during project execution. Saving Changes...
Program Manager| HARPER SRLSanto Domingo / Distrito Nacional, Dominican Republic
Yes, this happens very often. One key reason is that charters are usually created with high-level assumptions, while real understanding of needs emerges later. Something that can help reduce surprises is separating authorization from detail: use the charter to confirm purpose, authority, and boundaries, then manage requirements through living artifacts that are reviewed regularly. Frequent stakeholder check-ins, early validation of assumptions, and a clear change process make shifts visible sooner. When uncertainty is high, iterative approaches also help surface changes earlier instead of letting them appear late in execution. Saving Changes...
Jeff PanningSpeaker, Facilitator, Thought Leader| JP Training & Consulting, LLCTemperance, Mi, United States
Jan 09, 2026 9:01 PM
Replying to Fabian Crosa
...
Yes, requirements often change during execution. To reduce surprises, the most effective approach is to maintain active stakeholder management, periodic scope reviews, and a formal change control process that allows you to quickly detect and adjust any deviations.
If requirements are changing during execution, there's a good chance the discovery process of needs based requirements was hurried or that the team shifted too quickly from the problem definition mode into solution mode. Another outcome of hurried discovery work is potentially missing key stakeholders. Saving Changes...
Information is not knowledge,
Knowledge is not wisdom,
Wisdom is not truth,
Truth is not beauty,
Beauty is not love,
Love is not music
and Music is THE BEST
Community Champion
