Realities of web project management

I think one of the most important things here is "...when it all
>starts to unravel (which it does)...". It is not just a symptom of our (relatively) fledgling industry that all these issues arise. Ask a project manager from any industry (engineering, architecture, you name it) how often their projects run into crisis and they will probebly say "most of the time". Anything which requires dealing with human beings (and especially their subjective opinions) will be prone to problems.

So what makes a good project manager? Regardless of what methodology (as long as it isn't entirely useless) often it is as much about how that person handles the issues as it is about how much they can predict and plan against. Having a project with a crisis is not a measure of a good or bad PM but how it is resolved is. This often makes Project managing about people management, crisis management, client management, negotiation/arbitration and solution providing. At times like these a nice MS project plan and a status report just won't save you.

Asking for a person with all these ideal qualities can be a tall order though. (could you just turn lead into gold and cure cancer while you're at it.........and we want it done by monday lunchtime too) but that is why in most industries it is held with high regard as a discipline.

On 12:4:39 18 March 2001 jonathanbriggs wrote:
>I enjoyed reading Ashley's book but felt like some of the
>other correspondents that he portrays an almost ideal
>world in which a project starts with a long discovery
>phase and large teams. At the end of last year it appeared
>that many of the large web agencies were being abandoned
>by some of their clients because of the over engineering
>of the project process; a process in which clients are
>seeing few real results until months into the project.
>
>I have spoken to producers at many agencies in London and
>the tension between 'doing it properly' and 'doing it
>quickly' seems almost universal.
>
>Our industry is made up of professionals from many
>different backgrounds including advertising, software
>development and print design. These industries each have
>their own development methodologies and to a greater or
>lesser extent they all have regular project failures (even
>when these methodologies are applied). Putting these
>industries together into new media has made things worse
>and the idea of a single methodology is proving hard to
>achieve. We just need to look at software development to
>realise that the perfect methodology has remained illusive
>for over 30 years - projects are still often (usually?)
>late, over budget and clients dissatisfied.
>
>I applaud all attempts to provide structure, checklists
>and good practise to our industry (and Ashley has made a
>very useful contribution) but does anyone else feel that
>we still have a considerable way to go?
>
>Until clients understand what is possible, indeed until we
>really understand what works and what makes money, we will
>not really be able to plan most of our projects. Instead
>we should accept that planning is an important step but
>reassure producers and project managers that when it all
>starts to unravel (which it does) it is because that is
>the nature of the chaotic business we are all currently
>still devising.

Some good points in this thread. Yes, theory and reality are very different beasts and web project management is hard, very hard. I would contend harder than most other kinds of project management, largely as it is still an immature art and also because there are just so many variables, so many things to consider, so many different skills to blend, so many different forms and levels of communication to master.

As I say in my book, I think to create a successful web site, the project team needs to combine the skills and techniques involved in:

- software development (requirements analysis, documentation, quality control, testing etc.)
- magazine production and publishing (workflow, content management, editorial skills etc.)
- creating a work of art (the creative processes)
- producing a live TV show (going live, being live 24hrs a day)
- planning and running a commercial venture (try glossing over this in the current market climate...)

There is a whole host of further knowledge in areas such as marketing, contract law, worldwide tax and VAT regulations, security and privacy that the team will also need to call on. So not easy. If every project I worked on ran exactly like I say it should in my book then I would be a happy man indeed. Hopefully the case study in the book gives some taste of the challenges that reality throws up.

A couple of comments in the discussion that I'd like to pick up on:

> "an almost ideal world in which a project starts with a long discovery phase and large teams"

You don't have to have large teams. Often you don't want large teams. Particularly at the beginning of a project I think it is crucial that a small nucleus of experienced people 'architect' the solution on all fronts - approach, processes, people, technical, commercial etc. The discovery phase does not necessarily *have* to be long but it absolutely has to be done and done right. Doing this fast or poorly just does not bring benefits in the mid or long term. If there is no conceptual integrity to the project it will unravel in a nasty fashion at some point.

> "the tension between 'doing it properly' and 'doing it quickly' seems almost universal"

I'm sure it is. It comes back to the 3 fundamentals of project management: time, cost and quality. How do you optimise the balance of these? There are always pressures pulling every way. I would say that 'doing it properly' has to win out though. Fortunately, or unfortunately, depending on how you view it, the current harsh market conditions ('land grab' i.e. speed to market is out, Return on Investment and doing it properly is in), mean that it is now easier not to be forced into 'doing it quickly'.

>"reassure producers and project managers that when it all starts to unravel (which it does) it is because that is the nature of the chaotic business we are all currently still devising"

A little negative to suggest that all web projects *will* unravel, I think. A project manager has to manage risk among other things. A project should not 'unravel' without the project manager knowing how, why and when it is unravelling and communicating everything as it happens to the project stakeholders. If done properly the project manager should never to be blame - he / she can present options and suggest way forwards but the project stakeholders, presented with all the facts, must take responsibility for decisions made.

It does mean that documentation, and an audit trail of decisions made, is very important for the project manager in order to manage his or her own exposure. Have a look at http://www.shorewalker.com/pages/documentation-1.html - an article on the importance of documentation (which also happens to say nice things about my book...). I particularly like this article for what it says about forcing you to do the thinking work (cf. my comments above about requirements analysis).

> "a more evolutionary project methodology is required. We also need to manage client expectations far more while demonstrating quick wins to keep them interested"

I certainly agree that within a maturing industry close communication and evolutionary methods (little steps at a time) are suitable. It is often a learning process for all involved. Managing client expectations is absolutely vital. Managing your own internal team's expectations, is, of course, equally vital. I'd prefer 'proof of concept' to 'quick wins' but, yes, demonstrating that you are delivering value is good for the client and the development team.

> "good place to start might be RAD (rapid application development) or Extreme Programming"

I like the RAD approach. "Rapid Development : Taming Wild Software Schedules" by Steve C McConnell is good on this. For me the key take out from RAD is the importance of close, frequent, open and cross-functional communication. I do think it feels very much like a software development methodology (which it is) and misses out a lot of the other elements that a web project hinges on (like the *content* of a web site for example).

Ashley