Top

Amazon no longer offers textbook rentals. We do!

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

by: Shelford, Thomas J.; Remillard, Gregory A.

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

by: Shelford, Thomas J.; Remillard, Gregory A.

ISBN 13:
9780321112552
ISBN 10:
0321112555
Edition: 1st
Format: Paperback
Copyright: 10/25/2002
Publisher: Addison-Wesley Professional

Rent

Sorry, this item is currently unavailable.

Free Shipping On Every Order

Note: Supplemental materials are not guaranteed with Rental or Used book purchases.

Extend or Purchase Your Rental at Any Time

Need to keep your rental past your due date? At any time before your due date you can extend or purchase your rental through your account.

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

Summary

The authors show not just the generally accepted methodology, but also where and how that theory doesn't help in real-world situations. This 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.

Author Biography

Thomas J. Shelford is a partner in Project Calibrate™, a consulting group specializing in Web project management training (http://www.projectcalibrate.com). He began his Web-related career in 1996 as the founder of SeaState Internet Solutions, a freelance Web development shop.

Gregory A. Remillard has been a project manager on large-scale Web development projects for five years. He has managed projects for diverse companies such as Gruner & Jahr USA (Parents.com) and UrbanExpress.com (formerly UrbanFetch.com). Greg is a founding partner of Project Calibrate™ (http://www.projectcalibrate.com).

0321112555AB09172002

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

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

Like many of our fellow 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 responsibilities. 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 management 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 project management, a dark, uneasy feeling entered the pits of our stomachs at the kickoff 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 traditional project management methods, the more frustrated we became, and the more chaotic 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 minibasketball 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. Knowing when or how to implement overengineered or seemingly inapplicable project management techniques like "force field analysis" or "interrelationship digraphs"caused us to second guess our approach to the "science" of project management. We needed techniques and processes we could implement NOW that would garner us the greatest results in the shortest amount of 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 way there. Basic p