Bad Project Warning Signs

Andy Budd, a freelance web designer in Brighton, England, offers 10 Bad Project Warning Signs, many of which ring very very true over on this side of the pond as well. In particular:

>* The project needs to be done in an incredibly short space of time, due to a fixed deadline. In these situations the potential client has often known about the deadline for a while. However it�s taken them longer to plan the project than initially anticipated so they expect the developer to make up the time.
>* The client says they want the site to be as cheap as possible, or they have an extremely low budget. This usually means the client doesn�t value their web presence much, preferring cheaper over better. In this situation potential clients are often spending their own money, can be extremely demanding and expect more for less.
>* The client expects much more from the project than their budget will allow. In these situations it can be difficult to manage the clients expectations.

A couple of my warning signs:

* The client is unable to articulate the outcomes/results they want from the project, or to connect those outcomes to accomplishing their organizational mission.
* The client resists the idea of trading off features, cost and time — the classic project management “iron triangle.”
* The client appears too busy and overwhelmed to do their part of the work on the project.

What are your warning signs?

10 thoughts on “Bad Project Warning Signs”

  1. I would add….

    Clients makes some statement that indicates they do not like technology or learning new technology.

    Your project contact is not empowered to be the decision maker on the project.

  2. Clients who insist that there’s no need for requirements gathering, and thus money can be saved by eliminating it from the project.

    “We already know what we need. We need a Web site!” (sigh)

  3. Great post, Jon. I’d add: decision-makers aren’t interested in technology, and the people interested in technology lack authority to make decisions. Not just a Bad Project Warning Sign, but also a sign of an out of touch organization.

    Edumacate me: I see a list of “Recent Trackbacks” in your sidebar, but I don’t see TrackBack URLs associated with your posts. How can I TrackBack here if I quote you?

  4. Ed, the trackback link is buried somewhat inconspicuously in the paragraph just below the main entry text, “You can leave a response, or trackback from your own site.”

    Not great usability on the part of WordPress, I admit.

  5. Some of the biggies are already mentioned, but I’d include:

    Clients who return scope and contract documents without clearly indicating changes (i.e. using Word’s track changes) for significant changes. This happened to me today.
    Clients who don’t have time to do adequate scoping, but are “on a really tight timeline” for development.
    Clients who schedule technology projects (website redesigns, database upgrades, etc) during their busiest program season.
    Clients who insist on line items in a bid, then try to remove the line items that they don’t think are important (like training, documentation, etc).
    Clients who start conversations with “We don’t want to nickel and dime you on this, but…”
    Clients who insist that audience research isn’t important because they “already know what our audience needs are.”
    Clients who want to save money on a project by having staff do work that they aren’t trained for (as in “our development director does some graphic design…”).
    Clients who want search engine optimization work, but aren’t interested in developing better content.
    Clients who don’t understand that custom software development is risky and problematic, and aren’t willing to consider existing COTS or opensource software that does 85% of what they need.
    Clients who have already made decisions about technology without a proper needs assessment. As in, “We want to do this in ASP. Or Filemaker. Or LISP.” (Okay, so I’ve never had anyone ask me do to anything in LISP. But you get the point.)
    Clients who use bootleg software. (Apart from other issues, it indicates a lack of commitment to having the resources to get the job done.)
    Clients who want technical change but aren’t prepared to make the necessary staffing or business changes to support that technical change (e.g. deploying a blog, but not carving out staff time to create new content.)
    Project managers who don’t communicate well with other staff.
    Clients who are averse to a “start simple, iterate often” approach and instead want a massive project in a single development cycle.

    That’s enough for now, I guess. At one time or another, I’ve had each of these happen to me.

    I’d also second the mentions that leadership needs to be bought in on technical change (in no small part because business practices are so tightly linked to technology), project managers need to be empowered to make decisions (and be willing to make those decisions), and staff need to have a good understanding of the amount of time that tech projects will take. So many clients seem to walk into a project thinking that if they just get the ball rolling, the consultant will do all the work.

    Incidentally, the Software Project Survival Guide by Stephen McConnell is one of the better books I’ve read lately about managing custom software development projects.

  6. Dear Jon: Thanks for your insights! I’ve posted a link to this article to the Information Systems Forum , because I think that this is well worth discussing. Warm regards from Deborah

  7. Excellent additions, Trey.

    And thanks, Jon–that’s helpful. Although definitely not user-friendly on WP’s part. It’s invisible on the homepage, and when you click the “Comments” link, the paragraph with the metadata is actually *above* the top of the screen. 😛

    Enough griping–great thread.

Comments are closed.