Don’t let Scope Creep creep up on You
Scope creep is where many of our problems with budgets and deadlines come from. Freelancer Miles Burke defines scope creep as what happens “when extra functionality or items are added into the project that weren’t part of the original specification.” (Burke, 2008, p 127). It is arguably one of the biggest project killers and tension points, and is no fun to deal with when it happens.
But, scope creep can be easy to overlook when it starts because, as the name implies, it creeps up on you. It starts small, with a little request for an extra feature here, or a suggestion for an optimization there. Entrepreneur Brendon Sinclair describes a possible scope creep situation where “the client’s approved your quote to complete certain work, but, as you begin work on the project, the client asks for the addition of extras here, there, and everywhere. Before you know it, that 25-page ‘brochure’ site becomes a 50-page, ecommerce-enabled site, fully optimized for search engines, with an additional newsletter subscription script and a forum!” (Sinclair, 2007, p 201). That’s almost double the initial work! A change in budget and timeline are necessary, although the client may not agree. Thursday Bram on FreelanceSwitch.com writes, “While it’s easy to get frustrated at a client for piling request after request on top of an existing project, not all clients really realize that’s what they’re doing. Especially if you’re working with a client that is newer to working with freelancers or the type of project you’re working on, he may not recognize how much work his requests require.” (Bram, 2009).
But the fact remains, as Sinclair writes, “the project could quickly become unprofitable.” (Sinclair, 2007, p 201). Burke agrees, “It’s important for both parties that you tame that scope creep monster quickly – leaving it to grow and envelop the project will mean that both parties will end up in disagreement. The client will feel your resentment as the budget and timeline blows out, while you’ll feel pressure to get the work done quickly and may end up reducing the quality of your work as a result.” (Burke, 2008, p 127). Something must be done to tackle scope creep before it overtakes any project.
Most freelance professionals agree that beginning any project with a clearly detailed brief that includes milestones along the way is a great start. Shelley Doll on TechRepublic writes, “Controlling the scope of your project begins before the first line of code is written…you’ll benefit greatly from documenting your efforts before you begin them.” (Doll, 2001). Most professionals also agree that scope creep is inevitable, and even natural. Doll suggests freelancers “implement Change Order forms early and educate the project drivers on your processes.” (Doll, 2001). Burke agrees and writes, “By sticking to these processes, you and your client will retain a clear understanding of the costs in terms of time and money of the scope changes.” (Burke, 2008, p 127).
By beginning with a clear understanding of the project, expecting and preparing for scope creep, and utilizing Change Order forms to update the details, price and timeline of a project, both designer and client will benefit. It’s much better than letting scope creep creep up on you.
What about you?
Have you ever had any issues with scope creep? How do you deal with it? Any suggestions to avoid scope creep in the first place?
References
Burke, Miles. (2008). The Principles of Successful Freelancing. Australia: SitePoint Pty. Ltd.
Sinclair, Brendon. (2007). The Web Design Business Kit. Australia: SitePoint Pty. Ltd.
Doll, Shelley. (2001). Seven steps for avoiding scope creep. On Tech Republic. Retrieved June 3, 2010 from http://articles.techrepublic.com.com/5100-10878_11-1045555.html
Bram, Thursday. (2009). 4 Ways to Kill Scope Creep. On Freelance Switch. Retrieved June 3, 2010 from http://freelanceswitch.com/clients/4-ways-to-kill-scope-creep/
Hi Aaron,
Sometimes Scope Creep is created by the Project Manager himself, to sustain his indispensability by creating more work (take a look at this example about a different kind of scope creep).
In most case, I’ve seen that scope creep is caused by bad requirements gathering in the planning stage.
Thanks for the link PM Hut.
In this case, with Simon, it does seem a bit like he was trying to maintain his indispensability with more work, although he got a bit too carried away with it. Everything (and everyone) has limits, particularly project budgets and timelines for companies that want to actually release a project for use – rather than be bogged down in endless development, and re-planning.
In the case of Simon, and others like him, if they want to remain indispensable to a company, I think the best thing for them to do is to finish the project they undertake within budget and on time – and if they must have scope-creep, it should be kept minor. If the project manager thinks that more scope-creep and features need to come in, then he needs to make a new project proposal. If too many new features, and renegotiation of original planning is made, then the project will no longer be what it started off as. But, to keep the company who is financing the project (and paying “Simon’s” bills) happy, the project manager and development team need to complete the project within a reasonable timeframe and budget. If more is needed, the team can put together a “Version 2.0” proposal, and so on.
I think it’s best to finish the original job first, release it to the public (if that is what it is for), and then consider additional features and a different scope for “Version 2.0.”