I love good coffee and I love good cafés. When I’ve the time to do so, I’ll spend hours in a café, thinking and writing shite like this. I prefer to order many regular-sized coffees, rather than a few large ones. This is because no matter the size of the coffee, the speed with which I drink it and the rate at which it cools stays the same, which leaves me with an unpleasant drain of cold coffee at the end. The same happens with large projects.
Humans will be humans
Long planning and development cycles, status reports and presentations and meetings, handover documents, signed approvals, user acceptance tests, focus groups. By the time long projects come to a close, a few human factors tend to kick-in:
- monotony leads to de-motivation,
- bored minds stop having new ideas,
- stifled creativity breeds mediocrity.
Change happens
Long projects with waterfall-style plans also suffer because they assume the world stays the same throughout the course of the project. A web app, for example, launched in September 2008, tested in June 2008, built in March 2008, designed in December 2007 from wireframes approved in September 2007 based on business requirements agreed upon in June 2007 will already be out-of-date. (And if you think that’s unrealistic, you’re fortunate to be unacquainted with the sad, real world of corporate / enterprise / government web projects.)
The solution is agile
Long projects go cold and the end result is usually below-par (in quality of implementation and solution) and dated (in technology and business requirements). The alternative is short, bursty, bite-sized projects that cut to the chase and allow for rapid iteration. Most people call this agile and at Contrast, we try our best to run our projects accordingly. Sure, we have separate planning, design and build phases, but we aim to keep them short and sweet and affordable and efficient. Clients get great results early and cheap, with time and money left over to make changes after they test their new sites in the field. Next time you plan a project, take the budget, time and scope, cut them in half and get to work and finish something before it goes cold.
The solution is Contrast
If you need some quality web software built and don’t want to wait until 2010, please give us a call.
5 Comments
Umm, there’s a saying: when the going gets tough, the tough get going. There’s gonna be grind. It won’t be fun.
The difference between something masterful and something a bit slapdash is the sheer amount of time it takes, and the amount of planning and revision to the plans.
The web is no different.
Basically what I’m trying to say is the tough drink their coffee hot or cold.
Posted by da bishop at 12:10 pm on 12 September, 2008.
da bishop: Definitely true, but like I said, humans will be humans. When there’s a great amount of people involved, it’s much harder to keep things going strong when a team are worn-out and demotivated. It’s far less risky to go agile and get results quick and then iterate.
Posted by Eoghan McCabe at 12:17 pm on 12 September, 2008.
My experience in industry is that the most successful project life cycle involves the amalgamation of long term project plans with agile approaches to component parts.
You can easily spec out a long term project, break it down into abstract layers and then adopt an agile approaches in how you develop the distinct sections identified in each abstract layer. These distinct sections should be created in such a way that they are goal orientated and have their own tangible end point and output. Small, goal orientated tasks are by far the best way to maintain motivation in my own experience.
I agree with you that long projects go cold, but I only agree if we add the caveat that long projects go cold when long projects are planned as single task jobs. I would also say that when we use the phrase “long project”, the word long does not refer implicitly to time.
My point is, a 3 week project or a 3 month project can equally be classed as “long” if they are defined unnecessarily as a single task job.
Posted by Keith Redmond at 12:45 pm on 12 September, 2008.
On the whole “world staying still” aspect of waterfall, I totally agree. Even the most rational, sound minded clients will still got nuts if their competitor adds a fancy widget. At that point it’s waterfall out the window, and it’s all about what the competition have got.
The other frustration I’ve seen is the duration between “here is how it will look” (png file) and “here it is built ready for testing” usually allows people to fall out of love with aspects of the application/site/graphics/content/etc.
Posted by Des at 1:09 pm on 12 September, 2008.
I think that this comes from the 37signals blog: Launch quickly - because it’ll force you to finish the damn thing, and mistakes are quickly identified in a live environment, which may lie floundering in a development environment unseen.
Harder to do than to say though … I’m currently involved in a project that fits the ‘business requirements’ in June 07, launch in Sep 08, almost perfectly. Of course, it would fit perfectly, but it hasn’t launched yet.
I ‘flipped the switch’ on this one a while back!
Posted by David Horn at 1:42 pm on 16 September, 2008.