|Published (Last):||6 January 2009|
|PDF File Size:||2.44 Mb|
|ePub File Size:||4.33 Mb|
|Price:||Free* [*Free Regsitration Required]|
No part of this publication may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopy, recording or any information storage and retrieval system, without prior permission in writing from the publisher.
Introduction Web project managers come in all shapes and sizes. Some have project manager written on their business cards. Nonetheless, project management sounds like a daunting task. Many people think of project management as an annoying overhead cost. And while time spent managing is not time spent designing, coding or deploying websites, it is not time wasted either.
Good project management is all about making sure that you and your team have a better time doing something that you love. If you are a football player, your coach is not an annoying overhead to the discipline of playing football.
The coach helps you train, strategise and execute winning plays. So what are my core principles, as a project manager? Mess with working teams at your peril.
It may be that you have a particular process because your predecessor did, because one of your clients read about it in a self-help book, or because it came to your former boss in a dream. It may or may not actually make any sense for you or for your team, today, with your current technologies and working environment.
What you can expect from this book This book walks through a typical web development project. Internal web teams or design shops, freelancers and large digital agencies all follow more or less this process, though the length of time and documentation required will vary depending on the environment.
The five sections steps of this book are: 1. Beginning a project 2. Analysing requirements 3. Design and prototype 4. Construction and testing 5. The team I describe analyse and consider the requirements for a good website, look clearly at content and audience, do some design, and think carefully about integration and deployment of the finished product.
A note for internal web teams A lot of this book may seem a little odd to you, with all the talk of clients and a clear separation between the delivery team and the people approving the work.
Making things together builds morale and gives your team some of the social support that you need. Even if there is other work going on, thinking of the web team as a unit will help you to see what roles you have covered and where you need more help. This can be a harsh lesson, but by some measures most technology projects fail. Setting a hard deadline for your team and thinking through the project schedule independently of your normal organisational schedule will help you get to done.
And remember: perfect is sometimes the enemy of done. OK, time to get going! He has worked for multinational businesses and IT consultancies as well as a couple of start-up technology firms and design studios, mostly as a technical architect.
Thanks to some great teams, mentors and a little common sense, his projects have generally finished on time and on budget. He has lived in more than ten cities around the world, and now makes The Hague, Netherlands his home. He likes playing traditional Irish music with friends, and has worn geeky glasses since the age of two.
All of the above? Then this book is for you. And it will tell you quite a lot about how to have a better time during the building process, because unless you are extraordinarily lucky, chances are your last web project was a bit of a stressful experience. You might have had a great time at the beginning, only to find out later that things weren't going as well as you thought.
Or maybe you had trouble getting paid, even well after the end of the project. Perhaps the whole project was successful, but it just took more time and effort than you thought it would. If you've had a few bad experiences trying to build websites for money, you needn't be ashamed. You're not alone! The secret to the difference between a lousy web project experience and a really rewarding one is often project management. Here's the thing about project management, and web project management in particular: there is not now, and never will be, a single way to do something — a practical sequence of techniques and processes that will get you out of every jam, manage every client and make any website.
The best project management guide I can give you is a set of rules of thumb, checklists and some guidelines for each phase of work in a typical web project. These are ideas that have worked for me and for web teams that I have worked with. I hope that these guidelines, however familiar or strange, will help to make your next web project even better. Emily and I got engaged in Dublin, Ireland. That night is one of the fondest memories I have. This book is a pragmatic, hands-on guide to the process of making websites.
Like many books about web project management, it describes the myriad of steps that can be combined to conceptualise, create and launch a successful website.
Successful projects are a unique blend of the right people, clients, and processes. Those mixes are often difficult to replicate, and a great project manager can balance the need to be flexible and efficient, traditional and innovative, in order to establish a winning track record.
This book goes into great depth about a plethora of techniques that are necessary to truly achieve excellence on a web project. I didn't propose on our first date. When we got engaged, Emily and I had been dating for four years and had been friends for eleven years. Web projects are similar to relationships, in that they require time and trust to grow into something beautiful.
Once you've read through, I have no doubt that you'll have the right tools to build that trust and watch it turn into something wonderful. Happy reading! Creating strong briefs and proposals, and estimating the scale of a potential project are also here. Once the bid is won and your team is geared up, this section will also give you tips for planning an effective kick-off, workshops and project communications.
These are great goals to have. But there are also subgoals that vary a bit depending on exactly where you are in the business of making websites. President Ronald Reagan had a plaque on his desk with a variant of this quotation. Estimating, therefore, is something that you have to do really well. Given economic constraints, your main task is to keep the site design and build as efficient as possible. You need to make sure that every bit of work you do contributes to a deployable website that meets the requirements of your project.
Either way, efficiency is going to direct much of your action during the project. You get to take a strategic view of the project, which can be a mixed blessing. And that can be a bit scary to think about. You may be worried about the elapsed time for the project: you might have other marketing or communications activities with which you need to tie in; you might have major events sponsored by your organisation coming up; you might need to think about how your brand values are being expressed in relation to those of your competitors, and in a competitive situation there may well be a first-mover advantage.
Not all management teams realise exactly how crucial the web is to their business, or how much the internet has increased the value of information processing and information dissemination within their field. But they will. The actual efficiency of how time is spent matters less to you than whether the work being done will directly support the larger goals of your organisation.
The agency will certainly know those goals or at least it should , but it will be your job to keep the project focused on delivery.
And website commissioners should be aware that agencies are under a different kind of time pressure: not the pressure of being there first, necessarily, but the pressure to ruthlessly cut any scope that can be done without, to build a quality website within a fixed budget. Agencies need to be efficient with their time, and focus on accurately doing work to meet the brief.
Website owners are focused on effectiveness, and making sure that the work done will support offline goals, including those never articulated in the website requirements brief. An obvious distinction, perhaps — but worth keeping in mind, for everyone.
Waterfall A waterfall model is what most people think of when they think about project management not that too many normal people spend a lot of time pondering such things. The idea is so attractive to organisations because it promises predictability and stability. With each phase distinct, you have a chance to involve all the right people in the review. You can create documents that clearly express the concepts and analysis of your designs, and you can get agreement on each step before moving forward.
The classic waterfall model is derived from the project management used in the construction industry, where each step needs absolute agreement so that the proper materials and services can be ordered. Many software consultants over the years have clung to the waterfall model as a way of shoring up management support. The theory is that you can pin down the business stakeholders by making them commit in writing to a description of exactly how the system will work, thus making it impossible to change minds later on.
Even when the conception, initiation and analysis phases are all done in one chunk and documented carefully, the beginning of the design-construction phase inevitably creates changes in the requirements of the system. But since the analysis phase is already complete and no more effort is planned, the typical result is that requirements are changed only implicitly by changing the functioning of the system, and the requirements documents themselves are left to slowly obsolesce.
What could be simpler? Of course, the devil can be in the details. And of course, there are very few designs, however wisely created, that long survive contact with users. It is the rule rather than the exception that there will always be problems with. Variations on the waterfall model abound. Drawing a series of boxes or wedges with arrows between them gives a settled, repeatable process, and helps to justify the time to be spent in each phase. At best, you and the client will both create a detailed, static requirements document and then be willing to ignore it as the design evolves.
The Rational Unified Process4 When I first started working on software projects, the Rational Unified Process was the gold standard of sorts, and still enjoys a lot of popularity. The process RUP to its friends combines aspects of the discrete and the iterative, allowing for an overlap of phases and for multiple iterations within each phase.
RUP makes a distinction between public and internal releases — you can keep going with a completely iterative process, but show your stakeholders only your finished work. RUP is structured as a series of suggestions, a box from which you can select the tools that you need for each part of the job. RUP covers team roles and what each role might be responsible for. It offers deliverables documents, mostly for each phase of work.
Practical Guide Managing Web Projects by Breandan Knowlton
An Aran Reader by O. Be the first to write a review. Please note, the image is for illustrative purposes only, actual book cover, binding and edition may vary. You may pay for your items using credit or debit cards or other payment methods, under the discretion of eBay. The contract for sale underlying the purchase of goods is between us World of Books and you, the customer.
A Practical Guide Managing WEB Projects
Goodreads helps you keep track of books you want to read. Want to Read saving…. Want to Read Currently Reading Read. Other editions.
A Practical Guide to Managing Web Projects (Practical Guide Series)
Published by Five Simple Steps Ltd Seller Rating:. Condition: Good. Former Library book. Shows some signs of wear, and may have some markings on the inside.