"Web Project Management" - what do I think 1 year on?

I actually wrote most of "Web Project Management: Delivering Successful Commercial Web Sites" (if you don't know what I'm talking about see http://www.e-consultancy.com/book/) over a year ago now. Many people have asked me "How might the book be different if you wrote it now?". So here are some thoughts...

- Working practices vs. process

I was recently lucky enough to see the Beta version of a new collaborative web development tool being released by Macromedia (called Sitespring see http://www.macromedia.com/software/sitespring/) and spent quite some time discussing how web development teams work together with Sitespring’s Product Manager...

The truth is that despite processes, frameworks, standards and methodologies it is very difficult to pin down and concretise the day-to-day dynamics of how web sites are developed. If things are being done properly there are a wide range of people from different disciplines and parts of the business involved (a good site touches pretty much every part of a business) and things change and iterate all the time. The working practices of a web project can be quite amorphous and trying to tie them down can be like the proverbial ‘nailing jelly to a wall’.

This is recognised and addressed to a large degree in DSDM, RAD, JAD and XP (extreme programming) approaches though these are really still software/application development focused not web site development approaches (e.g. they don’t talk much about the unique challenges of branding, marketing, content etc.). There is definitely a need for milestones, deliverables, an agreed process, structure and certainly standards, agreed points of reference and a common language (so people can communicate effectively) but the day-to-day working practices are less easy to tie down and structure. And should we worry too much about trying to nail them down too much?

I am all in favour of the kinds of principles and techniques proposed by RAD, JAD and XP type approaches. Close collaboration between all interested parties, especially if this is a small-ish core team of talented people, is in my view quite clearly the best way to produce outstanding results quickly and cost effectively. Such a team communicates very well, has a respect and understanding for each team member's skills, roles and responsibilities are clear, decisions are made fast, quality control is almost built in to the development process etc. Things can really fly.

The problem is that these kinds of approaches can break down if you are dealing with a big organisation which may have a lot of internal politics, may be very process-oriented, where the e-business project team may be inexperienced, where many people involved in the project don’t know (or trust) the others, where team member turnover is commonplace etc. In these cases it is much more difficult to use RAD type approaches and more 'traditional' methodologies (e.g. Waterfall) can be more applicable. They may be slower, more expensive and not even produce the same quality of results, but they are the best way of getting the job done.

So it depends. It depends on the nature of the project – the people, the client, the consultants, the commercial context and potentially all sorts of other things.

However, the importance and necessity of collaborative and iterative working practices surely cannot be called into question. So you need to be structured but you need to be flexible – tough, eh?

I think it can be done and it was interesting to see how Macromedia tried to address this challenge with their new software. Essentially it provided a set of tools and a way of setting up workflow processes but it ‘hardcoded’ very little in terms of what worked with what: each team could choose to assemble its own preferred processes. Is this object-oriented project management…? As mentioned above, I think this works for small-ish teams who work well together but may break down for really big teams.

So if I were writing the book now? I would try and get across this notion of iteration and collaboration even more emphatically, borrowing some of the tools and techniques from the likes of JAD, RAD and XP. The method proposed in the book was only ever put forward as a ‘framework’ to work to and I would stick by this as I would stick by all the more practical realities and observations of what happens, and what to do, at each stage.

- Usability and user-centred development

Maybe it’s the work I’ve been doing more recently on eCRM (electronic Customer Relationship Management), maybe it’s because I’ve been using the web for that much longer, maybe it’s because I’m a Londoner… More probably it’s just that it takes a surprisingly long time for people, me included, to *really* get it in their heads that you have to give people what they want on the web or it they will go elsewhere. Either way, I have come to be an even more fervent fan of usability and customer-centric development processes than before.

Despite being an apparently blindly obvious thing to strive for (giving customers what they want, that is), it is actually a whole lot harder to do this really well – and make money.

I won’t go into all the customer insight, usability and user research approaches now as a) you may well already know them and b) they could be, and have been, the subject of many other books. However, if I were to write my book again now I would place more importance on these elements than perhaps comes across in the original book.

- Interactive supporting content

By this I mean the digital content assets that support the book. In my case these all sit on this site at http://www.e-consultancy.com/book/

It is interesting to look at the number of people who come to the site to download some of the supporting content. Looking at book sales versus visits/downloads it appears that over 40% of people who read the book also then come to the supporting site – a high response rate.
As we (slowly) move towards e-books and micro payments, and as more and more people shop for books of this sort online, I expect this kind of supporting content to become more and more important. Indeed, there could be more money to made from the supporting content than from the book itself. The margins on books are not that high once you account for all the editorial, production and marketing costs. The margins on selling a file across the web, where costs are negligible, are much higher. The number of people who have asked me for template documentation, Gantt charts, budgets etc. is huge and I suspect they would happily pay as much again, if not more, for these than for the book. Could it be that books (non-fiction, trade type books) will come to fill a role more like marketing pamphlets to promote and sell more lucrative supporting assets?

Relative to other supporting book sites, I think that what is at http://www.e-consultancy.com/book/ is quite good but could be a lot better. The documentation, which is what most people are after, could certainly be updated more often, made more complete and more detailed. There are many challenges to making this possible: time (who’s got any?), money (do you get any for doing it?) and intellectual property (can you actually use the content?) are 3 big ones.

I’d be interested in hearing any feedback on my thoughts above… Do people feel things have moved on in web project management? How important is supporting content to a book of this sort and would you pay for it etc.?

Ashley