Register your product to gain access to bonus material or receive a coupon.
Real Web Project Management: Case Studies and Best Practices from the Trenches
- By Thomas J. Shelford, Gregory A. Remillard
- Published Oct 25, 2002 by Addison-Wesley Professional.
Book
- Sorry, this book is no longer in print.
About
Features
A practical, advice-filled guide to the growing field of managing Web development projects
° Shows not just the generally accepted methodology, but also where and how that theory doesn't help in real-world situations.
° The practical handbook approach allows the reader to find immediate solutions to the problem at hand
° The CD and website include valuable project plan templates, model websites, project checklists, consulting contracts, and software vendor reviews
Description
- Copyright 2003
- Dimensions: 7-3/8" x 9-1/4"
- Pages: 336
- Edition: 1st
- Book
- ISBN-10: 0-321-11255-5
- ISBN-13: 978-0-321-11255-2
Web project management is a relatively new and expanding profession. It has developed as people have discovered how different web site development is from traditional software projects. Web project managers are not only found in technology companies or dot coms. As companies of all sizes in all industries rush to integrate the web into their daily business operations, employees are being asked to manage web projects of all shapes and sizes. As veterans of the internet industry, the authors offer detailed solutions to managing web projects. They will present tools and real-world advice on both techniques for success as well as pitfalls to avoid. The numerous examples and case studies are based on their own success at iVillage.com as well as other web sites they have worked on. Rather than presenting a rigid methodology, the authors present a toolbox of tips, tricks, anecdotes, and case studies that will help the reader come up with a Web development methodology that works for him or her.
Sample Content
Online Sample Chapter
How to Manage Scope Change in a Web Project
Downloadable Sample Chapter
Click below for Sample Chapter(s) related to this title:
Sample
Chapter 5
Table of Contents
Foreword.
Preface.
Acknowledgments.
About the Authors.
1. The Project Manager: Who You Are and What You Do.
Who You Are.
The Best Seat in the House.
What You Do.
The Enabler.
Summary.
2. Web Team Roles.
Common Web Team Roles.
The Project Stakeholder.
The Producer.
The Editor.
The Information Architect.
The Graphic Designer.
The HTML Developer.
The Developer.
The Tech Lead.
The Database Administrator.
The Quality Assurance Engineer.
Common Team Problems.
Missing in Action-Become Part of the Team.
The Micromanaging Stakeholder.
Case Study: Startup Breakdown.
Summary.
3. Communication Cues.
Communication: What It Is.
The Unambiguous Information Society.
Translation Skills.
Nonverbal Communication.
Communication: What It Isn't.
It Takes Tact.
Know Your Audience.
Communication Best Practices.
Best Practice #1: Plan to Communicate.
Best Practice #2: The Issue Log and the Change Request Form: Communication Tools for Control.
Case Study: Peeling the Corporate Onion.
Summary.
Interview: The Voice of Experience. Tracy Brown.
4. Defining the Project.
The Creative Brief.
Getting Started with Internal Initiatives.
Project Documentation.
Needs Assessment.
The Project Charter.
The Statement of Work.
Use-Case Scenarios.
Wireframe Mockups.
Content Map.
Tech Requirements Meeting.
Application Flow Diagrams.
Technical Specification.
Project Risk Assessment.
Case Study: Defining the Project with HTML “Shells”.
Summary.
5. Managing Change.
A New Perspective on Scope.
Classic Scope Control.
The Project Web Site-Getting Everyone on the Same (Home) Page.
Managing Scope Change.
The Project Triangle-Scope, Schedule, Resources.
Getting Project Documents Approved by the Client.
Playing Defense.
Problems with Classic Approaches.
Iterative Approaches.
Common Scope Headaches.
Problem #1: I Sketched the Site Out on a Napkin-Is that Okay?
Problem #2: It's Nice, But It's Not What We Had in Mind.
Problem #3: Just One More Tiny Little Change…
Summary.
Interview: Extreme Programming—Alex Cone.
6. The Art of Planning.
The Project Schedule.
Infatuation with Planning Software.
Planning by the Numbers.
The Work Breakdown Structure.
Drafting the Schedule.
Assigning Resources.
Obtaining Approval and Scheduling Work.
Plan (and Pay) as You Go.
Using Your Judgment.
Planning Pitfalls.
Approvals and Revisions.
Copy Editing for Design.
QA Testing.
Prelaunch Review.
Case Study: Planning Software Overload.
Summary.
7. Learning to Love Meetings.
Why Are We Here?
The Agenda Is Your Road Map.
Meeting Pitfalls.
Common Project Meetings.
Kickoff Meetings.
Status Meetings.
Postmortems.
Case Study: The Exploding Meeting.
Summary.
8. Workflow.
Workflow for the Web.
Benefits of Workflow Planning.
Creating Workflow Standards.
Code Review: Standards for Developers.
What Processes Do You Need?
Documenting Your Current Workflow.
Workflow Analysis.
Workflow Recommendations.
Content Production Workflow.
Summary.
9. Managing the Design Phase.
Is Information Architecture the Designer's Job?
Design Production.
Revisions and Sign-off: Making the Client Happy.
Design Production Phases.
Internal and External Design Groups.
The Internal Design Experience.
The External Design Experience.
How Technical Do Designers Need to Be?
Summary.
Interview: The Information Architect Role in Practice—Fabrice Hebert.
Interview: How We Manage Design—David Young.
10. The Technical Build.
Anxiety over the Technical Build.
Mitigating the Fear Factor.
Model-View-Controller.
What Is Model-View-Controller?
A Generic Technical Build.
The Tech Kickoff Meeting.
Infrastructure Configuration.
Component Inventory.
Data Modeling.
Display Markup.
Application Coding.
Prototyping.
Code Review.
Code Review Guidelines.
Production Challenges.
Problem #1: The Designer's Blind Date.
Problem #2: No News Is Not Good News.
Problem #3: “You need Java? Cool! I used to work at Starbucks!”.
Case Study: A Recipe for Disaster.
Summary.
11. Surviving Quality Assurance.
A Common Scenario.
Quality Assurance for the Web.
What Does QA Test For?
Usability.
Browser and OS Compatibility.
Functionality.
Internal Standards.
Performance and Load Handling.
Content.
Security.
How Does QA Test Web Sites?
The QA Process.
Early Quality Assurance Milestones.
The Bug Database.
The Testing Process.
Handoff.
Rounds One, Two, and Three.
The Blessing.
The Politics of QA.
That's Not a Bug, That's a Feature!
Who Needs Code Reviews?
Case Study: Burning QA.
Summary.
12. Getting It Out the Door.
The Final QA Phase.
The Soft Launch.
Launch Deliverables.
Turning over the Keys.
Going Live.
The Launch Moment.
Case Study: The Most Expensive Launch that Never Happened.
Summary.
13. Leading Organizational Change.
The Invisible Team Member.
Common Organizational Structures.
Functional Organizations.
The Functional Matrix.
The Project Matrix.
The Project Unit.
Early Stages of Project Management.
The Project Management Office.
Establishing a Project Management Office.
Case Study: Establishing Web Project Management at a Media Company.
Summary.
Appendix A: Project Quick-Start Guide.
Brochureware.
Business-to-Business Portals (“Vortals”).
E-Commerce Web Sites.
Putting the “E” in E-Commerce.
What Kind of E-Commerce?
The E-Commerce Project Plan.
E-Commerce Nuts and Bolts.
E-Marketing Projects.
The Message IS the Medium.
The Campaign Process.
Conclusion.
International Web Sites.
Internationalization.
Localization.
Back-end Inventory.
Code Cleansing.
Content Management.
Graphics.
Editorial Muscle.
Intranets.
It Doesn't Get Much More Political than This.
Whose Site Is It Really?
Who's Going to Take Care of It?
Features.
You'll Need a Marketing Plan Too.
Intranet Resources.
Appendix B: Technology for the Web Project Manager.
What You Really Need to Know-Frameworks.
Microsoft .NET.
Sun Microsystems' Java 2 Enterprise Edition.
The Open Source Initiative.
Object-Oriented Design.
CRC Cards.
The UML.
Web Services with XML.
Content Management Systems.
Digital Rights Management.
Appendix C: Useful Web Sites.
Recommended Reading.
Index. 0321112555T10042002
Preface
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 would betray 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.
Through front-line experience and during the many interviews conducted for this book, it became crystal clear that the role of the project manager in the Web development industry has come to be considered as indispensable. This is true for both interactive agencies and internal Web development or IT departments; Web project management has become a crucial success factor for a huge variety of organizations. Having worked with many unfortunate companies that lack solid project management practices, we believe that reading this book will be worth your time. Please enjoy it, and send any feedback to feedback@realwebprojects.com.
0321112555P06282002
Foreword
Click below to download the Foreword file related to this title:
Foreword
Index
Click below to download the Index file related to this title:
Index