Let’s start at the beginning. Before a single document is written, before a Gantt chart is drawn up, before a copy of Project is opened or Visio has sketched out any process, the project manager has to figure one important element of the project…
The problem#section2
Without a problem, there is no project. Where there is a problem, however, there is a stakeholder who is desperate for a solution and who has a delivery deadline — which is normally sometime yesterday.
The mistaken methodology#section3
Many project managers believe a project has a beginning and an end. Everything that happens within those parameters can be dealt with by a methodology and a good framework of processes.
What they forget is the emotional core of a project and the questions that need to be asked: Why does this project exist? What benefits will it have? What features will express these benefits? How will it make users more efficient, effective, and happy?
The normal reason given for undertaking a project is that it will (say it with gravitas) “have a direct effect on the bottom line of the company.” This may be great feedback for a CFO, but not for a project manager.
Take, for example, a piece of software. It helps to know if it’s being produced to be used by the Marketing department or the IT department — or a small design firm where the number one fashion color just has to be black.
This knowledge allows an experienced project manager to make judgments on various elements of the project.
Inflate the balloon#section4
75% of the work of every successful project is completed in the initial stage. In other words, every project has a balloon phase. And if it doesn’t happen at the beginning of the project, then you may get into some serious trouble.
The “understanding” phase needs to provide you with the framework for the project. It should be assembled with all major stakeholders. And its purpose is to define the problem so you can design the solution.
The 4 bedroom house.
On 13 March, 1999, Habitat for Humanity in New Zealand made the Guinness Book of Records. They constructed a four-bedroom house from scratch. It took a mere 3 hours, 44 minutes and 59 seconds. (I’m sure there’s a reality TV show in there somewhere, but I don’t believe we need another one of those.)
An incredible feat. The significant fact is that it took 14 months of planning to achieve.
The balloon was inflated at the correct end.
Where did that stakeholder come from?#section5
A few years ago, I was part of a project for a large Australian company. The project’s aim was to convert an aging monolithic website into something more manageable.
It was to progress over a number of stages. Our client briefed the company, allocated project, and commenced. The client asked us to develop an interim design. “Something nice, just for now,” they expressed casually. This was not scoped, but was quickly completed. All seemed to be going well until…
One fine morning, the sun rose and traveled gently across its arc. Birds chirped away in the trees. The view was spectacular from the 30th floor of the client’s building.
It was a “stakeholders” meeting intended to introduce the work to date. This was the first time we had met any of these people. It was the first many of them knew of the project.
Matters started off pleasantly and went downhill like a snowball out of control. There were issues discussed that were never in scope or expected. There was heated discussion about the colors used, text on the page, images. Every one, even the cleaning lady, had an opinion.
There was a mistake by both parties. We had taken on an area of the project we assumed was an interim measure. We knew we never should have touched it. We didn’t ask the right questions at the beginning. We only partly inflated the balloon.
The cruelest lesson? We never got to Stage Two.
Don’t ever be afraid to hit the “STOP” button#section6
As the project manager, you are the King of the Castle. If you have inflated the balloon at the beginning, you now should have a lot of ammunition at your disposal:
- You have documentation everyone has agreed to
- You have all agreed to the scope and vision of the project
- You have all agreed what should be done
And now you want me to make what change?#section7
When the scope starts to run out of control and new requests are asked for, the best tactic that you have is to state the truth.
Please repeat after me: “What you are asking at this stage has changed the project considerably from the documentation and the scoping process that we undertook and has been approved. We could continue, but I believe it would jeopardize the quality and the integrity of what needs to be delivered. If what you are suggesting is vital to the project, and cannot be handled as a phase two, then I would like to stop the project now so that this new addition can be properly scoped and integrated, rather than tacked on. To continue without re-scoping, may cause unforeseen problems later, which could be quite costly. However, you must understand that to stop now will affect timelines and budgets. How would you like us to proceed?”
I have done this, and believe me, most clients want this kind of honesty. You will not win any friends if you continue dealing with scope creep and allowing it to defile the project. You will become the scapegoat. You will not go past go. And you will not collect the $200.
Joe,
I can sympathize with everything of what you are describing. However, these problems not are not limited only to the Web world. I may go even as far as to say that these problems are the main cause of ulcers in middle management.
The way I see it, the solution to the problem is a little different than repeating a mantra.
The solution to this problem has everything to do with hiring|being an experienced project manager who knows the field and understands the complexities involved in project implementation.
IMHO, among the victims of Web revolution are the designers and coders who started “just doing sites” and suddenly found themselves in the middle of a serious business with complex workflows and processes. Without solid project management skills, they had to learn PM using the BST (blood, sweat, and tears) method. As a result, Web project management processes are commonly ridden with “magic bullets”, ritualistic dances, and mantras.
There is no need to re-invent the wheel. It’s been told and re-told in many various ways. Go to school. Take a few PM courses. Or start with Amazon, if you’d like.
Excellent article. It also shows, by implication, the absolute necessity of having a project manager who is given the authority to actually make decisions. This is a real problem when the project is done internally. Too often, the PM finds themselves constrained by an existing chain of command, if not explicity then out of institutional habit.
A great book dealing with website PMing is Web Redesign | Workflow that Works by Kelly Goto and Emily Cotler. Don’t pay attention to the “redesign” in the title; the book outlines the stages of any web project—definition to delivery.
Also, 37signals’ Basecamp is a great online project-management application…as long as you remember to use it!
As this article points out, it really is all about managing the scope of the project.
If you are dealing with the appropriate stake-holders who have final authority on a project, the biggest thing you have to worry about is scope. If you do all your discovery work ahead of time and write it in a document that is delivered to the stake-holders AND SIGNED BY THEM, a PM will have a much better grasp when it comes to saying “Yes, this is in scope, go ahead” or “No, this isn’t in scope. We can do it, but it will take $X and Y time”
Being able to reference an agreed document for things like this will save *quite* a bit of headache in the long and short run.
I also want to point out the book referenced by one of the above posters. Website Re-Design is a good look at how a proper discovery phase (and subsequent project management) should be executed. It isn’t fully sufficient for “large enterprise projects” but you can easily take what they have and add the missing pieces.
we’ve just been burned doing an ecommerce site by scope creep. they now want to know thousands off the price 🙁
One poster commented about a PM having proper authority. I agree with that to an extent and suggest that it goes a step further with defining everyone’s roles within the project. We have Project Managers, Business Analysts, Business Users, QA, Developers, Team Leads etc. All of them are involved at the different levels of the project. Too often the different roles aren’t well defined and tend to bleed into one another. The PM attempts to analyze what the business wants, the business attempts to define the interface design, the business analysts are trying to manage the details of the project, and the developers are having to deal directly with the business users when the interface they provide doesn’t match what the PM said they’d get.
There are other problems (HR issues) in that sometimes the BA’s and PM’s are nothing more than developers who couldn’t hack it and got moved into a new position. The assumption in doing that is that the person is familiar with programming and therefor should act as a good bridge between the user base and the developer. That’s not necessarily true.
Any project has to be a itterative team effort. PM’s shouldn’t sign off until they’ve consulted with developers to make sure that what the business is requesting meets what can be done. Likewise PM’s should be in close coordination with an apt BA to make sure that what the business is asking for is really what they need (so that there are no surprises).
The worst project scenario in the world is this:
You get a set of requirements for something that you can’t reasonably code. You push back and the business agrees to a compromise solution. You build out the compromise, set it up in production and users start using it. Then some time later the business comes back with a new set of requirements that completely scraps the functionality because it wasn’t what they really wanted or needed.
Nice read. Thank you.
While scope creep can be dangerous, how do I convey the implications of *removing* major functionality?
I was part of a project where an automated financial process was removed one month before the due date. The transactions now had to be done manually.
The project lost any return on investment with this canibalization. It became less desirable and created more work than the system it was replacing.
*Any* change in scope can cause problems.
I think one of the problems that I’ve experienced is managing stakeholder expectation alongside a project’s velocity.
Let’s be honest, most of the time the balloon phase gets shortchanged for any number of reasons – lost my briefcase, forgot about that email, didn’t realize you didn’t understand what i mean, he/she said this wouldn’t be a big deal. And most of the time we’re working on super tight budgets and timelines without enough people. So, ladies and gentlemen, how do you convey to the stakeholders that without formalized business rules and planning velocity could adversely be affected?
I can handle that. But how do you manage a stakeholder who’s clamoring for something
Great article!
I think the biggest trouble I’ve run into has come with trying to balance the desire not to nickle-and-dime the client with the desire to put the brakes on scope creep. When the client emails relentlessly about a tweak here or a change there, it’s hard to really say “STOP” in a loud voice, because any of them individually are no big deal.
What I’ve done in the past is, in that initial balloon phase, to acknowledge the inevitability of change as the project continues, but say that we’d need to take a second look at budget and schedule if, say, there’s 5-10% deviance from the statement of work. And then keep meticulous records about all the requested changes, so when we get close to that tipping point, I can raise that red flag for the client.
Anybody have other ideas?
While it’s great having stakeholders who are really invested in the process, it is imperative to have a key decisionmaker on the client’s side who has the authority to cut the bull and make a decision when the debate has run it’s course, and enforce that decision with the stakeholders.
In this respect it is important to have authoritative project managers on both sides, and ideally they’ll have a rapport to facilitate the project and bring it to a satisfactory conclusion for everyone involved. Not all the stakeholders will be 100% happy, but that’s the client-decisionmaker’s problem, not necessarily yours.
John
It often seems logical to ensure all your team members are on target towards the project goal 100% of the time but you should never neglect the emotional and individual needs each member requires. This shows as a project manager you care and helps keep everyone happy and focused on the project when they are supposed to be.
As a part of the course I’m doing i was recently involved in a group project where we had to design a solution for a client.
I took the role of Team Leader, and while our project was never to reach a development stage I relate very well to your article. Being my first leadership experience it took me a while to find my feet and i fear i at one stage ruined the project for all of us because i didn’t understand it properly!
This is an excellent article highlighting some key issues in project design and development. Great Work!
God, there’s been some fantastic responses. I know from experience that Projects rarely end up exactly as you thought they would when you first began. The aim here is to provide a simple process that will help you save your sanity, secondly save your company from overruns that the client won’t pay for, and thirdly save the client from themselves. Much of the time clients have a thought and the Project Manager’s role is providing direction and defining a deliverable. I have worked with a client who never ever wrote anything on paper. They never read any documentation. Boy, every day was a minefield. But there had to be a way to protect myself and the company I was working for. Hey, what it seems everyone is saying is that there is a reason we are Project Managers. We do like the excitement and challenge of methodically getting to a finish line. We really do like the heat, we just don’t like to get burnt.
I’ve been trained to use DSDM ( http://www.dsdm.org/ ) in projects. This can include everything from websites to building a new city.
The fun thing of dsdm is that only money and time are fixed, everything else is variable — and as such opposes the inflated balloon a little bit.
Scope creep is a fact of life, because during a project people learn new things that could never be envisioned initially. That’s a fact of life.
I have never done a project without scope creep.
I once participated in a project where the initial signed documents where treated like a Holy Script. By the time the project was delivered everyone was dissatisfied, although the project was delivered on spec.
Since it was one of my first experiences as a junior on a team I vowed never to do another project like this, because it took the fun out of working and it missed target since the target was moved, but the trajectory wasn’t.
And thus I found my thing in the dsdm method. And thus I have done a lot of projects that ended somewhere else than where we started, with nothing but very happy clients, within budget and within time.
I just inflate a lot of different balloons along the way (sold as prototypes), but I keep a countdown clock to Moment X visible for everyone. The closer we get to Moment X, the smaller the balloons 😉
And that’s the same mantra as used by Joe: “We only have limited time, so we’ve got to make some decisions now what is included and what’s left out”, also known as MoSCoW:
– Must Have
– Should Have
– Could Have
– Would like to have, but not this time around.
What functionality is grouped under one of these requirement groups is a matter of inflating the balloon along the way. The closer you get to delivery time, the less is grouped under Must Have, and most of the “must have’s” have been delivered or shown in a previous prototype.
So interesting to stumble onto this discussion. I’ve dealt with the same issues, but on a micro level.
I teach web design to high school kids, and have them do sites for real clients whenever I can, usually people who are starting small businesses and have called the school looking for a way to get a site on the cheap.
Even though I hate the business end, I force my kids to do a ‘scope of services.’ We have a client interview and try to ask the right questions so that we understand what they want/need. Often they aren’t really clear themselves.
Then each kid tries to write a SOS. I give them a formula; one short paragraph saying something to the effect, ‘Great meeting you, we’re excited about the project and think we have a good understanding of what will make the site work splendidly for your target audience and your business. Eager to get started. Below we’ve scoped out what we propose to do. If this meets with your approval, sign and return the form with your deposit and we’ll get started.
Detailed description of project leaving as little room for interpretation or misunderstanding as possible.
Concluding sentence: What we’ve described above constitutes the entire project. Any work not included in the above will be billed at an additional hourly rate of $xx.xx.
We really look forward to working with you on the site.
Sincerely,
X
I explain that if you proceed this way and get the ‘lawyering’ out of the way right at the beginning, you can go on and be casual and friendly later, but if you don’t start out with absolute ruthless clarity at the beginning, things get murky and uncomfortable, and usually ugly in short order.
It usually goes something like this, starting with a phone call about a week after the project has started:
Client: Listen, I was talking to my brother-in-law and he mentioned that his site has a guest book, and I thought, wow, how great would that be? So could we add a guest book to my site?
You: Er, yeah, I guess we could. (now starts wondering if the client assumes that will be included in the already-agreed upon price, or knows it will be extra, and if so, how much extra…) Either way, you lose, because if you don’t charge them extra you’ll resent the job and make less, and if you do they may get angry and feel you’re trying to up the price and take advantage of them. The relationship sours and you don’t get return business or referrals.
If you have done the SOS They’ll say, I know this will be extra, but could we….blah blah blah?” you can say, “Sure, I’ll send you a change order pricing out the guest book, and as soon as you sign off on it we’ll go ahead.” And then they can decide if the addition is worth it or not, but you won’t have soured the relationship.
Had this happen last year with a good client. We were doing a site with animations of several rooms of a house for a children’s book. Did the SOS. Started work, showed her the preliminary, which she loved, but she asked “What about the basement?” I thought maybe she was right and we had forgotten it, but was able to go back to the SOS and see that it wasn’t included. So instead of a horrible situation where we remembered the agreement differently and both were sure we were right and oh dear, we have a tense situation on our hands, it was fine, and she decided she didn’t need it. The job turned out quite well, she was thrilled and sent us other clients.
So important to start with clarity, get it in writing, and then get on with the job of creating something great.
What if one of the balloons burst from too much pressure?
If the balloon burst from too much pressure? That’s easy, you go to K-Mart and buy a whole new bag. Then you either inflate another, or many, as mentioned by Martijn ten Napel above. Or if the pressure has been really bad, it means you probably don’t have a client or your sanity. So, you’ll be filling them up with water and dropping them from tall buildings.
Having been on both sides of thie fence here I think this was a pretty “safe” article.
On the one hand being upfront and honest is key when you are acting as a vendor.
On the other hand…you do it too often, or you don’t fully explain and get buy-in from your client…they will hate you even more and think you’re a predatory vendor doing a few things:
1) Stalling: You’ll need to provide some kind of tangible update and evidence of your good faith at this “honesty” session.
2) Screwing: You’ll also need to get 100% buy-in from your client that stopping or re-scoping is the right thing to do. Otherwise, they’ll just think you’re trying to eek more money out.
Here’s why… (that other side of the fence)
1) Organizations don’t necessarily have a good grasp on what doing a fully developed web-application can involve on the part of a developer and development team.
A great example is a simple text change that my company needed to make. We specified the change in the text. That text appeared on approximately 10 pages. Only 8 were changed by the developers and they were blamed for poor execution of our change request.
I have a feeling that the developer thought they had changed everything. I think that the developer needed to ask for the specific pages where those changes were to be made.
On our end, we saw it as something simple. In reality…the developers needed more time and information that wasn’t provided. (ie. the scope for the change request wasn’t defined well)
2) Organizations aren’t as flexible as developers.
When budgets get approved. That’s typically it. In some cases it takes moving mountains to get budgets changed. If you’re dealing with a business unit inside a larger organization…you better be COMPLETELY sure that you know what you’re getting into regarding scope changes and budget adjustments for a project.
Remember…web-developers (yes even great ones) are a dime a dozen. And more often, the best developers are just consulting front-ends that have actual developers in China or elsewhere doing the actual work. So remember your competition before you start hitting that stop button!
You have every right to. And it is nearly always the right thing to do. HOWEVER, organizations don’t “get it” so don’t assume they will magically with an email. You better be 100% clear with them.
3) Organizations are notorious for business-rule changes that effect whatever you’re working on.
Don’t assume that a change request is coming out of the blue only to you! A lot of times things change in the course of a development project internally at a company. Especially one that is developing a complex site or web-application.
Expect it. Build it in if you can. And keep in close contact to help anticipate it.
Remember…only so much can go into versioning with an application. Business rules don’t get versions. They happen and that’s the end of the story on the date they go into effect.
Your clients will see your ability to keep up with them EQUALLY as important as your ability to deliver a quality project. So put on your jogging shoes and get creative with how you handle these things.
In a lot of cases you’ll be able to make a small change that won’t be a big deal. But in other cases you might need to find a way to build your current version in a way that allows the company to do what they want, but then release a more elegant interface or procedure for that in a future release.
Never say no if you don’t absolutely have to.
So in a lot of ways the relationship between the client and the develoer aren’t adversarial. But…it is EXTREMELY easy to fall into that pattern of discourse with them.
The best way I can help you think about it, and the way that I do…
Think about a magical box where you type in what you want and then reach in blind and hope to pull out exactly what you want.
In many ways that’s how businesses feel. They want a very specific thing. However, they are a bit blind in terms of thinking about all the bells and whistles it needs. And when they reach into the box they can only feel the basics of what is being built. That can cause questions, revisions, and worry on their part.
You are inside that box trying to provide them with as much feedback as possible. The more accurate, timely, and complete the feedback is that you provide the better that hand in the box will understand what it is grasping.
Ultimately you want the hand to grasp exactly what it wants, and understand how it got to that point. Problems will occur along the way. The more the hand knows…they more it understands the shape it feels. The less it knows…the more it thinks it’s being tricked.
Be honest. Be complete. Be timely. Be COMPETITIVE.
One of the major reasons I’m into the internet seriously is because a few years back I got addicted to the “Water Balloon Drop” game on Shockwave.com. I mean, I didn’t even know one thing about HTML till about November 2002, but still it’s ironic.
I am going through this right now… and it is spot on, lesson learnt!!
I have just about finished a job for my first ever client, wishing I had read this 6 weeks ago.
sweet article, nifty diagrams
I think you’ve hit the nail on the head with this! I have discovered that feature creep is the number one problem with any programming/web design project. Having the scope clearly defined and agreed at the outset is the only way to make a project work.
Thanks!
Someone asked how to say no to the client when each change viewed as an individual change is actually quite small. They are right to worry about this because the client wont see the bigger picture, and doesn’t understand that all these ‘small’ changes pile up.
A very wise person (I forget who) told me that the best way to get them to see the small changes pile up is to get them to follow a vigorous RFC (Request For Change) methodology. Make them fill out a form to be submitted for aproval, and if the change justifies it, set up a meeting, for EVERY INDIVIDUAL CHANGE. This way, when they are filling out the form for the 20th time that week, they will get some understanding of how these changes are piling up.
If you make them do some paperwork for each change, they will see the paperwork pile up, as we see the code to be produced get more and more complicated.
I hope this helps.
The problems outlined in this article and the comments are compounded with very small projects. The overhead of producing a requirements document with an adequate level of detail for a small fixed-price project dwarfs the actual development time.
This “up front” time causes problems for inexperienced clients who “don’t want to pay for process, just results”. Some clients balk at the concept of paying to scope the work formally because “they already know what they want” (even when they only have a broad sense of what it is that they really need).
Currently we treat very small projects as loss-leaders. Most methodologies that we have used do not scale *down* well. If anyone has a methodology for producing highly detailed requirements for micro projects (less than 5 days total delivery time) please follow up.
I understand the problem you’re describing, but I’m not sure I agree 100% with your solution. Certainly, a scope of work needs to be defined and requirements need to be gathered and analyzed, but I don’t agree that 75% of the total work needs to be accomplished in the initial discovery phase.
I think what you’re saying is, “Spend extra time on requirements and scope, then lock it down and produce the product.” If that’s correct, then a basic assumption that (I think) you’re making is that the project team will follow the traditional “waterfall” style of development. Newer, iterative styles of development not only reduce the cost of change, but allow flexibility to such an extent that change is not only tolerated, but embraced.
The fact is, changes occur during every project. Iterative development simply relocates most of the change to earlier stages of development, where the change is least expensive to make.
I won’t go into the details of this type of development, as it’s covered in detail elsewhere on the web (a great recent article on this is at http://www.oreillynet.com/pub/wlg/4691). I can tell you, however, that I’ve been using it for the past 3 years, on projects ranging from site redesigns to full-scale e-business implementations. It almost always results in a better product being produced more efficiently, with less cost.
I like the honest approach, but it tends to ruffle feathers, and may make your client contact look like a dunce in front of other stakeholders if they aren’t 100% honest – which you have little way of knowing.
A bit of a shameless plug, we use a tool called INSPIRE, which we developed as a project management/asset approval/web collaboration tool for not only our web projects, but also for managing video production, animation, and audio. Check it out at http://www.epicsoft.net/inspire
I agree with G Jones: iterative development allows you to keep gathering features for the ‘next version(iteration)’ while keeping the current one on track. Deadlines are met, avoiding developer frustration, while requests are planned in, avoiding stakeholder frustration. It’s also very good for sales, as long as your pricing is hourly based, or at least a bid for the ‘first version’ (defined in advance) with hourly-based pricing for future iterations.
Over the past decade I’ve worked for companies whose management was more responsible for scope creep than the clients. Whenever a client — or worse, someone who hinted that they would maybe possibly sorta kinda consider sending some business our way, maybe — would even hint that something may be needed down the line, that “something” would immediately become a priority #1 addition/enhancement/revision to our products and would de-rail the development cycle. This never ended the entire time I worked at these companies (unfortunately they were all related as the later ones were spinoffs from the original. Inept, inexperienced management always followed us).
We were in the business of developing software, not web sites/applications, so perhaps none of this applies to the current discussion. I suspect at some level it does, though. I’ve always found clients to be much more reasonable than my company’s management. Perhaps it’s just me.
My own management seems to be the major issue. Clients are generally open to new ideas or “best practices”, but my management seems to be in a constant struggle with the designers/developers to remain in “control” of every project. It’s as if they regret having “experts” on staff.
Great article! As a professor at a small college, it is difficult to “get throught” to students and explain “Scope Creep” and “feature Creep”. This article puts it in terms that I think are very easy to understand. Great Insite.
Rob
I’ve had this happen on several occasions and I have a script very similar to yours for just such situations. I have one item of interest to add and that is making sure you get sign-off before you proceed. I was recently put into the position of building a site and did all that you had suggested but couldn’t get all the stakeholders together. They had all agreed to the terms casually and via e-mail individually but when specs time came it was all “well, we thought” etc. What had happened was I took the verbal agreement as an agreement and got burned on the other end. Its amazing what people choose to forget when it is to their advantage.
joshua
I think you don’t understand software development at all. Yes, scope creep is a problem, but not for the reasons you seem to think. The problem is that you think you can define scope ahead of time. Quality software must be built via an iterative process with all sides gaining an understanding of features and workflow and using that feedback to improve the process, but it is a process. You can’t really scope it because pretty much no one involved understands ahead of time all the factors involved and implications of the choices that’ll be made along the way. Software isn’t a building, and that comparison is totally bogus. Better to change your contract’s to be shorter and based on delivering running prototypes that continually improve and grow, and you can stop at any time and have quality working software.
To put it another way.. scope creep is a symptom of using the waterfall process, a known bad practice to begin with. Fix the root of the problem, stop using waterfall and start using iterative development, it doesn’t suffer these problems, at all.
I think where we fail is to press stop button once we have realised the step wehave taken is wrong. Step 2 is more mportant then step One. Here
Thank you for a very interesting article.
It took some time for der XP-ers and AP-ers to show up – but finally they did.
I suppose everyone practises incremental design and coding, but that does not neccessarily mean that Requirement Specification has to be done incremental!
I think everyone will agree when I say that the volume of the ballon(s) is approximately constant and given by the problem at hand – to simplify, let me define it as the sum of the requirements.
Now, whereas I admit that the sets of requirements may differ depending on whether they have been accumulated over a period of time (small balloons) compared to having been collected at the start of the project (one big balloon), but I have never met a customer who did not know rather precisely what problem he wanted to be solved – and I have not only been working with compiler construction or hardware protocol implementations. Even when I had to develop web-sites the customers told me: “Look at that web-site. I want mine to have the same structure and functionality. What will it cost me and when do I get it?”
And I do not dare tell him: “I do not know. Let us produce a prototype for USD xxx. You will get it in 2 weeks, and then we will negotiate again. And so we will keep going month after month.”
Many customers just do not have the time to blow into a series of small ballons every couple of weeks.
To summarize: I agree with Joe Di Stefano and Phil Banes (Requirement Change Request) and never had problems with using this approach.
Joe Di Stefano delivers the best ammunition for scope creeps I’ve heard to date. I look forward to sharing the scope creep repellent verse verbatim for years to come! Thanks.
I’m just starting a side-business as a web programmer. I’ve been working at a software company for a a year and a half now, and I’d seen mistakes made a few times that have led to scope creep, wasted programmer time, and dissatisfied clients. It’s always easy to see a problem once it happens, but not so easy to see the solution, and even trickier to figure out a means to prevent it before it happens. This article was a real enlightener! Of course, it all seems obvious – once you know what to be aware of.
I’m working on my first big job now, and I am going to be betting on a great reference to generate future business. Also, it’s a one-man job. I really can’t afford to waste time on last-minute changes. So, I took Jo Di Stefano’s (and others’) advice, and spent several hours scoping out each part of the project in detail, with the client as an active member in the process. I documented everything that would have to be done in detail, so that I don’t have any questions, and made clear “success conditions” that could be demonstrated to the client at each stage. I also took a word of advice from Nate‘s comment, and included a disclaimer in the spec doc which allows room for minor changes, while setting a limit to scope creep.
When I sent them the programming agreement and spec doc to sign, they already knew what to expect, and said that it had everything in it that they want.
All of that was ridiculously tedious and took a lot of work on my part, but the client and I are both on the same page now, and having organized everything that has to be done, the coding is much easier.
I’m sure there are mistakes yet to come that I’ll have to learn from, but Jo and the great commenters here have helped me avoid some of the most costly problems.
Thanks! 🙂
I guess that html is not allowed in comments. And like a doof, I misspelled my own URL! It should be http://isaac.beigetower.org
Sorry for the clutter.
Well, the obvious solution is to spend time looking for good clients rather than bolting down processes with idiots who don’t respect written contracts anyway. LOL cleaning lady having an opinion – this situation shows that your client doesn’t know how to run a business or contract out services, and I would always use the Nike method to escape those ones. Especially as web design businesses are often exposing themselves to clients far in excess of their size and litigation strength.
For short projects I also like ONE SENTENCE AGREEMENTS eg “the site will be facelifted” or “existing pages will be made dynamic with php” because unless you really DO screw up, the client can’t twist things round and demand a month’s slavery to “finish the job”. It takes some explaining, and a lot of reassurance that you have heard their dearest concerns, but if they are pushed for time they will normally agree to a simple one-liner that gives them hope that soon, their worries are over.
For short jobs, clients seem to respect the simplicity and lack of “faffing about”. Of course, a “final changes” meeting is good just before the end, because it’s called “final changes” so they get the point.
Then when you are finished you just say “we agreed to facelift, and we did, so pay up” rather than arguing over the wording of subsection 6a.
And the golden rule is 50% UP FRONT. If they don’t trust you enough to pay you that, they won’t trust you with a design decision and you’ll be arguing for months. Or, they are the kind of business who make money by witholding it from subcontractors. And, when they have ALREADY paid 50% it can sharpen their minds about pissing you off or dragging the project out indefinitely.
Once, I demanded 50% up front, I had been burnt too many times by clients to do business any other way. I offered a written contract, and they laughed, saying “not worth the paper they’re written on.”
They said “You’ve been burnt, but we’ve been burnt too! It’s 50-50!” and I said “Exactly. 50% up front, and 50% on completion.”
I tried not to sound like a smartass, and they agreed. These dudes would not have wanted a 10 page document detailing every pixel of their simple facelift. They wanted to check my personality out a bit and then trust me, not spend hours in the “development phase” inflating some abstract balloon. It’s true, these breakdowns of processes often totally forget that humans have to carry out the work. Humans are not like flowcharts.
Every job you do, however small, should be treated as a partnership (nay sexual relationship) with the client. This includes trust, real human trust, not paper. If you aren’t comfortable with that, if for example you wouldn’t go down the pub for a drink with “those wankers” then find a different clientbase before the stress kills you.