My company recently began releasing updates to our content management system on an almost-weekly basis. Previously our approach was to determine which features should be included in the next release, compute a timeline appropriate for the requirements, and then get to work. Most of our timelines were at least a month long, while some approached 2 or 3 months.
Our new approach, inspired in part by the open source community's "release early, release often" mantra, involves setting a regular release schedule (weekly in our case) and then prioritizing the features into these weekly buckets. Our goal is to deliver "business value" each week in some way. If a desired feature can't be built in one week, we find a way to break it into smaller portions that can each be done within one week.
We also apply this approach to the websites that designers hire us to program. Breaking down projects into smaller, more-manageable increments is a discipline we've adopted with great benefit.
We certainly didn't invent this approach. You've heard it said in other ways like "eat the elephant one bite at a time." In the development world there are methodologies like Agile and XP that espouse similar ideas. As a freelancer looking to manage time, make customers happy, and keep motivated, the benefits of breaking a project into smaller pieces are definitely worth another look.
Catch scope creep sooner
Clients' ideas will evolve over time. The longer they go without talking to you the more likely it is that their thinking has changed without your knowing it. New information about competitors, things they've seen on other websites, and conversations they've had with colleagues or customers are all things that can cause a client's thinking to shift. This shift in thinking usually leads to requests for changes to the project's scope. We call these midstream changes "scope creep."
Scope creep isn't caused by long project timelines but is more likely to occur in bigger projects with lengthier schedules. The risk of experiencing scope creep, however, can be somewhat mitigated by establishing frequent milestones and reviewing the project's progress against the agreed-upon scope at each milestone.
Too little client interaction on a big project increases the risk of experiencing scope creep. However, if every two weeks you're showing progress to the client and telling them exactly what they'll get in the next two weeks, you're more likely to control their expectations and any questions or concerns they do have will surface earlier. The sooner you address issues about scope, the less pain and expense you and your client will have to endure.
Keep morale and motivation up
When you work on a big project with a lengthy timeline it can be easy to lose momentum and excitement partway through the project. There is something very satisfying about completing a project and when that satisfaction isn't available after weeks or months of hard work, it's hard to stay motivated.
The closer you are to the "carrot" the easier it will be to keep your excitement level up. For a 3 month project, having a milestone to reach every couple of weeks will break the big project into 6 smaller projects. That's 6 more times you'll get to feel great about meeting a deadline and delivering successfully to your client!
Improve customer perception
Unfortunately a client can only judge your progress by what they can see. If you go "stealth" for several months it won't matter that you've been working all hours of the night to complete their project. Their perception is that nothing is happening.
Creating frequent milestones in which you deliver an agreed-upon result will show your client that you are reliable, consistent, and dedicated to their project. The more often you meet a deadline and show them progress the more confident your client will be in the commitments you make.
If a significant portion of the project is behind the scenes (like a complex backend to a website) it's helpful to tie a visual element to each milestone since most clients are unable to gauge progress on something like the architecture for a database.
Provide business value sooner
It can be rewarding to unveil a finished project in its entirety and wow the client with your completed masterpiece. Whether it's a logo, a website, or an identity system only the completed project truly reflects your creative genius.
Although the "grand unveiling" of the completed project can be satisfying to you, it is sometimes in your client's best interest to deliver a part of the project sooner. Often even the smallest portion of a project has business value in and of itself.
Generate revenue earlier
Many clients have a grand, dreamy vision of what their project will be like when it's done. One of the best indicators that you're dealing with a visionary client is that they'll make reference to some industry leader like eBay, Amazon, or Google. They want to be the Amazon of books or the eBay of online selling. Although it's great to have a visionary client who is shooting for the stars it's important that you help this client be practical and set reasonable expectations for what you can provide.
The key to helping this type of client is to establish a set of milestones and deliverables that provide realistic business value. The client may insist they need everything done before they launch but you can help them realize that there is great benefit in rolling out their big dream incrementally.
An e-commerce website can begin generating revenue, for example, as soon as there is a way for the customer to select a product and pay for it. Features like seeing recommended products, reading customer reviews, applying discount coupon codes, or making a wish list are all desirable and certainly improve the e-commerce experience. Your client can sell products without those features, though, and if you can convince them to approach their project in phases, they'll begin earning revenue sooner.
There are some types of projects, however, where it is critical to launch only when all things are in place. In cases like this, releasing a portion of the project to the public may not make sense but applying the same discipline in meeting milestones internally will still yield the benefits listed above.
Avoid unnecessary rework by getting feedback more frequently
One of the biggest problems with delivering to your client via the grand unveiling method is that you're presenting a finished product and your client is likely seeing several things they want to change. If you're "done" and they want to make changes that means you have a fun discussion about scope creep to look forward to!
Keeping your client in the loop throughout the project will minimize the amount of rework you'll have to do. Regular milestones and reviews provide necessary opportunities for course correction and adjustments to expectations for both you and your client.
During more complex projects, we'll often meet with the client after an initial database design has been formulated. We'll use the database diagram to facilitate a discussion about the project's requirements and ask questions such as, "Can a customer have more than one address?" or "Is a discount coupon code only valid one time per customer?" We find that many customers haven't thought through these issues and consequently not informed us of the exact requirements they'll actually need in the end. It's much cheaper to modify the database diagram to support multiple addresses for each customer than it is to modify the finished website.
Conclusion
Not all projects are candidates for this approach. Larger projects certainly support this method better than smaller projects. Even small projects, however, can benefit from a schedule which establishes frequent milestones to gauge and report progress.
A project isn't over 'till it's over and breaking a project into smaller increments doesn't mean you'll need to do less work. But setting frequent milestones throughout the project can help catch scope creep early on, keep the project team more excited, show your customer that you keep commitments, provide business value and revenue sooner, and reduce the amount of rework you have to do at the end of a project.
This article was originally featured on FreelanceSwitch.com.