Project Charters and Social Contracts
On just about every project I’ve been involved with over the past twenty years, I have promoted the idea of a “Project Charter” (or better-yet, a “Social Contract” for the project).
I have reproduced the basic template for a vanilla Charter, below.
Aside: These days, I myself would avoid working within the structure of a “project” wherever and whenever possible, the “project” concept being a zero-sum game, at best. But I recognise many folks have not reached that happy place, as yet. Accordingly I’m open to the accusation of helping folks “do the wrong thing righter” with this post. Folks still mired in the project swamp may find it useful, nevertheless.
The Project Charter
The strength of having a charter (a.k.a. Article of Understanding) lies in helping stakeholders – dev team members, sponsors, customers and others – understand the social context and mutual responsibilities involved in working together. When it works well, everyone is more or less “on the same page” with regard to expectations, etc.
Article of Understanding
In line with meeting the needs of the project’s stakeholders as quickly as possible, the project team wishes to keep the amount of detail in the requirements for this project to a prudent minimum. The following Article of Understanding attempts to set a certain level of expectation amongst all concerned regarding the likely consequences of that wish:
“Project [Project name – TBD] will try to capture every important requirement in its functional- and non-functional- requirements models, but gaps and ambiguities will inevitably occur. To resolve these the project team will need to invent details on their own. On a typical project, hundreds of such gaps can exist, which makes it impractical for stakeholders and the project team to confer about each one. The project team typically resolve the vast majority of these gaps without the stakeholders ever becoming aware that an ambiguity existed.
In some cases, a stakeholder will have a strong feeling about how the project team has resolved a particular ambiguity and will require a different resolution. This happens to a greater or lesser extent on virtually every project. To the extent that a stakeholder clarifies such ambiguities later in the project to mean something different from the project team’s earlier assumption, there will probably be negative impacts on costs or schedules, or both. The project team will try from the outset to structure the deliverables to minimise these negative impacts, but we all know from long experience the inevitability of this unfortunate feature of development. We will all try to remember this.
The project team undertakes to try to be responsive to the stakeholders’ needs and create solutions that satisfy those evolving needs with minimum disruption to costs and schedules.
The stakeholders undertake to remember that the project team tries its best when interpreting gaps in the requirements.”
The key weakness of a project Charter, is the unilateral or one-sided nature of the document. Typically drawn up by the dev team, a Charter rarely affords the opportunity for buy-in and commitment from all stakeholding parties. In many cases, stakeholders do not see the value in spending time understanding and committing to such a charter. Indeed, quite often some stakeholders will fear the loss of control and increased accountability that such a multi-lateral agreement notionally brings.
A project Contract, on the other hand, demands more work and more understanding from all the signatories, which can take much time and effort to negotiate and discuss. Many organisations are not prepared (sic) to commit the level of effort required to make this happen.
I do not intend for the reference to “requirements” in the above sample to imply e.g. a Big Design Up Front approach to requirements gathering. If you feel the word may seduce your readers into this assumption, feel free to make more explicit the iterative nature of requirements gathering – assuming that’s how you run your projects, of course.