Chartering Away
As I mentioned in my last post, I'm in the midst of standing up a new project. This involves hurrying up to finish charters, PMPs, RACI charts, risk registers, and all those other trappings of a waterfall project--and then, after the hurrying up is done, comes the waiting. Sometimes, this process can drag out for what seems like a long time. We go back and forth on the word choice for page 4, paragraph 2 of the charter. We incorporate multiple rounds of comments to chase the elusive executive signature. And then, once signed, it's full steam ahead. But sometimes, by this point, particularly in a government setting, the wind may have fallen out of our collective sails. No wonder they call it waterfall. There's a rapid torrent of loud excitement and then...we fall off of a cliff into oblivion. Why were we doing this project again?
Contrast that with the agile approach, us waterfall-weary PMs are told. Chartering is a breeze! Teamwork is fun! If we're falling off of a cliff, at least we're all in this together. Of course, agile is by design less certain than waterfall. But the supposed certainty of a freshly signed charter is merely a facade. For example, I've never heard of a project team that wasn't at least tempted to revise its charter once signed. Charters are supposed to be static documents, but the projects (and the teams that comprise them) are living things. So it would seem that the chartering process needed to be refined to recognize that. How do we do that?
Dispense with your organization's chartering template. This lumbering old elephant can learn some new tricks. Instead, hold a team brainstorm to make sure all participants are on the same page with regard to the project's goals and objectives.
Limit your charter to one page. Anything longer than that won't be useful. It won't be read.
My organizational IC also suggested something that hadn't occurred to me but, of course, makes perfect sense. You know all those things that send your waterfall project pitching and crashing over a cliff? Figure out what those problems are, and write them down. Your charter should define the parameters required for healthy team dynamics.
Revisit your charter. Just like you're supposed to revisit and update the risk register. And then actually do it. Instead of burying this task as a checklist item in a multi-line schedule, store the charter in a prominent place. Start your scrum meetings by pulling it up on the webinar. Is everything still working? Do we need to adjust? Listen to your team, and adjust.
In general, people over processes is not a bad way to approach any type of project, whether agile in name or not. I hope these techniques will help your team charter away into a churning sea of fresh, new ideas.
