Tips on managing your freelancing project’s scope
There’s this saying about being careful of what you wish for — because you just might get it. As a freelancer, you’ll have many opportunities to appreciate its wisdom.
Take project management for one.
If you come from the corporate world, you’ll probably have many bad experiences with incompetent project managers over-promising and leading their teams into “death marches” to be able to finish a project on time. In general, one of the great motivations for becoming a freelancer is being able to choose your own projects, define their scope, and see them to completion. But what happens when you suddenly get your wish granted — and make a mess of things that is totally your own fault? You’ll probably begin thinking that maybe that project manager was not really incompetent after all — perhaps managing project scope is inherently difficult.
Which it is. But there are few battle-proven tips and techniques, that can help you find out how to define and manage, the scope of your freelancing projects — which is exactly what we’ll be examining in this post.
what is a scope statement in project management? First, a definition. A project’s scope describes what you’ll be delivering to your client.
If you’re a graphic designer doing branding work, a typical project scope might be the delivery of “a corporate logo in various formats, official stationery, and business cards”, but it won’t include e.g. redesigning the customer’s web page or decorating their corporate offices. And this is also, how writing a project’s scope statement should be done.
So how can you do to please the gods of Project Scoping?
Know your limitations
Managing scope requires you to know your limitations (especially regarding budget and available time). The same way you can’t build a skyscraper with the budget for a single story building you also can’t build a major freelance project without major funding. But also, whatever your budget, 9 women won’t produce a baby in one month.
Nothing throws estimations off as much as unexpected changes in requirements (or worse, general direction) while you’re already building your project. And while you can’t always predict all future needs, it’s important that you have a pretty good idea of what you want to build before you commit to it. That way, you can better handle scope changes that will occur, no matter how good you are in project management.
Avoid scope creep (aka requirements creep / feature creep)
Already alluded to in the previous paragraph, scope creep refers to uncontrolled changes in a project’s scope. Scope creep has killed more ambitious projects than all other reasons combined (especially large enterprise and government projects, where everybody and their dog chime in at any time adding exponentially increasing features). There are several project management methodologies attempting to deal with it. But the lowest hanging fruit with the biggest and easiest to reap benefits regarding scope creep comes from…
Having it in writing
When it comes to proper project management, handshake agreements just won’t cut it. They leave too much room for disagreement on what “was supposed” to be included in the final delivery, and they leave the door wide open for the customer to ask for additional features as the project progresses (and insist that they should be done for the original asking price).
Always have the customer agree and sign on a written description (spec) of the project before you start. If they later ask for anything on top of it, you can always point them to those original specs, and either accept it or not. The written spec will also help in case they don’t plan on paying you after the delivery, sadly an all too common occurrence.
When you’re running out of time and the project is not done yet, just scale it down a little (or a lot). Knowing when and what to scale down is all about prioritization. Some things are necessary for a full delivery of any product, others are secondary or “nice to have”.
Have the customer rank the required features in order of importance. This way, even if the project misses its deadlines, you’ll still have the foundations and all the basic stuff down, and you’ll be able to work in late features with less stress.
The Pareto principle
There’s a rule of thumb in economics called the Pareto principle (aka the 80/20 rule), that, when applied to project management, says that (usually) 80% of the required functionality comes from 20% of the features(think of how you never use more than a few dozens of the thousands of features Microsoft Word has).
Of course, you still need to know which features belong in that important 20%, but the takeaway point here is that now all features are created equally — and you probably need fewer features than you think to keep the customer satisfied.
In this post, we gave a few hard and fast rules for managing freelancing project scopes. There are many others, but we haven’t budgeted correctly to fit them in the post — so stay tuned for a follow-up post down the road, and happy freelancing!