Managing Web Projects Part II

Continuing the review of J. Rodney Turner's book.

It seems many people who read books ignore the Preface. I'm not one of them, and I don't understand why people skip it. The Preface is the author's personal message to you, dear reader, about their intention in writing the book, and how they intend it to change you, as well as change you into what. Why would you not want to know about that?

Upon opening a book, I go directly to the Preface right after briefly flipping through the pages (mostly to filter out books that use size L or XL fonts). After reading the Preface, then I start to take in the smell of the paper, but let's not go into that.

In his Preface, Turner reveals that this book is the first of a projected series of books on specific applications of project management. Perhaps sensing that he needs to undertake a defense of the need for such a series, he elaborates that although he agrees with the opinion of many, that project management is a generic skill, nevertheless, different types of projects have different needs and therefore require different methodologies.

Comparing project management with other professions, such as medicine, law, and accounting, Turner observes that while these three, like project management, are generic professions, each has its own sub-specialty.

You probably do not want a specialist in corporate-law to defend you in a criminal case (viz. when Sherman's lawyer acquaintance turns him down in The Bonfire of the Vanities). Neither do you want a neuro-surgeon to deliver your baby (Dr. Brown of the Everwood TV Series notwithstanding).

Turner points out some revelations he had while researching and working on the book:

- General managers (rather than IS managers) tend to end up being handed responsibility for delivering web projects.

- Change management seems to be much more important than he initially thought.

- Web projects tend to be managed whole, rather than delivered piece-meal. In consequence, he discovers that techniques like agile management or extreme programming were not as central as he initially expected.

I was initially confused by those observations: why would piece-meal deliveries espoused by agile techniques not be central? Isn't the changing nature of web pages a perfect match for agile software development? And why would change management be important in a web development project where quick delivery is the expectation? Who has time for change management?

Peeking inside, I realised that in the context of the book, Turner was not speaking about simply developing web applications, but also about web-enabling business operations. That is why general management plays larger role. That is why change management is fundamental (not change control management, as I originally thought), and that is why the project tends to be delivered whole.

The type of projects covered by the book possibly makes this book less interesting for technical managers interested in managing web-based software alone, but it does make it more interesting to me.

In the next posting on this subject, we will look at chapter 1.