How do you review and update your project charter throughout the project lifecycle?

In my experience, regularly reviewing the project charter is key to ensuring that it is aligned with current objectives and requirements. For example, during status meetings or important project milestones, it's important to take the time to review the charter and ensure that all stakeholders are still aligned with the scope and objectives.

Ideally project charters are not supposed to be updated, but I am considering a hybrid model being followed here & hence, during each project phase transition or major milestone, PM should revisit the charter &make necessary updates based on lessons learned, scope changes, or new risks identified. However, I strongly feel that if project's scope, objectives, assumptions, and constraints have been thoroughly defined and validated during project initiation phase, involving all relevant stakeholders, the need to update charter can be significantly minimized.

I think for each project the "regularity" is different and should be customized to each. Some - it is quarterly, others - annual if not bi-annual. I believe if the project charter set well at the inception, the updates would be either minimal or if the project/program is evolved significantly.

You can update the project charter, but more important is to review the Scope Statement, since this document need to up to date with all the project changes. Projects must have a Control board, with a process to create and manage “Change Requests”. And these CRs can change duration, objectives, and scope (in terms of WBS / SOW). In these cases, where we have a scope change, this must be reflected in the scope statement.

Es hilft die Anforderungen an die L?sung in regelm??igen Abst?nden aufzulegen und den Umsetzungsstand festzuhalten. Ggf. werden hier Anpassungen an den Arbeitspaketen oder am Design der L?sung ermittelt und mittels ?nderungsantrag ins Projekt eingebracht.

You can update the project charter, but more important is to review the Scope Statement, since this document need to up to date with all the project changes. Projects must have a Control board, with a process to create and manage “Change Requests”. And these CRs can change duration, objectives, and scope (in terms of WBS / SOW). In these cases, where we have a scope change, this must be reflected in the scope statement.

The project charter is a live document throughout the life of the project. Depending on the duration, it can be updated daily, weekly or monthly - which ever suitable, and communicated to all stakeholders so that they are aware of any updates/changes timeously.

Be careful with this statement – You need to involve your stakeholders during all the project duration, not only in charters review. The key stakeholders should be aware of every change that could be generate a charter update, they can be informed about it during weekly status report meeting or steering committee meeting. If you involve your stakeholders only when a charter update is necessary, they could receive bad or unexpected news about the project without any preparation.

I'm going to contradict here and say that your project charter does not change your project plan - your plan changes to accommodate the charter. If you consider your project charter to be the project brief and the guiding north star for everything you do in the project, and it's been approved by the stakeholders, then the project needs to be designed in alignment with the charter, not the other way around. If it turns out that the project plan is *better* than what the project charter called for or if in some other way brings more value, then it might be time for a new charter that identifies new/better outcomes or better serves the organization.

In my opinion is just the opposite – You need to update your plan when you have a charter update that justify it – Some actualization like project goals, resources available, assumptions or risks. It means you should have in mind that not every charter update will need a plan update.

Since in implementations, the product of one phase is an input for the next one, is better to review the charter outcomes in the end of each phase. For do it, I like to use the Stage Gate approach, where we have all the expected conditions (based on the project charter) need to move to the next phase. We prepare a document with the current progress and compare it with the expected condition. With this analysis we can define if we can move or what we still need to perform to move on.

We need to complete the project life cycle, started with the project charter sign in and finish with the project sign off. The last version of the project charter should be archived in the company knowledge base and used in the future as an accelerator to future projects.

Regularly refine the renewable energy project charter, drawing insights from feasibility studies for connection applications. Examples include adjusting offshore wind turbine locations based on environmental assessments. Adapting the charter to optimize onshore substations aligns with grid connection requirements, ensuring seamless integration into the transmission and distribution network. Continuous updates enhance project viability and success.

The archived project charter is a great accelerator to be used in future projects. It contains lessons learned and information that can be used to reduce time in the opening of future implementations projects.

I was in a situation where I needed to change the project charter in agile and hybrid projects. However, in waterfall project all project charters were stable, and no change was acceptable as these projects were funded based on a firm approved plan and charter.