A great way to destroy a program is to avoid writing a charter. When I do assessments or work with teams, I often find that programs do not have charters, or that the charter is too big, or is missing some key piece of information.
But what do you really need in a charter? Too big a charter and it’s tempting to fake your way through it. Too small a charter, or insufficient information, and it’s not worth the time you spend on it.
I’m not sure there’s a “Goldilocks” size for every program’s charter, but here’s my attempt:
- The program vision. You need a vision or purpose so everyone knows where the product is headed. Depending on the size of the program, the projects that make up the program may need visions also, but you need to know you’re making a cell phone or a refrigerator.
- Release criteria. You need to know what done means for the product so you know when you can release.
Can you write more? Sure. Do you need to? Maybe not. If you’re agile, definitely not, not for the charter. For example, lots of people like to try to discuss ROI (Return on Investment) in a charter. Well, I can lie with numbers, to make the numbers look any way I want them. ROI is a prediction that only starts once the program ends, so that’s not helping the people creating the product.
Remember, a charter is just enough to help you get started. It’s not supposed to be a book, or a thesis, or the reason for the program’s existence. It’s also not supposed to be one sentence, “We’re making a cell phone.” The charter provides everyone on the program the 50,000 foot view of what they are building and how they know it will be done.
Don’t shortchange your program charter, especially if you’re working on an agile program, and don’t overdo it.
