Why Scoping Matters
Had I scoped every project I had ever worked on, countless dollars would have been saved, countless tears wouldn’t have been shed, and I probably could have added years to my life. You see, when you don’t scope your project well, you automatically create client expectation management issues. This means that you think the system should work one way and your client thinks it should work another way. But because you didn’t take the time to write it out and tell them exactly what you’re planning on building, now you have a problem. Sound familiar?
Expectation management issues come in a wide variety of painful and often very frustrating encounters with clients. Most of the time though, it sounds something like this; you say “Here we are Mr. Client, your awesome new thingy!” “Well…” says your client “this is ok, but it’s supposed to do [fill in the blank here] or work like [some other thing you weren’t expecting at all].” “So” says your client again, “when can we expect these changes?” I’ll just let you imagine how the rest of that scenario plays out when you realize you don’t have any budget left and maybe the client is actually right now that you see what he is saying. In the very least, you feel like you should take care of his requests because it really was your responsibility to make sure you explained it correctly in the first place.
This whole situation could have so easily been avoided had you just taken the time to explain to the client exactly what you were planning on building for him. But now, you have a problem.
The Power of “Should”
I hate the word should. Well, more accurately, I hate the word should in reference to interactive design and development. To quote Yoda, “there is no should, there is only do or do not”. When programmers are working, the system works one way, or it works another way, there is no inbetween. So when you’re planning a project, one of the most important things you can do is to explain to your clients EXACTLY how the system works, exactly what each feature is going to do, and preferably how long it will all take to build.
One of my other (least) favorite quotes on the word “should” is from about ten thousand different clients who have said “it should work like [Facebook, Google, you fill in the blank with a company with a truly giant budget].” A client has no idea how much time it takes to make something work or what is involved in Facebook’s feature that pulls in a page image, header, and text and formats it so nicely from just a link. But you do, so make sure to tell your clients exactly how their system will work or you’ll be on the hook for building a multi-hundred thousand dollar feature with your 3k budget. Or at least you will in the eyes of your client. Should you allow your client to dictate what goes into your project like this, you are highly subject to….
Scope Creep
Raise your hand if you’ve ever heard this; “The client asked if we just add another form here,” or “Can we add just one more page,” perhaps “Our CEO asked to include the shopping cart with this budget as well (95% of the way through the project)” or finally “You know what would be great? A Twitter feed on the home page!” Some people think this is terrible, but I have to admit, any of these items are music to my ears because it means we’re going to keep working for this client and keep on getting paid for our work, because for ever project we do, we have a set scope of work. I’m not saying that we’re inflexible, and some rules bend, others break. But if you don’t have your scope of work and your rules, you definitely can’t enforce them.
Good Clients
For example, we have one client who is super easy to work with, is a great non-profit that does medical work for children in war zones. If we send them a bill, they pay it right away. If something is late by a day, they are understanding. As a consequence, if they need help, we’re there for them. Rules like “you always have to abide by the scope of work” don’t really apply to them.
Bad Clients
We’ve also had clients that are super hard to deal with, are always trying to bring down the price, don’t get back to us on time but then get upset when their projects are late, and have been just plain mean to the team. Having a scope of work for a client like this can save you countless thousands of dollars, and a lot of headaches. I really can’t stress enough how much having a set scope of work with these guys has made our lives better.
Big Clients
Finally, scope creep is most noticeable on a large-scale project. I think the best example of this that I have is a great, but very indecisive client. He is a great guy, is easy to work with, has a lot of financial power behind him, and is a total dreamer. His ideas are amazing, but they change every day. We started on a 300k project with his team, but half way through he changed some major areas of the scope. Because he started changing things very quickly on us, and paying on time and materials, we didn’t write down all the requests every time and re-scope the work. This almost cost us a great client and a great relationship.
My lesson from that project was that no matter what, always, always, always scope every request that a client gives you and send them a breakdown of what they asked for with time and costs. Had this client better understood the costs he was facing for all of his requests, he may not have authorized them. But even if he did, when he came back and asked what was taking so long, why things weren’t done, and what we were doing with all of his money, we would have been able to point to all the scope docs that he had approved and say “you told us to do all of this!” But instead, we had to pull up all those emails, all those requests, and then we still didn’t have a great answer when he asked why we didn’t show him each time he asked us to do the work how much it was going to cost. It’s all worked out now, and we have fixed our relationship there, but we scope every single request now, and we make more money and have a happier client.
Can a scope be simple?
I’ve always worked in interactive development, so for me, not really. Maybe in print, or sign-making, or poster design it could. But I have a feeling that even for those areas, the more clearly you write out what you’re planning on doing, the better off both you and your clients are going to be.
For web and app design and development, there are tons of variables, usually many different pages each with it’s own content, functionality, and other non-functional requirements. If you don’t explain to your clients what each thing is and what it does and have them sign off on it, at least in your client’s eyes, you’re probably on the hook for this work. When I do a scope of work for a website, I like to write out every page, every section, every sub-section, etc. and have the client sign the document before every starting on the project.
I’m not saying that there is no room for agile development and that everything has to be waterfall, but you need a place to start. Also, when you are building in agile, you still need very clear specs for completion and for each iteration.
It is important to say that I don’t think that you have to point out every database table and every variable, but the clients need to know and understand what you are proposing you are going to build for them. In the same way you would plan a house, you need to architect your plans for your web and app projects.
But I’m a Designer!
I hate it when designers tell me this, so I wanted to address it directly.
Yep. You are a designer, or developer, or project manager, or whatever. But the minute you sold your services for money, you also became a professional. As a professional, you have certain obligations to your clients. One of those is making sure they know what they’re getting. You can whine about how scoping the project should have been done by the sales team or the other guy or just not by you. But at the end of the day, if you took the job, it was your decision to take care of the client and you needed to explain what you were doing so that you were both on the same page before your client paid you money. You know what you’re building, and your client probably doesn’t, so it’s your job to make sure you both understand what is being done. If you’re going to be a professional, be professional and do the right thing.
It may be the most important part of the project
The reasons and challenges above are why we built BrainLeaf. Before we built this system, we had failed time and time again at scoping our work because it was time consuming and complicated, and really, no one wanted to do it. We needed a system that would be fast and easy to use for all of our team members, and would allow us to build and reuse complex scopes of work and information architectures for multiple clients. We needed something that would be as clear for clients as it was for us. After way more work than we had ever expected, we now have a system that works well and we hope that you too will find as much use in this system as we have.
Give it a shot!
If you’ve ever run into some of the problems noted above, sign up for a free BrainLeaf account. We’re always looking for more input on what we’re doing, how we’re doing it, and how we can make our system better! Let us know right here and we’ll do our best to get your requests implemented!
