Real Web Project Management: Case Studies and Best Practices from the Trenches

0
499

Like many Web project managers, we came to the role—or rather the role came to us—suddenly and somewhat unexpectedly. Without really knowing it, we had been preparing for the role through our individual professional experiences for some time. We were familiar enough with the project lifecycle to be able to distinguish one end of a project from the other, but the more refined aspects of project management were as yet unknown when we assumed our new responsibilites and were charged with delivering two important projects. It was time to discover just what project managers actually are and what they actually do. The search for knowledge began with Yahoo! At the time, our search turned up only a small handful of Web sites devoted to project management, but nothing Web-specific. We did discover the Project Management Body of Knowledge® (PMBOK®) from the Project Management Institute (PMI). PMBOK, and other project management books, taught us basic, traditional project managment processes and methods that had been used in other industries for years. We felt reassured with this newfound knowledge but at the same time a little uneasy because we still could find nothing specific on Web project management. “That’s all right,” we thought. “A project’s a project, right?” As we set out to mimic our colleagues in the more mature branches of software development, a dark, uneasy feeling entered the pits of our stomachs at the kick-off meeting of every new project. Somehow, in spite of everything we had recently read about process and methodology, we knew we were going to end up doing the one thing we felt sure wouldbetray the very premise of project management . . . wing it. The disconnect between the correct process and what happens in real life has been a source of growing unease among Web project managers. For a time, many people explained away the problem by pointing to the inexperience of the industry. It was assumed that once traditional software development processes and best practices were understood by immature Web professionals, the chaos would subside. Well, not quite. As we gained more experience, project by project, we discovered that the harder we tried to adhere to the use of the tradtional project management methods, the more frustrated we became and the more choatic the atmosphere seemed. How do you hit a hard-and-fast completion date when the specifications for the project are changed and expanded daily by the very person who is mandating the completion date? In your project plan, how do you account for the time your star developer spends getting in the mood to work by shooting mini-basketball free throws for a couple of hours, followed by a donut run, and then a few quick games of UNO with the graphic designer? This was our reality. Learning overengineered or just plain silly project management techniques—”force field analysis” or “interrelationship digraphs”—did not seem like the best use of our very limited time. Because of the continued rapid growth of the Web; the constant changes to the technologies that support it; and the frenzied, media-driven expectations and mythologies that surround it, developing Web sites using only traditional project management methodologies adopted from other industries just was not enough to get the job done. Many traditional methodologies rely on the existence of a fixed scope and clear, measurable objectives. Web site design and development, however, is not like building a rocket or releasing an off-the-shelf software product. Web teams must collaborate in a continually unfolding creative process, which is often more of an art than a science. Traditional methods will get you part of the way there—basic process building blocks can be used with great success and should be. In this book, we demonstrate some of the basic methods as they relate to Web development. But, we also demonstrate where traditional methods fail and tell you how the ability to improvise, and think on your feet, will serve you far better than a painstakingly constructed Work Breakdown Structure or Gantt Chart. It all boils down to this: There is no accepted, proven, documented, or foolproof process for developing Web sites or Web applications. You use what works, and what works you glean from experience. We certainly don’t think we have a patentable method; however, we do have a lot of experience and do know what has worked for us and peers in the industry. Our Approach In writing this book, the goal was to spare the new project manager the pain of learning project management theories, processes, and terminology that would serve only to confuse and frustrate when applied to the Web development arena. We wanted to chronicle our experience and describe the methods and processes that have worked by showing them at work in real-world situations. From the moment we embarked on this project, we decided that the best approach to recounting experiences was to be as lighthearted as possible without undermining the point of the lessons. We are the first to admit that project management for the Web, or any industry for that matter, is a pretty dry topic. We hope that a little humor mixed into the content will keep the material engaging. Experience as project managers has taught us that the one thing you need to maintain is a sense of humor—without it you will lose the ability to lead effectively. Not only that but your life at work will be tedious. By the same token, why should reading a book about your profession be just as tiresome? Simple answer: It shouldn’t. The Use of Case Studies and Interviews What’s the use of a lot of theoretical mumbo jumbo without some illustrative material to prove or disprove the theory? In our early search for project management knowledge, we read many books that were long on theory but short on examples of real-life application. We wanted to see an example of a “force field analysis” in action. More to the point, we wanted to see an example of a “force field analysis” in action on a Web project gone completely awry with only two days to go before launch. While working our way through project after project, we discovered traditional methodologies that worked and many that did not; other methodologies could be tweaked to fit into the Web environment. After a couple of years, it dawned on us that the hundreds of email threads, scope documents, and project plans we had drafted contained our own project management body of knowledge. The basis for this body of knowledge was experience—the real-life projects we had managed. As we interviewed colleagues and peers in the Web development industry for this book, we were provided with more case studies and stories that could be used to illustrate project managment methods. Similar to ourselves, we found that the experiences that resonated the most with colleagues were not the huge successes but the dismal failures. To be truly helpful and instructive, we have chosen to publish case studies and interviews that illustrate things that can and often do go wrong during a Web development project. In order to avoid any legal difficulties from sensitive corporations and their attorneys, we have fictionalized some of the stories recounted here and changed the names to protect the not-so-innocent. But be assured, the stories herein are all based in real-life events—we couldn’t have made some of this stuff up if we tried. Who Should Read This Book This book was written for people who are new to the project manager role in the Web development industry. Real Web Project Management will provide those of you who come to the role from more vertical expertise, such as programming or design, with an introduction to the world of Web development from a manager’s perspective. (A manager with a lot of responsibility and very little authority, we might add!) We also hope the book will provide a resource for fresh ideas and inspiration to veteran Web project managers who may recognize themselves in some of the case studies and situations described in this book.