managing a web project

In some ways, this whole book is about managing a web site. But project management is a science in its own right. Strategy must be set, decisions made, a team hired, and a site built all on schedule and budget. But there's no single correct way to accomplish this.

The best methods will vary with the size and scope of the site, and the temperament of the team. Some projects rely on tight schedules with firm deadlines, regular meetings, and structured documentation. Others leave deadlines loose and documents simple.

So the details will vary. But certain key principles apply to web projects of all shapes and sizes.

4 golden rules for web project managers:

  1. Clarify what you're creating

  2. Decide how decisions will be made

  3. Learn how to say no

  4. Create a "process"

clarify what you're creating

The first step to web success is simple: You have to describe what exactly it is you're creating. This may sound obvious, but it's startling just how many projects get started without a clear idea of what's being built or what it's supposed to accomplish.

"It sounds strange," says Kris Carpenter, former VP of Excite. "But we had projects get pretty far along before we realized that the team just wasn't clear on what they were building. They hadn't fully comprehended the application experience they needed to enable. They could describe features and benefits in a PowerPoint presentation they used all the right language but at the end of the day, they didn't have a clear understanding of what the end product needed to be or how they would enable that application."

To make sure everyone on your team is rowing in the same direction, it's important to articulate the site's mission and set concrete goals. These clear directives will save you time and energy down the road, and they may be the key to hitting a tight deadline.

"I had only six weeks to build my first major web site," says former MSN managing editor Martha Brockenbrough. "Six weeks! That's barely enough time to give birth to a rabbit!" Clarity, she says, was the key to her team's success. "Everything moves really, really quickly. So what you have to do is get everyone clear on the goals, on board with the mission."

See writing a mission statement, p. 12, and setting goals, p. 14.

decide how decisions will be made

Over the course of developing your site, you'll have to make decisions, large and small. How will these decisions be made? Who has input into the decisions, and who makes the final call? These questions about who answers the questions are important to resolve before you begin work.

"The most important thing that makes web projects go well is when the team structure and the decision-making process are clear and agreed-upon from the beginning," says Lance McDaniel, VP of Creative for SBI and Company.

"Frequently, we'll ask a new client, 'Who's running the project?' and they say 'We all are!' And I say, 'Okay. But when it comes down to whether your web site is blue or green, who decides? What if it's a 3-3 vote? Is it a blue-green site?'"

It's a simple example that speaks to a larger truth, McDaniel says: "Ultimately, you need one person who has the ability to cast the deciding vote. You can only build a site in one direction."

But the solution isn't as simple as naming a leader (although that's an important step). Web projects are usually collaborative ventures that affect an entire organization. In order to get everyone on board, you need to identify key stakeholders in the organization and involve them early soliciting their opinions on site direction and goals. (See how to get everyone on board, p. 341.)

You also need to know whether anyone the CEO for instance has the ability to overturn decisions. If so (and this is usually the case!), take care to get their input early on. You may have to lobby for their attention, but better to put the effort in early than have them object later on.

Finally, do what you can to avoid design-by-committee. Many companies create a large task force or several to oversee their web site. And while the idea is well-intentioned (collaboration is an important goal), too many cooks without rules in the kitchen create a big mess.

learn how to say no

The dirty little secret of every successful web producer is that they know how to say no. They may have learned to say it in the most charming way possible ("That's a great idea! I'll put it on the feature list for version 3.0.") But say it they must. And here's why: Every web site runs the risk of "feature creep," which happens when different team members get excited about different ideas, and the site gets pulled in too many directions. If creativity is left unchecked, the To-Do list will stretch endlessly and the site will lose its identity. A strong product manager can head off such silliness with a single word: "No."

"If your product manager can't say no to people who ask for features, that's a red flag," says Peter Merholz, a partner with Adaptive Path. "Probably the single most valuable thing an organization can have is a product manager who can step back and see the whole picture. If they have a coherent vision of what the product ought to be, then they can say "No" because what's being requested doesn't matchthe vision for the product."

Buy these books!

graphics/buy.gif

Developing Effective Websites: A Project Manager's Guide

Roy Strauss and Patrick Hogan ($26.95)

Collaborative Web Development: Strategies and Best Practices for Web Teams

Jessica Burdman ($39.95)


"I actually don't know why I called this meeting. I guess it was just a reflex."

graphics/322fig01.gif

create a "process"

Who does what? And when? And how? These are the questions to answer before you begin working, not a week after your first missed deadline. Every good project manager (and every consultant, good or bad) will talk about "process."

Process covers things like:

  • Schedule & budget

  • Meetings

  • Deliverables

  • Documentation

Though these topics make non-manager eyes glaze over, a good process goes a long way toward the success of web projects. And the key to a good process is consistency: Design a system you think will work for your team, and then stick with it. As Greg Dotson, Chief Information Officer of Guru, advises: "You all have to agree that you're using this process, and you're not just going to throw it out the window when the first deadline is missed."

Schedule & budget Time and money or the lack of them are facts of life on web projects. In an ideal world, the schedule and budget would be built from the ground up, based on what you need to create your ideal site. But usually, it's the other way around: You have to look at available time and resources, and figure out what you can afford to make. But don't despair: These constraints actually help you place limits on a project, and a few scheduling tricks can help keep you on track. (how to set a schedule that sticks, p. 324.)

meetings No one likes meetings. And some people prefer to call them "working sessions." But whatever you call them, they're important. They keep the project on track and help team members remember that they're a team. To make them as painless as possible, decide ahead of time when they'll be held, how long they'll run, and what will be accomplished. And, oh yes, serve food. See how to run a brainstorming session, p. 326.

deliverables Over the course of the project, different team members will have to produce work site maps, technical specs, marketing plans, etc. so that everything else can proceed. Which of these "deliverables" must be produced at each stage? Make sure each team member knows what he's expected to deliver before his deadline looms.

documentation What sort of written documents must the team produce? Will the producer write a product plan? Will the engineer write a technical spec? Some teams go heavy on documentation, and some barely write down the site's name. It's important to write something down; how much is a question of style. See writing a plan, p. 21.

lesson from the trenches: how to save a schedule that's slipping...

graphics/323fig01.gif

"You should never throw more people at a project at the last minute."

Pamela Statz

Its an all too familiar situation. Your deadline is looming, and it's clear you're not going to hit it. What to do?

  1. Extend the deadline. Although it causes managers deep distress, there's nothing wrong with extending a deadline. Don't just let the project float. Set a new schedule, and make it stick.

  2. Do less. If you have a hard launch date that can't be changed, your only attractive option is to cut back on features. "The best thing to do at that point is chop off a piece of the project, whichever is the least important," says Pamela Statz, former production manager for HotWired and Lucasfilm. Focus your energy on the site's essential elements; others can be phased in later.

  3. Expand the team. You can also bring in more people to help finish the work. But this, Statz says, is perhaps the worst thing you could do. "You should never throw more people at a project at the last minute," she says. "It just never works. You might think, 'Oh, this project is running behind schedule, let's add 10 more people to the staff.' But you can't! It becomes a management nightmare, with all of these new people who don't know the project or the company. Then you have to spend all your time training them, and you can't get the actual work done."


apply what you already know

If you're new to the web but not to project management don't hesitate to apply what you already know. "The web is very similar to other disciplines, other industries," Pamela Statz. "Architecture, software development, filmmaking they all work basically on the same premise: You need to do a lot of planning, you need to keep people on schedule and on budget throughout the process. And you need to have a really big party when you're done."

lesson from the trenches: how to set a schedule that sticks

graphics/324fig01.gif

"The key is setting some early deadlines. When a team hits a deadline early on, it sets them up for success."

Greg Dotson

graphics/325fig01.gif

"The schedule needs to be agreed upon by the people who do the actual work."

Lance McDaniel

Although few people would list schedule-setting as one of their favorite things, it's an indispensable skill. Nearly every successful web site has a task-master behind it. Someone or several someones has to make sure the trains run on time and the site launches when it's supposed to. Here's some expert advice on setting a schedule that sticks.

  1. Define the project before setting the schedule. It's impossible to set realistic deadlines for a vague, ill-defined project. You'll need to describe the scope of a web site before you can figure out how long it will take to create.

  2. Set a real schedules with real dates. It's essential to have a launch date, even if it proves wrong. Without a deadline, it's difficult to motivate a team and impossible to measure progress.

  3. Ask each person, "How long will this take?" A solid schedule is built from the ground up, by asking team members how long each task will actually take. This empowers the team, builds confidence in the schedule, and allows you to hold people to their own estimates.

    "The schedule needs to be agreed upon by the people who do the actual work, or at least a valid representative," says Lance McDaniel. "Of course, one of the tricks is turning managers into valid representatives of the people they manage."

  4. To hit hard deadlines, make hard decisions. It's rare to be handed a blank slate on which you can draw your ideal schedule. Usually, you'll be working against an external deadline, which you don't control. Work with your staff to decide which steps must be skipped or features cut to make the date work. You may even decide to focus on key features while fudging the others. A risky approach but it worked for software engineer Jim Morris when launching an online store: "We had only six weeks to build the site, so we focused on the features that had to be built first," he says with a mischievous smile. "When it launched, we didn't have the billing software written. But customers didn't care. They don't care if you don't bill them."

  5. Set smaller deadlines along the way. Establishing and hitting milestones builds confidence among team members and also makes hard deadlines easier. "You can't just say, 'We've got to be done in six weeks! Go! Go!'" says Martha Brockenbrough. "You have to break it down for people. A good manager, and a good producer, is capable of breaking everything down into easily digestible parts."

    "I've found that teams can be pretty resilient around hard deadlines, even if they seem unreasonable at first," says Greg Dotson. "The key to staying on schedule is setting some early deadlines. They're not only early for the sake of being early, but also for the sake of being attainable. When a team hits a deadline early on, it sets them up for success."

  6. Look for red flags. Always double-check the schedule, looking for ill-defined tasks, over-loaded team members, or deadlines set too close together. These may indicate aggressive scheduling or confusion about tasks. "A good manager can quickly spot the things that just visually are red flags," says Greg Dotson. "Like tasks with long timelines or nebulous names like 'database work.'"

  7. Make progress visible. Teams build momentum when they can see the progress they're making. Create daily builds of the site, print out new designs, create a chart tracking percent completion whatever you can do to help people see the progress around them.

  8. Require progress reports. If you're managing multiple teams or a large project with many facets, you may need team leaders to submit progress reports, explaining what they accomplished that week. No one likes writing them or reading them, for that matter but they're a necessary evil in bigger companies. They hold producers responsible for their projects and allow senior managers to identify projects that are falling behind.

  9. Clear obstacles. If you can see that your team is stuck, ask them why. They may have questions, or they may be running into problems they can't solve on their own. "A lot of times, a problem is difficult for a team member, but incredibly easy for the manager to solve," says Martha Brockenbrough. "People love it when you clear an obstacle for them, and, as a manager, that's your job."

  10. Pad the schedule. To be on the safe side, it's always best to build some extra time into the schedule. You'll need it! "Padding, padding, padding! It's very important! Put that in your book," says Pamela Statz, who has managed web sites for companies like HotWired, Lucasfilm, and Future Farmers. "You have to pad your schedule, because some things will take more time than you think they will. Other things take less. But if you've properly padded your schedule, you should be okay. A good rule of thumb is to always set QA to be a few weeks longer than neccessary. There you go! There's your extra time."

  11. Don't agree to an unrealistic schedule. Too often, entire teams sign on to hit impossible deadlines, and no one's willing to speak up and admit it. "That's what's called 'delegated delusion,'" says Greg Dotson. "There's an unrealistic deadline, and everybody knows they're not going to hit it, but nobody wants to admit to upper management that it's all delusional."

    It's important to be realistic, and also to ask: Why the rush? "In retrospect, now that I'm out of the business, I think people kid themselves about timeframes all the time," said Cate Corcoran. "People think things are more urgent than they are."

  12. If you're running behind, do less. If your project is slipping off schedule, you can either cut back on the site's scope or extend the deadline. (See how to save a schedule that's slipping, p. 323.)

  13. If the schedule slips, set a new one. Web projects are complicated, and there's no great shame in falling a bit behind. But when you realize you're going to miss a deadline, it's important to set a new one and make it stick. More than one slip causes everyone to lose confidence. "My rule is that if you're going to slip, try to slip only once and know what you're slipping to," says Greg Dotson. "Don't set another bad deadline."

  14. Don't despair when things go wrong. It's important to remember that web development is complex and sometimes unpredictable; you have to expect some slippage in the schedule. "It's important to remember that software is hard to develop; it's hard to keep everything on track," says Greg Dotson. "If you slip only a week, you're doing a great job, especially if it's a project of any complexity."

    Pamela Statz is even more emphatic. "75% of the time, things go terribly wrong, in spite of your best efforts. And you should be thrilled when something actually gets done and works well," she says with a completely straight face. "Then again, I'm something of a pessimist."

  15. Throw a party when you're done! Regardless of how successful a project was, it's good for morale to celebrate its completion. Have a party or at least eat cake!


lesson from the trenches: how to run a brainstorming session

graphics/326fig01.gif

"You have to give people a chance to think around the question in different ways."

Emily Simas

At some point, nearly every web producer will hold a brainstorming session to generate ideas for the site. Unfortunately, few will do it well. It isn't enough to get people in one room (although this alone can be a challenge), you have to know how to draw good ideas out of them, and what to do with the ideas, once drawn.

The key is participation, says Emily Simas, a trained facilitator, web veteran, and former Kindergarten teacher who knows a thing or two about group dynamics. "If you're going to run a really good brainstorming session," she says, "you have to get everyone involved."

No small task. As facilitator, you'll need to draw out the people who shy from public speaking, force the guy with the laptop to pay attention, rein in the noisy Nellies who usually dominate meetings, and keep everyone focused on the task at hand.

"Imagine a typical brainstorming session," Simas says. "You walk into a room, you sit around a table, and someone just spouts out questions and expects you to spout answers back."

Typically, only a few people and always the same people will participate. "These are the people who think while they're speaking," Simas says. "They're the noisier people in the room."

But they're not the only ones with ideas. "Some people need to take in all the information and absorb a lot more before they come up with ideas. And if you're going to run a good brainstorming session, you have to give them a chance to think around the question in different ways."

Circulating the questions before the meeting, breaking off into small groups, allowing "think" time, and requiring everyone to write down their ideas on Post-its, perhaps are all ways to draw creative ideas out of everyone in the room.

And while it's worth it for the ideas alone, brainstorming sessions ones where people actually participate and feel involved have another benefit: They help team members feel invested in a project. And when people see that their ideas are being heard and integrated, they're likely to work harder toward the site's success.

  1. Have an agenda. Like any other meeting, brainstorming sessions run best when participants know what to expect. Give an overview of the process, set a time limit, and outline your goals."

  2. Explain how decisions will be made. "You've got to somehow get agreement on how the decision-making process is going to work. People should feel that they're heard at the beginning, that their ideas are part of the process, and that there is a structure for how the decision will be made."

    "If people don't feel they're part of the decision part of the process they're not going to work as hard toward the end product."

  3. Carefully craft your questions. Brainstorming usually revolves around questions that are posed to the group, with the goal of generating as many ideas as possible. "But if your questions are too narrow, you'll get run-of-the-mill answers," Simas warns.

    "You have to somehow challenge people to break out of thinking within their normal limitations in the working world. You have to craft your questions in a way that will inspire creativity."

  4. Create an idea board. Throughout the session, all the ideas that are discussed should be written on a board where everyone can see them. This might be a white board, or butcher paper, or just the wall. But be sure everyone can see it, and that the ideas can be permanently recorded later on.

  5. Get everyone to write their own answers. Rather than shouting out suggestions for a moderator to scribe, invite participants to write their own answers down perhaps on Post-its. Limit them to one idea per Post-it, and have each person explain their ideas before sticking them on the board.

    "I'm a huge fan of the Post-it note," says Emily Simas. "It's a brilliant brainstorming tool for a number of reasons. First, if people write their idea in their own handwriting, they feel more ownership of it when it hits the board."

    "It's also a phenomenal tool for organizing similar ideas. Seven people can say the same thing, and you can just stack those seven on top of each other, and they're naturally organized."

  6. Give people time to think. Most people need a little time to mull things over. Always offer some "think time" between questions.

  7. Break into small groups. Some people think better when they have a chance to talk through a problem in a small group. And many shy people are more likely to speak up in a small setting. So breaking into small groups and reporting back to the overall group can be very effective.

  8. Draw out the "quiet ones." Many of the ideas here breaking into groups, writing ideas down will encourage participation from the less usual suspects in the room. But Simas encourages facilitators to take more direct action, as well. "If you see someone who continually looks like they have something to say, but just isn't talking, take a moment and say, 'June, you look like you had an idea. Was there something you wanted to share?' Call those people out."

  9. Rein in the noisy ones. In any meeting, certain people are more likely to speak out than others. But if your noisy ones are particularly dominant, or prone to interrupting, you might want to use a "speaking object" to control who has the floor. Only the person holding the object (a "Koosh" ball is a good one) gets to speak at any given time.

  10. Ask people to represent their departments. To help people take the process less personally, you can ask individuals to represent their departments or disciplines: "As a designer, I get excited about...." "As an engineer, I'm worried about...."

  11. Appoint a timekeeper. You should set a time limit on each group activity and appoint a timekeeper to enforce it. "If you know someone who generally drifts off or does work through meetings, make them the timekeeper," Simas suggests with a smile. "It's a great way to keep them involved."

  12. Serve food. Food brings double benefits to a brainstorming session. First, people are more likely to attend meetings where food will be served. Second, food can help get creative juices flowing.

  13. Don't penalize people or award prizes. Some facilitators like to reward people for participating or penalize them for being late. Don't do it, Simas says. "If you want people to sit and pout in the back, charge them each $10 for being 10 minutes late," she says. "Tried and true way to kill a meeting."

    Similarly, you shouldn't reward certain participants over others. "I'm just not into competitions," Simas explains. "I don't think they inspire creativity, and they definitely don't inspire teamwork. If it's the culture of your company, it might work. But personally, I'm way too Kindergarten teacher for that. I've seen some facilitators use food as a prize: 'The best idea gets a snack!' I hate that. Everyone's ideas should get a snack!"




The Unusually Useful Web Book
The Unusually Useful Web Book
ISBN: 0735712069
EAN: 2147483647
Year: 2006
Pages: 195
Authors: June Cohen

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net