Cancel your Saturday tee time. In fact, forget about even having a weekend (or weekends) at all. You’ve just been handed the project from Hell. Here’s what landed in your inbox:
“IT management needs to provide global, transparent connectivity to the corporate network. Complete by fourth quarter.”
Based on a true story
What’s even more frightening is that I actually received that assignment once. At first glance, it seemed like we were facing an enormous task. We would have to build a network that connected all four of the company’s business units. It involved 500 facilities in more than thirty states.
The answer to managing this monster wasn’t to panic—it was to plan.
Project stakeholders—that includes any boss—expect to solve all of the world’s problems with a single project. Part of your management responsibility is to control expectations by:
- Paring down the objectives
- Defining the project scope
Scope v. objectives
This leads to a question: “How is project scope different from project objectives?”
- Project objectives are the goals, what the stakeholders expect to get from the project.
- Project scope refers to the limitations, the boundaries of the project.
Questions to help you narrow your scope:
- Who will be the end customer?
- What’s the deadline?
- What’s the budget, and what are the limits on other resources such as staff?
- How can I divide the project into phases?
For example, with a major software rollout, the scope might define which departments will be implemented during each phase. This allows you to break the phases down into more manageable pieces, increasing the probability of success.
How I tamed the beast
Let’s return to my monster project. If you look again at the objective, it’s pretty broad. The memo didn’t say how to implement the project or how the project’s success or failure would be judged.
So first, I clearly defined the project’s scope. I was charged with making the changes to “all corporate users in the home office who currently have a PC.” Notice that the scope has three separate limiting factors:
- “all corporate users”: This eliminated users from the separate business units.
- “in the home office”: This limited the project to the LAN.
- “who currently have a PC”: This physically limits the number of users and ensures that we didn’t have to provide PCs to those who didn’t have them.
A happy ending
That well-defined scope helped us narrow the project into something more manageable. We scrapped the unrealistic idea of connecting hundreds of offices in dozens of states.
Instead, we built a LAN/MAN that connected two buildings in a single metropolitan area.
Proper planning transformed a nightmare project into a manageable one. We completed the project on time and on budget while meeting the objectives of our stakeholders.
When you define a clear objective and identify a narrow scope, you’ll increase your chances of having a happy ending to your next project.
Andy Weeks is the director of consulting for Koinonia Computing .He has worked in IT for over a decade as an end-user support manager, network architect, and business process consultant.
What’s been the most unreasonable, “get-it-done-yesterday” assignment you’ve ever faced? Post a comment below, or send us an e-mail with a story idea.