21 Spot on

I am going through this right now… and it is spot on, lesson learnt!!

posted at 12:34 pm on April 18, 2004 by John

22 Well wicked

I have just about finished a job for my first ever client, wishing I had read this 6 weeks ago.

sweet article, nifty diagrams

posted at 02:27 pm on April 18, 2004 by Richard D. Bartlett

23 Well Said

I think you’ve hit the nail on the head with this! I have discovered that feature creep is the number one problem with any programming/web design project. Having the scope clearly defined and agreed at the outset is the only way to make a project work.

Thanks!

posted at 09:17 am on April 19, 2004 by Peter Holloway

24 Request For Change

Someone asked how to say no to the client when each change viewed as an individual change is actually quite small. They are right to worry about this because the client wont see the bigger picture, and doesn’t understand that all these ‘small’ changes pile up.

A very wise person (I forget who) told me that the best way to get them to see the small changes pile up is to get them to follow a vigorous RFC (Request For Change) methodology. Make them fill out a form to be submitted for aproval, and if the change justifies it, set up a meeting, for EVERY INDIVIDUAL CHANGE. This way, when they are filling out the form for the 20th time that week, they will get some understanding of how these changes are piling up.

If you make them do some paperwork for each change, they will see the paperwork pile up, as we see the code to be produced get more and more complicated.

I hope this helps.

posted at 10:19 am on April 19, 2004 by Phil Baines

25 The Curse of Small Projects

The problems outlined in this article and the comments are compounded with very small projects. The overhead of producing a requirements document with an adequate level of detail for a small fixed-price project dwarfs the actual development time.

This “up front” time causes problems for inexperienced clients who “don’t want to pay for process, just results”. Some clients balk at the concept of paying to scope the work formally because “they already know what they want” (even when they only have a broad sense of what it is that they really need).

Currently we treat very small projects as loss-leaders. Most methodologies that we have used do not scale down well. If anyone has a methodology for producing highly detailed requirements for micro projects (less than 5 days total delivery time) please follow up.

posted at 12:28 pm on April 19, 2004 by Geoff Waddington

26 Iterative Development

I understand the problem you’re describing, but I’m not sure I agree 100% with your solution. Certainly, a scope of work needs to be defined and requirements need to be gathered and analyzed, but I don’t agree that 75% of the total work needs to be accomplished in the initial discovery phase.

I think what you’re saying is, “Spend extra time on requirements and scope, then lock it down and produce the product.” If that’s correct, then a basic assumption that (I think) you’re making is that the project team will follow the traditional “waterfall” style of development. Newer, iterative styles of development not only reduce the cost of change, but allow flexibility to such an extent that change is not only tolerated, but embraced.

The fact is, changes occur during every project. Iterative development simply relocates most of the change to earlier stages of development, where the change is least expensive to make.

I won’t go into the details of this type of development, as it’s covered in detail elsewhere on the web (a great recent article on this is at http://www.oreillynet.com/pub/wlg/4691). I can tell you, however, that I’ve been using it for the past 3 years, on projects ranging from site redesigns to full-scale e-business implementations. It almost always results in a better product being produced more efficiently, with less cost.

posted at 02:36 pm on April 19, 2004 by G Jones

27 There are ways around this

I like the honest approach, but it tends to ruffle feathers, and may make your client contact look like a dunce in front of other stakeholders if they aren’t 100% honest – which you have little way of knowing.

A bit of a shameless plug, we use a tool called INSPIRE, which we developed as a project management/asset approval/web collaboration tool for not only our web projects, but also for managing video production, animation, and audio. Check it out at http://www.epicsoft.net/inspire

posted at 04:08 pm on April 19, 2004 by Dana VanDen Heuvel

28 Iterative Development - Another Fan

I agree with G Jones: iterative development allows you to keep gathering features for the ‘next version(iteration)’ while keeping the current one on track. Deadlines are met, avoiding developer frustration, while requests are planned in, avoiding stakeholder frustration. It’s also very good for sales, as long as your pricing is hourly based, or at least a bid for the ‘first version’ (defined in advance) with hourly-based pricing for future iterations.

posted at 08:33 pm on April 19, 2004 by JoeH

29 Sometimes client expectations aren't the problem

Over the past decade I’ve worked for companies whose management was more responsible for scope creep than the clients. Whenever a client — or worse, someone who hinted that they would maybe possibly sorta kinda consider sending some business our way, maybe — would even hint that something may be needed down the line, that “something” would immediately become a priority #1 addition/enhancement/revision to our products and would de-rail the development cycle. This never ended the entire time I worked at these companies (unfortunately they were all related as the later ones were spinoffs from the original. Inept, inexperienced management always followed us).

We were in the business of developing software, not web sites/applications, so perhaps none of this applies to the current discussion. I suspect at some level it does, though. I’ve always found clients to be much more reasonable than my company’s management. Perhaps it’s just me.

posted at 05:58 am on April 21, 2004 by erat

30 I agree with erat

My own management seems to be the major issue. Clients are generally open to new ideas or “best practices”, but my management seems to be in a constant struggle with the designers/developers to remain in “control” of every project. It’s as if they regret having “experts” on staff.

posted at 07:33 am on April 21, 2004 by David Hosting