September 28 & 29, 2020 | Virtual
Please login or join to subscribe to this thread
If you think it's big enough, I would say yes.
The charter can help in a number of ways. For one, it bounds the solution space. (e.g. This is an IT project, not a bridge construction.) That helps to focus the team if people want to do their own thing. The second is it helps when sponsor support is needed. If you need resources, like people from outside your organization to dedicate their time to the team, then the charter is handy to help ensure that you get what you need to complete the objectives.
Sorry @Mirko but I think you fall in the trap (hehehe). "Change is welcome" does not mean "there is not change control". First, Agile is not related to software and did not start with the Manifesto. In fact, the word "software" is inside the name for a reason. Second, there is no statement, there is not line inside the Manifesto (just in case your write your statement based on it) that said "change is welcome". What the Manifesto said is "responding to change" and inside the principles "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage". Mostly forgotten is before an initiative exists business analyst must work on creating the business case where one of the key components is the approach to be taken. From business case the project charter is created and project charter is "the contract" between or involved components where the approach must be agreed too. So, when to be or not to be a project charter is up to the governance model the organization has in place, there is not collision between having one and using an specific approach like Agile.
Each project needs a charter as an overall direction for the team and it is completely independent whether the project is executed in an agile framework or not.
Agile projects do have a project charter but it slightly varies from the one for waterfall projects.
The charter explains high-level deliverables plus triple constraints.
Agile differs from Waterfall on how the project is done rather than what needs to be done.
So, the agile project definitely needs the charter. The format may vary, but it it is a MUST.
I agree, there should a charter because it does not matter that you’ve selected a specific method of project delivery. You still need to give your project context, goals, basic framework. Projects do not happen in vacuum, certain coordination is always needed and if there’s no description of the project you can’t align it with other concurrent initiatives.
Project charter is also important for the team itself. Agile or not, the team needs to know what are they supposed to work on. But the format and content should be indeed adjusted to make it fit your methods of work.
If it has to include process & responsibilities, then there are different documents specifically for that. The project goal does not change. The Charter answers, why are we doing this project, the project vision, approach, most importantly authorization to proceed. Focuses more on how the project will be run THAN on exactly what will be built. It continuous to remain a flexible document, that allows the team to respond to changing needs and technology and deliver high value components.
we need to understand the "why" behind a given artifact, and the rationale for a charter when we have a true project (and not just a release within a product cycle) is still valid regardless of the delivery approach. Minimally sufficient should be the guiding principle for its creation, review & approval.
Please login or join to reply