Datasheet

In the first column, we’ve identified the different roles that are distributed throughout our project team.
From there, we’ve outlined a brief overview of the expectations that will be placed upon them over the
course of the project lifecycle. While it’s nearly impossible to accurately capture everything that a Web
designer is responsible for in fewer than 12 words, this brief synopsis should at least convey the most
important aspects of the role. Additionally, we’ve outlined the specific items each member will deliver
over the course of the project. These deliverables should be drawn directly from the scope of the project
and matched up to the individual best equipped to deliver them.
Also, you may notice that we’ve included a “project sponsor” on this table, which is a member of the
client organization that shepherds the project from inception to completion. While perhaps not as inte-
grated into the day-to-day execution of project goals and requirements as the rest of your team, this per-
son exercises veto power in critical decisions, defines the business needs that drive the project’s goals, and
ultimately facilitates communication between your team and other stakeholders from the client company.
As a result, this person is integral to the success of your project. Any additional information for which
they are responsible should be tracked closely, as though they were a part of your project team.
Budgeting Time and Expectations
After you’ve assessed the different needs of your project, you will be in a better position to determine
how long it will take, and exactly how much it will cost. “Time is money,” of course, but that’s rarely
more true than within the bounds of a consulting engagement. Granted, it’s a fine thing to discuss strat-
egy, scope, and staffing, but it’s your project’s budget that will determine whether or not any of those
things actually come to fruition. With a properly established budget, you can begin to add people and
technical resources to your project plan, as well as any other expenses that your project might require.
Furthermore, the amount of money allocated to a given project can limit the size of your team. Perhaps
our project plan requires two developers and one designer but funds exist only for two full-time
resources. As a result, something must go: either reduce the number of staff on our project, or reduce the
scope of the project to the point at which two people can easily handle it.
Conversely, the budget could affect the quality of our team: if the funds are not available to hire an expe-
rienced application developer, then we might need to hire a less-expensive (and perhaps less-seasoned)
resource instead. Or, if the budget is especially tight, we just might need to pick up that Perl book and
start skimming. Therefore, a solid understanding of any budgetary constraints will help us understand
the extent to which we’ll need to bootstrap our own skills or those of our team members, and how that
preparation will affect timelines.
Managing Change
Let’s say that we’re nervously eyeing the clock two hours from site launch. We’re looking at the last few
items on our to-do list and are feeling a bit pressed for time before the site’s go-live. Just then, our client
sponsor strolls up to say that his boss wants some holiday e-cards designed, and that they should go live
with the newly rebranded site (this has never happened to us, we swear). Just like that, our priorities
have been told to shift, but the project’s timelines haven’t budged an inch.
This is what is known as “scope creep” and is a part of almost every project. At some point, the require-
ments outlined at the beginning of the contract may need to be updated to reflect some new or updated
business requirement. If our project can’t adapt to our client’s needs, then we’re likely working on the
4
Chapter 1
03_588338 ch01.qxd 6/22/05 11:18 AM Page 4