|Managing Web Projects Well|
By Alan Zeichick
The process of developing a public-facing Web site is quite different from the process of building an ordinary applicationand in many ways, much harder. Thats contrary to many development managers instinctive opinion. Youd think the fact that the client environment is predefined and that communication uses well-known protocols would make the application a breeze.
But its not just the technology that makes Web development tricky. A project manager has to manage very rapidly changing requirements and accelerated schedules set by a jittery line-of-business department that is not used to interfacing with the IT department, as well as deal with artists, writers, editors, lawyers, brand specialists and other professionals who are not involved with the software development process.
Ashley Friedleins well-written book Web Project Management bridges the gap between general project-management titles and the plethora of purely technical books on Web site design and implementation.
Although in some areas his book could use beefing uphe barely talks about how the project manager should guide the process of determining the sites functional design and technical underpinninghis advice would be of value to a development manager new to the Web site management process and not sure exactly of what needs to be done, or in what order.
Friedlein, who worked as a video producer before venturing into the Web world by building content-heavy sites for such clients as the U.K.s Channel 5, correctly views Web site creation as a project-management challengenot as a technical issue. You wont find arguments over ASP vs. JSP or whether Apache or Netscape is the better Web server. Thats good. There are plenty of other venues for those debates.
Instead, he focuses on the project itself.
Early in this extremely readable book, he breaks the Web development process into four major phases: preproduction, production, maintenance and evolution. The preproduction and production phases are each broken into three smaller work stages. These ten steps, reminiscent of the waterfall model, are well defined in the world of video production; although Friedleins terminology isnt a usual part of the software development lexicon, these phases map well into the world of Web site management. Most of the book is spent working through each of these ten areas in detail.
While reading the book, I found my head frequently nodding in agreement. Its common knowledge, for example, that a successful Web project requires a high-level sponsor within the organization, preferably at the top of the executive org chart. Yet how many initiatives fail because they never achieved that backing? Far too many, and Friedlein hammers that point home.
He also brings up points that a technology manager might not consider, such as tracking down a corporations branding guidelines early in the design process and not after a prototype is rejected by the marketing department.
Because Friedleins emphasis is on content-rich sites, he understandably places a lot of emphasis on content creation and gathering. He urges managers not to take the clients promise that yes, we have lots of content in easily accessible formats at face value, but to also acquire samples of files and test database access methods, and test to ensure that the data is, in fact, in a format that can be readily processed.
Its also important, he says, to determine the project managers role in the content. Will the project manager need to hire writers? Who will enforce deadlines? Who will edit material for grammar, relevance and style? Who will determine the style, for that matter? Friedlein pragmatically suggests that, where possible, the client interface with the creative talent, so that if something goes wrong, its not the Web project managers fault. Thats the voice of experience talking.
I wish Friedlein had more advice for project managers seeking to pin down the functional specification of the Web site. He does advise that its best to be very detailed, to prototype early and often, and to make sure that the client signs off. But what if the line-of-business managers or corporate executives who are paying for this Web site have no idea of how the site should work, or what the user experience should be (other than Make it like Amazon.com, only profitable)? Id like more suggestions as to how a Web project manager can create a solid site design, and then a technological architecture, under those frustrating circumstances.
But the devil is in the details, and that is where Friedlein excels. In each of the ten major development phases, he covers all the basesand hes certain to mention items that even a moderately experienced Web project manager will overlook. He has obviously been burned by browser incompatibilities, for example, and he provides some general ammunition to help Web project managers defend the need for thorough testing to a client who becomes antsy.
Who should read this book? Technical managers new to the Web, particularly those used to the more mature and cut-and-dried world of software project management. Its a different world, where the technological problems are the easy ones.
Reprinted with permission of SDTimes. Originally appeared in Issue 24, February 15, 2001.