It's Bigger On The Inside
My older daughter has been working feverishly at turning me into a Doctor Who fan this year. (Actually, given most of the crap that passes for television viewing, I'm a thrilled parent to find her interests lie in British sci-fi and mysteries.)
For those of you not familiar with the Doctor Who series, the Doctor (generally with a companion) travels around time and space battling nefarious aliens and underworld creatures who seek to destroy the human race. His "vehicle" of choice is called the TARDIS (Time And Relative Dimension In Space) and is cleverly disguised as a 1960's police call box. However, when mere mortals are invited inside, they see how vast and advanced the inside of the TARDIS is. Their first line of incredulity is almost always, "It's bigger on the inside."
With the advancing 50th anniversary episode called "The Day of the Doctor" coming this weekend, this observation about the TARDIS got me thinking about some of the projects I've managed over the years, as well as others I've observed. One of the biggest pitfalls of project management is scope creep, where the amount of work seems to grow once the project has begun; hence, "it's bigger on the inside."
In addition to just having sound change control procedures up front, I've learned a few tricks over the years to predict whether scope creep may be an issue. Here are my top tips to use at the beginning of the project before you travel into the future and see what's really inside the TARDIS:
- Can the Executive Sponsor articulate the scope? When I interview the sponsor, I like to see if they can succinctly sum up the purpose of the project. If I find them droning on and on and not coming to a point, that's a big warning flag.
- Can the Sponsor tell me what "Done" looks like? In addition to the purpose, I want to see their vision of successful completion. In other words, "we will be finished with this project when _____." If the one signing the checks can't recognize completion when s/he sees it, how do they expect the rest of us to know what it looks like?
- How many outcomes are expected? I'm of the Thoreau camp of "let your affairs be as two or three, and not a hundred or a thousand." The fewer deliverables expected out of the project, the better the focus will be for everybody involved.
- Are the Business Analyst(s) and Programmer(s) doers or accomplishers? This is tricky, but in getting to know my team, I like to determine the orientation of those doing the work, so I'll ask them questions about their jobs. Those who talk about accomplishments rather than tasks and work, are generally more focused, where those who talk about the doing over the completing tend to allow more work to creep in than necessary.
- Do they "know no"? Prioritization is key in projects, and my favorite quote has always been "the quality of our YESes is determined by the quantity of our NOs." In the Midwest, we've had customer service pounded into us, and the overcommitment of "yes" gets a lot of projects in trouble. I'd rather take the heat for saying "no" and getting done on time with the critical tasks.
Following these simple tips at the beginning of a project can save you a Dalek-attack-load of trouble once you hit execution. Now, Allons-y! Geronimo! (And when it comes to scope creep, Exterminate!)