A Clear End

Imagine that you’re competing in a marathon. When do you know it’s the right time to stop running? For me, it’s when I cross the finish line. It seems borderline insane to picture running a race without knowing where the finish line is, so why do so many freelancers work on projects without a clear concept of completion?

If you don’t establish mutually agreed upon project completion criteria with a client, you may find yourself subject to scope creep.

What is scope creep?

Scope creep in a project is when a client asks for changes in the application that exceed the original set of features. Many times the client doesn’t do this on purpose. A normal progression is for a client to see the development progress and then realize that they forgot a “key” feature.

When scope creep isn’t scope creep

There are times when the right thing to do is incorporate the feature they’re asking for. I can think of examples where the client hadn’t listed a specific feature. But the feature was truly necessary and required by pure common sense.

Recently I headed up the development of an iOS project where the client didn’t specify that a push notification needed to be directed to a post. After the application was completed the client was frustrated that the system didn’t have dynamic and clickable push notifications. I could have pointed to the fact that they never asked for the feature. However in my mind the behavior was a common sense feature, so I had it added for no extra cost to the client.

When scope creep goes badly

Scope creep is rarely that easy. You’ll discover that typically clients will come up with new ideas and then try to get you to implement them for free. If you haven’t established a clear definition for project success you’ll end up with an angry client who thinks that you’re trying to over charge him. Remember that in the client’s mind they may not realize that they’re asking for a feature outside of the original set of requirements.

There are two ways for defining project success. And we’ll walk through both of them.

Based on Requirements

First and foremost is the traditional approach, which is based on a set of requirements. This approach is ok, however it rarely works in the real world.

This process goes through the following workflow:

1. Write out a comprehensive set of project requirements.
2. The requirements sound something like: user should be able to login.
3. Each feature has its own requirement
4. Once all the requirements are implemented, the project is considered complete.

Theoretically this seems like a great plan. However in real world projects it rarely works. The issue is mainly that even the most experienced developer or project manager won’t be able to list every… single… little feature. What will happen is that features will be missed. And when they are either you or the client is going to have to compromise to get the project completed.

Based on a Story

So if defining project success based on requirements isn’t practical, what’s a better approach? Personally I have had the most success by building easy to follow application stories.

What is an application story? Let’s take a look at one I wrote for a recent project:

When an admin user logs into the application she will be shown a custom dashboard that renders all of the projects that she manages. From there she can edit project details. She also can navigate to the resource section, user management dashboard, and user audit log.

Notice how a story is different from a set of requirements? When clients are presented with stories it is easier for them to visualize the final product. This leads to them supplying you with the full set of required behavior in the beginning, instead of at the end.

Lastly, well constructed user stories give you a clear definition of project success. Are the stories functioning properly? Then the project is completed, it’s that easy.

The Sign Off

After the client has approved the full set of application stories, make sure to get a formal sign off from the client. Typically this means having them sign a document that contains all of the stories. This provides a practical agreement that you can point to when all of the features have been implemented.

Summary

I hope that this has been a helpful guide for defining project success as a freelancer and that you can use this approach on your next project.