April 04, 2004 | View Comments (28) | Category: Project Management
Summary: Managing change in your projects.
When I mentioned there is a difference between software project management and web site project management I was not necessarily talking about the actual methodologies that should be followed, because in many cases web project management is the same as it is in other industries. However, the dynamic aspect of the web helps to differentiate it. The web is in a constant state of flux. What the web looks like now and how individuals interact with websites will more than likely differ 15, 20, 25 months from now.
On the web, client's (or project sponsors for larger corporate projects) think that changes to any project are easy to implement and that you can swiftly change direction. This happens to small freelance designer sites to large corporate sites. As the project manager it becomes your responsibility to manage this change. An example of an "easy change" is adding a shopping cart button and give the customer the ability buy items from one page.
In most models of software development scope is a fixed entity that can be clearly defined at the beginning of the project. If you try to take this approach with web development you may encounter some problems. Obviously this is possible to do with small sites, but with larger sites you are bound to run into greater issues due to web sites constantly evolving because of technological or business reasons. When looking at scope from a web project management position it is important to view it as an organic entity that has the ability to grow and change.
At the beginning of the project the scope definition serves as a contract between you and the client. This is where you agree on the features of the site that you are going to build. The key here is to clearly define what you plan on delivering to the client and to gain their consent before implementation begins.
A trap that many designers fall into occurs when the client ask to see some comps of the design that they would do for them. Then after seeing the comps, the client begins to suggest some changes. This "pre-process" itself turns into a project. I think it is okay to do comps for clients, but I think you have to charge just a little more than your rate to do them.
This is the time where good project management software comes in handy. Too many times specifications, guidelines, or other important documents are not properly maintained during projects. It is key whether the project team consists of one person or 20 people that their is a central location where all members can access the project's documentation. If you have the time I recommend setting up a free account on Basecamp and toying with it. If anything it will give you a better feel for some of the issues involved in project management.
This is where the problems occur. In any project that I have been involved in the headaches always come from changes in the scope. Changes brought about by the client. The key here is communication.
It is important that you communicate to the client that their is a direct relationship between the scope, the schedule, and the resources that you have. If you change one, it effects the other two. The client has to be aware of this so that they understand that asking for a change should not be made on a whim. Once they decide to make a change they must also communicate to you which of the three "legs" they are willing to adjust. Changing one has an effect on the other two.
Whenever there is a change in the scope of the project you should require the client fill out a change order request. This should not make you seem inflexible to changes to the project, but help the client understand the reprecussions of making changes to the project, be it large or small. The purpose of this requirement is to manage expectations and costs. Once they have to fill out a form describing the changes they want they begin to get a better feel for how they are effecting the project's schedule. One small change seems like nothing, but get them to fill out a form 20 different times and they begin to see how these small changes are piling up.
Again this is a problem for all designers. Client's will always try to get that little something more out of you. No problem. Just make sure they know that changes equal changes in schedule. Changes in schedule usually equal changes in price.
Managing change in a project is a large topic and I have many more thoughts to share on it such as project documentation, setting timelines and specifications. However, this is an entry, not a book so I will take a break here.
Trackback URL: http://9rules.com/cgi-bin/mt/mt-tb.cgi/196
FYI, you may want to consider attending The Building of Basecamp workshop. We'll take you behind the scenes and show you what it takes to launch a new web-based application -- from an idea on a napkin to launch and beyond.
Jason Fried (http://www.37signals.com)
I have been putting some serious thought into attending Jason. It would make my job decision easier if free passes were involved :-P
Scrivs (http://www.9rules.com/whitespace/)
Hmm... in chicago? I'll have to run that by my boss, I'm in South Bend, that's only a couple hour drive for us.
JC (http://thelionsweb.com/weblog)
"...An example of an "easy change" is adding a shopping cart button and give the customer the ability buy items from one page..."
Err...You must be referring to sticking a Paypal button on the site only?
Mark Fusco (http://www.lightpierce.com/ltshdw)
Excellent start on this subject Paul. Couple of points (which I'm sure you'll cover in one form or another in entries later).
Be proactive as much as possible. Make sure they are fully informed of your process ahead of time. For example, give them the change request form ahead of time. The less surprises, the less likely friction will occur.
Use the KISS method. If you don't have a simple process, don't expect the client to understand it. Your basic process outline (and where the client needs to sign off before continuation) should be simple enough for a child to understand.
Communication is key as you said. Keep the client informed of where you are every step of the way (either via emails or via a project site). If work has stopped because the client hasn't given you their content yet, make sure this is as plain as a crashing meteor hitting earth. At my last employer, I found it hilarious when a client wondered where we were in building their site when they hadn't even given us their content yet. Uh, hello!?
Bottom line is that while yes you are there to help the client, they need to realize that their actions will have consequences that can severely alter the life cycle of the project.
As a side note, I've found that comps can take a huge cut on the project timeline. The main reason for this I've found is a lack of client direction. Don't worry, I'm not dumping all the blame on the client here. If you don't ask the right questions, then how are they going to know what you need. The firm that I worked for would regularly give our designers one paragraph creative briefs to start working with and I would just shake my head when I saw them. Also don't ask vague general questions like "what kind of site do you want?" Because more often then not, you will probably get back "just make it cool". This was a running joke of mine in building sites for the computer gaming industry because that was a typical initial response from clients. "Just make it cool!" Guide and refine your questions so that the answers step your towards a focused direction that the client wants to go in instead of just a vague idea of what they want. In addition, ask your clients to give you anything and everything that they can give you from their existing marketing material (if they have anything). There is nothing worse than coming up with three comps for a client to look at, only to find out from them that they don't like any of them because they don't contain the color blue (which is a major color of their marketing material). And yes this actually happened with one of sites we were building. I think it was for the game Ground Control. Hilarious and sad at the same time. Hello! Please give us as much information as you can! :)
Nollind Whachell
Mark -
I think he meant what a client would consider an "easy change"
JC (http://thelionsweb.com/weblog)
Well, I certainly hope so. Since Paul's stated that he was, or is...uh, or wants to be...a PM, I wasn't sure from the way he wrote that comment if he was coming from the mindset of the PM who truly believes e-com is that easy, or from the mind of the developer whose head explodes when he hears something like that.
Mark Fusco (http://www.lightpierce.com/ltshw)
Mark: From the developer whose head explodes and from the PM who understands the annoyance that he is going to cause his development team.
Scrivs (http://www.9rules.com/whitespace/)
Scrivs, nice post, again. I'm really enjoying learning off everyone here. Good stuff!
About request forms; has anyone got a good example of a request form they would use? And how would the client submit it? Or would it be a good idea to host a form on your website for clients? It could then email the information to you, or enter into a database.
Sorry for all the questions. I really like the way this discussion is going.
Nollind; that was a great comment. If this was Slashdot it would be +5 informative.
phil baines (http://www.wubbleyew.com/blog/)
I have to run to a meeting, but here's a quick link for some supporting info:
They have chapters all over the world and (I think) are the recognized source for PMP certification.
Matthew Oliphant (http://usabilityworks.typepad.com)
Matt: You’re right; I’ve never met a project manager that isn’t certified via PMI.
As for the rest of the post, great stuff. Something else that you can do to really bring the point home for clients who want change (if you actually “meet” with them and have a laptop available) is to open up MS Project and show them graphically how their change will affect the project timeline and budget. Seeing the dollar amount change right before their eyes may cause them to think more about what they’re doing.
Vinnie Garcia (http://blog.vinniegarcia.com)
Paul -
Maybe I'm just tired from a week full of 16 hr days or I'm just not getting what you're trying to say here, but a PM who would say "just addd a shopping cart button..." is saying that out of ignorance to the complexities of e-com development.
Developer's know it's more complex than that, that's why they get frustrated by PMs.
So, if you're approaching the project as Developer / PM or as a PM with Developer experience, why would you approach your development team with a statement of ignorance?
Mark Fusco (http://www.lightpierce.com/ltshw)
Maybe I'm just tired from a week full of 16 hr days or I'm just not getting what you're trying to say here, but a PM who would say "just addd a shopping cart button..." is saying that out of ignorance to the complexities of e-com development.
Mark, I believe Scrivs was talking about the client thinking that adding a shopping cart button is “easy”, not the project manager. If the project manager says that, then yes, he/she is ignorant to the ways of web-based project management and should probably go back for retraining.
Vinnie Garcia (http://blog.vinniegarcia.com)
Ok, I see it now. I apologize for the interruption.
One additional rule of effective project management is to make sure you schedule in sleep for your team.
Back to your regular programming...
Mark Fusco (http://www.lightpierce.com/ltshw)
Speaking of change orders: Here is a decent list of the aspects of a change order. Another point on communication: share this form at the beginning of the project.
Matthew Oliphant (http://usabilityworks.typepad.com)
If a PM doesn't have even an iota of knowledge with regards to building a web page (even at a really basic beginner level) then I think they will only make things worse for their development team. Reason being is that yes they will do exactly as mentioned above, approving changes that the client wants (thinking that they can be done) and then expecting the development team to deliver (when they actually can't). Take note though that this doesn't mean they are going to be a great project manager for web development either. It just means they will hopefully know what can and can't be done (i.e. the limitations of the Web).
From my experience in the past, I got a lot of tasks from project managers that didn't make any sense whatsoever because they weren't aware of all the task details. Which means yes they would pass on a task to do without full knowledge of what that task involved. Where is the project management in that? The one project manager we had though learned over time to question us if she was unsure (i.e. "How much time will this take to do and what will it involve?"). I didn't mind this, as I'd rather get asked for advice then asked to do something that made no sense (and forced to do it within a small unrealistic timeframe). A lot of times I think people are just afraid to appear as though they don't know about what is going on. In reality, most big companies I've dealt with are flying by the seat of their pants anyways. There is nothing wrong with asking, if you don't know something. There is everything wrong with assuming you know what is going on, when in fact you know you really don't.
Nollind Whachell
At the beginning of the project the scope definition serves as a contract between you and the client. This is where you agree on the features of the site that you are going to buildFeatures. At the beginning of a project. Yikes. Whilst I agree that at some point in the project the scope will be defined as a list of features, I would advise that the scope at the beginning of the project, ideally, would not resort to feature definitions.
Why? Because at the beginning of a new project, it is highly unlikely that you, or the client has anything other than a vague notion of what they want to achieve. For example, the client is likely to be thinking 'I want to sell stuff over the web' or 'I want to market my company with a website'.
Because of this vagueness, it is likely that no feature list could instantly capture what functionality can enable the goals of the project. In fact, the very reason why change management is such a big issue is because of this desire to 'spec out' feature lists early on in the duration of the project; the feature list is always wrong, and, of course, because it is wrong change is mandatory, and often within the implementation phase of the project, and thus expencive.
A much better methodology involves explaining to the client that the bulk of the project will involve investigating what functionality will enable the realisation of the client's aims. This can be achieved through rapid prototyping and user testing...with tools as lightweight as paper and pens. Only after several iterations of this will a reasonable scope and feature list be viable. This approach has a distinct advantage; you can be confident that the scope or feature list is unlikely to change radically, i.e. 'can we do e-commerce too?' - as you have already tested it to make sure it works.
Only after this investigation is complete can you resort to feature lists and change forms.
How (http://www.howardstredwick.com)
Web Redesign: Workflow that Works
Oh I'm assuming most people know about this book. If not, definitely check it out. It is an excellent source for process within web development. A lot of web gurus are contributing experts for it as well (i.e. Jakob Nielsen, David Siegel, Jeffrey Veen, Lynda Weinman, Jeffrey Zeldman, etc). The foreword to the book is also by Jeffrey Veen. Here's a quote from it.
"I wish we'd had a guide through all of this. What I would have given for a reference like this book, suggesting ways in which we could have minimized the pain and alienation that comes with constant experimentation."
Nollind Whachell
Howard if I didn't know the full feature set of what a client wanted for their website before they signed off to start, then I would be going "Yikes" myself. The reason being is how can I give the client an accurate timeline or quote for the job if I have no idea what it involves. It would be like a home developer starting work on building a home without the blueprints in front of them.
If, however, you are saying that the client won't know all of the features for their site when you meet with them for the "very first time" well then you're absolutely correct. That's just it though. The time between when you first meet with them and when you actual start working on the site involves finding out what they actually want. This is called the "discovery" or "definition" phase and by the end of it, you should have in your hand the "blueprint" for their site (be it a scope definition or whatever you want to call it). Often times this phase is totally outside of the main project timeline and is often charged separately from the actually site development (similar to how you pay an architect for your house plans and pay a home contractor to build your house).
A problem that a lot of people have with the discovery phase is knowing when to stop. They may start throwing in comp samples and such. As Paul indicated, the key aspect of this phase is just to determine the scope or definition of the project. In otherwords, what features it will encompass. You shouldn't be going into making content wireframes (information design) or graphical comps (visual design), or anything like that because those are steps "within" the site development later.
Similar to Jeffrey Veen's quote above, the firm that I worked for found this out the hard way. I was continually frustrated by not having a clearly defined direction at the start of work for a site. I constantly asked why we didn't have this information. The reply came back that they had to get a signed contract before starting work and then they would get this info later. I said how can you quote or give a timeline without knowing the details or scope of a project. Over time, I won out and we eventually added a "discovery" phase to determine this information needed. Sometimes this phase is charged for separately for a large project, while other times, the firm just absorbed the cost of it since the project was so small. Either way, the steps in the process need to be there. Usually the smaller the project, the faster the steps can be processed.
Nollind Whachell
Good start to this topic.
Regarding "comps" I would say that almost all projects I've worked on (new apps, enhancements, re-designs) high fideltiy comps have been vital to the project's success. Clients that I've dealt with are primariy visual people. I can document the requirements and functionality all I want, but showing them to someone has been the most effective way to ensure the client, end-users, and I are on the same page. This has proven to be a great way to manage client and user expectation, as well as, save our team a great deal of headaches down the development road.
I would also like to emphasis the importance of clearly communicating your process with a new client, so he/she knows what to expect when working with you and your team. What are the different phases of the SDLC and what are the inputs and outputs for each phase? What inputs/outputs are expected from your client? How does the change management process work? How is support to be handled? Those are just a few topics of discussion. Setting the expectation with your client upfront and getting on the same page from the beginnig will definitely start you off on the road to success.
Grant (http://threesixty.cc)
Howard: You have to have some idea of what direction you are going in and this is where the initial features list comes in. Notice throughout the entry I try to emphasize the fact that web development is organic and that you will almost always go through changes to the specs.
However, I would suggest coming up with a complete feature list as possible and then use that for a deadline phase 1. Take an iterative approach to development so that then newer features could be pushed to phase 2 of the design.
Scrivs (http://www.9rules.com/whitespace/)
Scrivs:
You have to have some idea of what direction you are going in and this is where the initial features list comes in. Notice throughout the entry I try to emphasize the fact that web development is organic and that you will almost always go through changes to the specs.
As I said, the client will have a vague idea of what they want, but this idea will most likely, due them not being experts on all things web, be ill formed and not likely to cover such important things as ROI and usefulness; building a feature list from this ill formed idea seems to me like building on poor foundations.
Is all web development 'organic'? In a way, I understand where this 'organic' idea might be coming from, in that publication style websites could be described to be naturally organic. However my feeling is that stating all web development is organic in nature, and indicating that this is in some way different to that of the development of desktop software, is an oversimplification.
Traditional desktop software could be claimed to be 'organic' in that scope and definition are subject change and new features are added over time between revisions. Save for the delivery mechanism, there is little difference between the process of revising traditional software and the process of revising a website; both happen for the same reason; the original didn’t meet the requirements or the requirements have since changed. What you are describing as 'organic', scope creep, change orders etc, are all problems that the desktop software industry has been trying to deal with since the widespread adoption of PCs.
Making the generalisation that the web is 'organic' seems almost like an excuse for failing to focus on the systematic discovery of what clients, and their customers, need / desire / find useful before anyone even thinks of feature lists, let alone implementing version 1.0.
My point was that instead of creating feature lists early on in the project, taking time to discovering what the correct feature list of the application / website / whatever is more valuable than guessing from the off. I believe this is what Meg Hourihan was talking about when she described spending four months on user interviews and discovery during the development of Kinja. Where I totally agree with you in that at some point a website, or desktop application, car or whatever can be reduced to a list of features, contrary to what you stated, this cannot successfully happen at the beginning of the project, and if you try, you merely encourage scope creep and change orders.
How (http://www.howardstredwick.com)
Howard: Meg went through a discovery phase which is what you are supposed to do with every project. Maybe I should have mentioned this earlier. I am not saying you should talk to the client once and take a guess at the features. There are numerous things that should occur even before the contract is signed and they are all part of the discovery phase.
After you go through these procedures, then yes I do think it is possible to develop a features list.
I can see how it would have helped if I started this series in chronological order, but please don't think that everything that was discussed in the entry are the first interactions that should occur with the client.
Scrivs (http://www.9rules.com/whitespace/)
Very Nicely said, I was thinking of changing things on my site , though it uses css but still due to ad project management i find it difficlt to do site changes. Teaches me a lesson to be a good manager for future changes. The article is good
Pintu Sharma (http://www.sms-ndia.com)
One thing to remember is that there's no such thing as a perfect project plan. Don't waste too much time trying to be absolutely 100% correct on everything. Get out there. Start the work from a solid plan, but embrace reasonable change -- there will always be things you didn't think of that make a huge difference.
For example, the orginal plan for Basecamp didn't include RSS feeds or iCal integration. It was an eleventh hour call the night before we launched. And it's been one of our most popular features.
So, stay open to some degree of change. Flexibility should be your friend.
Jason Fried (http://www.37signals.com)
Definitely, as Jason said. We added check images to our online banking software on something which could very nearly be called a whim, because we could, and it would only take a few minutes... and it's one of the biggest reasons the project succeeded far beyond our expectations (the other being up-to-the-second transaction listings, which took rather a bit longer than minutes, but is very cool.)
JC (http://thelionsweb.com/weblog)
Keep track of comments to all entries with the Comments Feed
©2003-06 9rules, Inc. | Thoughts Feed | Notes Feed
Amazon Stores: Powertools | Jewelry | Books | Health | Landscaping | Kitchen | Movies
#1
FLiP (Fusebox Lifecycle Process) is a useful tool for web application development.
Start with a very simple web-based, clickable wireframe application that you can edit in real time while meeting with the client, modify it til they're happy with the basic flow of the website.
With that in place, a look-and-feel can be created... work that out with the clients.. then when they're OK witht he basic look, build a non-working prototype based on that look (FLiP suggests it be pure HTML, but they assume a number of non-developers on a project and we don't have any, so I usually code it up in CF with a templating system so changes to the global stuff affects everything at once).
Once the prototype is done, the client can tweak as needed, with the developer there if necessary to note what is and is not possible. When the client has agreed to the look and feel and so on, you print out each and every page, have them sign it with a note that each page has been approved and no further changes will be allowed in version 1 of the project.
And then the coders can finally begin to code. There will still be some small degree of scope creep and some minor changes, that's inevitible, but the majority of it has been hammered out before one line of real code has been written, so you're much less likely to hit a snag at 90% that requires you to go back and modify large chunks of the application.
That's just one aspect of course. It's a detailed process, worth reading up on.
That said, web projects aren't always easy to plan out. I have one that has been in process for about 4 years now, from planning to finally coding... and it's still not done yet. And we can put together MS Project documents left and right, draw up Gannt charts, whatever, and it won't make a damned bit of difference except wasting our time, because there are so many pieces in so many different areas that we don't have any control over.
We're making decent progress now that the coding has finally begun, but what we work on is limited to what pieces the mainframe guys have done, what pieces the consultant hasn't horked up at any given time while trying to implement stuff we asked him for 8 months ago. So while I may spend 2-3 hours a day working on the project, I can't set it out in a nice linear chart or give a real estimate of when we'll be finished, beyond "we'll meet the deadline with a little time to spare"
JC (http://thelionsweb.com/weblog)