1 The solution?

Joe,

I can sympathize with everything of what you are describing. However, these problems not are not limited only to the Web world. I may go even as far as to say that these problems are the main cause of ulcers in middle management.

The way I see it, the solution to the problem is a little different than repeating a mantra.

The solution to this problem has everything to do with hiring|being an experienced project manager who knows the field and understands the complexities involved in project implementation.

IMHO, among the victims of Web revolution are the designers and coders who started “just doing sites” and suddenly found themselves in the middle of a serious business with complex workflows and processes. Without solid project management skills, they had to learn PM using the BST (blood, sweat, and tears) method. As a result, Web project management processes are commonly ridden with “magic bullets”, ritualistic dances, and mantras.

There is no need to re-invent the wheel. It’s been told and re-told in many various ways. Go to school. Take a few PM courses. Or start with Amazon, if you’d like.

posted at 06:25 am on April 16, 2004 by Dimitri Glazkov

2 Pay me now or pay me later

Excellent article. It also shows, by implication, the absolute necessity of having a project manager who is given the authority to actually make decisions. This is a real problem when the project is done internally. Too often, the PM finds themselves constrained by an existing chain of command, if not explicity then out of institutional habit.

posted at 06:41 am on April 16, 2004 by Bryan Costin

3 Web Redesign | Workflow that Works

A great book dealing with website PMing is [url=“http://www.amazon.com/exec/obidos/tg/detail/-/0735710627/qid=1082127052/sr=8-1/ref=sr_8_xs_ap_i1_xgl14/102-0501718-5444948?v=glance&s=books&n=507846” title=“Web Redesign | Workflow that Works”]Web Redesign | Workflow that Works[/url] by Kelly Goto and Emily Cotler. Don’t pay attention to the “redesign” in the title; the book outlines the stages of any web project—definition to delivery.

Also, 37signals’ [url=“http://basecamphq.com/” title=“Basecamp”]Basecamp[/url] is a great online project-management application…as long as you remember to use it!

posted at 06:59 am on April 16, 2004 by Jacob Patton

4 Scope Creep

As this article points out, it really is all about managing the scope of the project.

If you are dealing with the appropriate stake-holders who have final authority on a project, the biggest thing you have to worry about is scope. If you do all your discovery work ahead of time and write it in a document that is delivered to the stake-holders AND SIGNED BY THEM, a PM will have a much better grasp when it comes to saying “Yes, this is in scope, go ahead” or “No, this isn’t in scope. We can do it, but it will take $X and Y time”

Being able to reference an agreed document for things like this will save quite a bit of headache in the long and short run.

I also want to point out the book referenced by one of the above posters. Website Re-Design is a good look at how a proper discovery phase (and subsequent project management) should be executed. It isn’t fully sufficient for “large enterprise projects” but you can easily take what they have and add the missing pieces.

posted at 07:16 am on April 16, 2004 by CM Harrington

5 Mirror World

we’ve just been burned doing an ecommerce site by scope creep. they now want to know thousands off the price :(

posted at 07:38 am on April 16, 2004 by mark

6 Other problems

One poster commented about a PM having proper authority. I agree with that to an extent and suggest that it goes a step further with defining everyone’s roles within the project. We have Project Managers, Business Analysts, Business Users, QA, Developers, Team Leads etc. All of them are involved at the different levels of the project. Too often the different roles aren’t well defined and tend to bleed into one another. The PM attempts to analyze what the business wants, the business attempts to define the interface design, the business analysts are trying to manage the details of the project, and the developers are having to deal directly with the business users when the interface they provide doesn’t match what the PM said they’d get.

There are other problems (HR issues) in that sometimes the BA’s and PM’s are nothing more than developers who couldn’t hack it and got moved into a new position. The assumption in doing that is that the person is familiar with programming and therefor should act as a good bridge between the user base and the developer. That’s not necessarily true.

Any project has to be a itterative team effort. PM’s shouldn’t sign off until they’ve consulted with developers to make sure that what the business is requesting meets what can be done. Likewise PM’s should be in close coordination with an apt BA to make sure that what the business is asking for is really what they need (so that there are no surprises).

The worst project scenario in the world is this:

You get a set of requirements for something that you can’t reasonably code. You push back and the business agrees to a compromise solution. You build out the compromise, set it up in production and users start using it. Then some time later the business comes back with a new set of requirements that completely scraps the functionality because it wasn’t what they really wanted or needed.

posted at 07:44 am on April 16, 2004 by Michael R. Havard

7 "Every one, even the cleaning lady, had an opinion

Nice read. Thank you.

posted at 09:11 am on April 16, 2004 by Sorvoja

8 Removing Functionality

While scope creep can be dangerous, how do I convey the implications of removing major functionality?

I was part of a project where an automated financial process was removed one month before the due date. The transactions now had to be done manually.

The project lost any return on investment with this canibalization. It became less desirable and created more work than the system it was replacing.

Any change in scope can cause problems.

posted at 10:21 am on April 16, 2004 by Andrew

9 This Scopes Creeping Me Out

I think one of the problems that I’ve experienced is managing stakeholder expectation alongside a project’s velocity.

Let’s be honest, most of the time the balloon phase gets shortchanged for any number of reasons – lost my briefcase, forgot about that email, didn’t realize you didn’t understand what i mean, he/she said this wouldn’t be a big deal. And most of the time we’re working on super tight budgets and timelines without enough people. So, ladies and gentlemen, how do you convey to the stakeholders that without formalized business rules and planning velocity could adversely be affected?

I can handle that. But how do you manage a stakeholder who’s clamoring for something

posted at 11:21 am on April 16, 2004 by El Guapo

10 where is the line?

Great article!

I think the biggest trouble I’ve run into has come with trying to balance the desire not to nickle-and-dime the client with the desire to put the brakes on scope creep. When the client emails relentlessly about a tweak here or a change there, it’s hard to really say “STOP” in a loud voice, because any of them individually are no big deal.

What I’ve done in the past is, in that initial balloon phase, to acknowledge the inevitability of change as the project continues, but say that we’d need to take a second look at budget and schedule if, say, there’s 5-10% deviance from the statement of work. And then keep meticulous records about all the requested changes, so when we get close to that tipping point, I can raise that red flag for the client.

Anybody have other ideas?

posted at 01:25 pm on April 16, 2004 by Nate

Discussion Closed

New comments are not being accepted, but you are welcome to explore what people said before we closed the door.

Got something to say?

Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.

Create a new account or sign in below if you’d like to leave a comment.

Forgot your password?

Subscribe to this article's comments: RSS (what’s this?)