Y U No Tell me: Bigger Projects != Better Projects

This is the 10th post in a series called Y U No Tell me; Lessons learned from building a WordPress development business. For a list of all posts in the series, please start here.

At 9seeds we have a team of about 10 people. At any given time, each of us will have 1-5 projects on our plate. Each project will range in size from a couple hours up to about 40 hours. 40 hours is the sweet spot where our ability to estimate, schedule and deliver all come together nicely. I say that as if this was some great epiphany that struck us one day. No such luck. This is one of those lessons we learned the hard way over the course of many lost weekends cramming to complete projects that we over-optimistically estimated would be done by Monday.

That's not to say that we haven't had success working on larger projects. We certainly have. But when a large project starts to go off the rails, they aren't always as easy to get back on track. And if things go really wrong, the results can be devastating.

What went wrong?

Early last year we had a project that didn't go so smooth. I'm putting that too mildly. It was the type of project that makes you want to reconsider your choice to start a development company.

The first mistake we made, in the long line of mistakes, was that we didn't start out with a proper scope document. This mean that we were working with only partial information, and many decisions that would affect development still needed to be made after we started the project. This affects timelines, cost estimates and everything in between. I'd love to say that we handled those changes smoothly, but we didn't.

We spent a bunch of time working on the estimate which came out to somewhere close to $45,000. We then made the second mistake, we agreed to do the project at a discount. If you listen to nothing else I say, ever, listen to this. There are only two prices for which you should do work; your standard rate or free. If you are doing something out of the goodness of your heart because you want to help somebody out, you do that work for free. Everybody else pays full price. Working at a discounted rate is a recipe for disaster.

The third mistake was also a biggie. Although, we didn't really realize it at the time. We handed the entire project to one developer to work on. It became their full time job for far too long. There are several key reasons not to have only one developer on a project. The most obvious is that with 2 developers working on the project, it should get done twice as fast. But also, with two (or more) developers on the project, the developers would have somebody to bounce ideas off of who are intimately knowledgable about the project. Plus, if one developer becomes unavailable for any period of time, that project doesn't have to go dormant until they return. And if the client comes back later needing some updates on the project, you'd have two people who are familiar with the project which will save you spin-up time down the line.

When all our mistakes finally caught up with us, the project ended up going south in a hurry. By the time we completed the project, we were drastically late and way over budget. The client wasn't happy, we weren't happy and the developer wasn't happy. It hurt our relationship with the client and the developer. And our profits on the project were somewhere just below zero.

When you have a project go that far wrong, it's important to look back and learn from it so that you don't make the same mistakes again. For us, the biggest lesson had to do with the scope of the project. If we had done a better job on the scope, the rest would have fallen in place or at least would have been manageable.

The scope

These days when a prospect comes to us with a sizable project, the first thing we ask for is a scope document. We're happy to hop on a call to discuss the project with them, but without a scope document it's going to be impossible to properly estimate the project. If they don't already have one, we start by offering a research & discovery phase at a non-refundable flat-rate. In the R&D phase, we'll start by having a call with the client where we walk through the project with the client asking any and every question we can think of. Many times the questions we ask will stump the client and they'll need to go research with their team before they can provide an answer. Making the client think through their entire site is important because you never want to be guessing what needs to be built.

The deliverable for the R&D phase is a heavily detailed scope document. In our case, this will consist of a detailed written description of all aspects of the project, flow charts (if needed) of any processes that will take place behind the scenes and wireframes of the page layouts. The final document can now be sent as an RFP to any developer or agency the client sees fit. It is from this final document that we will then move on to the estimating phase.

If you think it's important to get an estimate right for a 10 hour project, think about how important it is to get them right on a 300 hour project!

The initial excitement you feel about landing a large project can quickly evaporite. Remember the Boy Scout's motto and Be Prepared!

I'll continue this series tomorrow when the topic will be Company Names.