The Charter is your Keel
Project chartering, whether handled formally or informally, is the pivotal first step to initiative success
I always begin the recurring seminars I teach at New York University’s School of Professional Studies with a model I describe as “ground zero” for projects. I draw two capital “P”s on the whiteboard, and define one as “Product” and the other as “Project”. Together, the class defines, from a shared perspective, what each of these terms means and the interplay between the two. The point of this exercise is to establish two key truths:
- These two concepts travel together but are not interchangeable
- While the Product exists in the real world, the Project is simply an organizational construct
The second of these truths has been on my mind recently as I have struggled to bootstrap several new initiatives.
The organizational construct that makes up any project includes an assortment of key attributes:
- Underlying motivation
- Current state vs. expected target state
- Success criteria
- Timeframe
- Human resources, allocations
- Jurisdictional authority
- Budget
- Other assets brought to bear
- External constraints (time, cost, organizational, regulatory, etc.) and their interplay with our own effort
Shared understanding of these attributes across the team represents table stakes for the project to progress effectively. Resources need this knowledge to inform the decisions they make every day as they push progress forward. These attributes are established, right up front, in a Project Charter. Sometimes, based upon the needs and larger environment, that charter will be formally documented. In other cases, because methodologies for defining these attributes are fully baked into the Project bootstrapping process, no document is necessary. The format of the charter doesn’t particularly matter. The act of chartering absolutely does. Socialization of these attributes across the community of resources and stakeholders is pivotal to project success.
The format of the charter doesn’t particularly matter. The act of chartering absolutely does.
All well-organized projects begin with a Kickoff session, the agenda for which essentially consists of outlining the project charter for the team. Who are we? What is our mission? What assets have been provided? What constraints define our boundaries? The team gets the message, any outstanding questions get clarified, and we get busy.
Several years ago I had a strange experience wherein a client wouldn’t allow me to schedule a Kickoff meeting at the front-end of the Project. Internal politics played a role, as did the fact that, “…nobody has time for your kickoff.”
I recognize that everyone is 120% subscribed. So am I. But if we don’t create clear, shared expectations about these attributes up-front, our project is likely to depart the rails before we even roll clear of the station.
- Necessary resources are not alerted of their participation, and are not available when we need them…
- Ability of the Project team to purchase materials is delayed due to protracted approval processes…
- Not clearly understanding WHY we are embracing this initiative, team members struggle to make key decisions
- Without clear definition of leadership’s target timeframes, the team can’t calibrate how to fit the project in with their other responsibilities…
Quite simply, the charter serves as the keel of your project, allowing you to sail a straight track even as the wind and waves do their best to toss you aside
Sometimes [often?] pushback on defining the charter comes because some of the attributes are difficult for leadership to lock down. Internal politics may make the establishment of clear jurisdictional boundaries difficult. Competing demand for resources might raise ire across units. Leadership might know the direction it wants to travel, but not the final destination. These challenges are exactly why the charter is so important. It is the right and responsibility of leadership to make these calls. Refusing to address these issues doesn’t make them go away, and the project team cannot be successful in an environment loaded with invisible gotchas. The team is sophisticated and resilient. Trust them to understand and manage whatever nuance may be embedded in these inputs.
As discussed at the top-end of this post, the project doesn’t exist in the real world. It is nothing more than a construct built of understandings, expectations, and agreements shared across a group of people unified around a singular goal. Every undefined attribute or unaddressed issue depletes the substantiality of that construct, reducing its ability to move swiftly and cut through challenge.
Every undefined attribute or unaddressed issue depletes the substantiality of that construct, reducing its ability to move swiftly and cut through challenge
Market-based product development is difficult enough to execute successfully even in the best of circumstances. Hobbling the project right out of the gate with a lack of clarity adds unnecessary drag, risk, and churn. The act of project chartering — whether formal or not — establishes the firm foundation upon which everything else will be constructed.
