You Better Plan to Stop Those Runaway Projects Posted 7/13/2007 by Geoff, Pres/CEO

Over the past several years as we’ve been growing this company we’ve encountered many challenges and frustrations along the way. Undoubtedly, the biggest and the most costly frustration has been runaway projects. Runaway projects are those projects that you estimate will take a certain amount of time and incur a certain amount of cost and they end up going way, way, way over budget. Not only do they end up draining resources, draining time, and causing financial loss, but they also frustrate the client in the process because the client was expecting a much quicker turn around on their project. Over the years, we’ve had our fair share of runaway projects.  But that’s part of the learning experience you go through building a business like this.

We’ve had some real killer runaway projects over the years.  I remember one from a few years ago where the client came in with around a $20,000 budget.  The total time we expended on their project was the equivalent of $200,000.  Of course, we incurred that huge loss ourselves because the client was unwilling, and rightfully so, to pay for the crazy overages because frankly we did a sloppy job of understanding and documenting the scope of the project to begin with.  This is an extreme but true example, and as you can imagine, you can’t have too many examples like this before your company goes under.

Since we’ve encountered projects like this in the past, we’ve made it a large focus internally to prevent runaway projects in the future. We changed our processes and our work flow to try to ensure these types of overages can’t happen again - at least to this extreme.

So how do you prevent runaway projects? The number one way to do it is to have an extremely clear understanding of the clients’ needs during the sales process and to document them. You must ask very thorough questions to understand how exactly the client expects their website to operate. Walk through every potential piece of functionality with them step-by-step so you fully understand the work flow surrounding any functionality. Ask questions to make sure you haven't missed anything. Integration with third party components and databases is one of the largest areas for time drain, so make sure you have thoroughly researched all third party integration requirements prior to setting your price. Once you have compiled this information, document it thoroughly in the form of a statement of work document so there is a crystal clear understanding between both parties as to exactly what you will be doing for the price listed.

In this statement of work document you need to be sure not to use any vague or loose terminology. For example, don’t use the world etcetera. Wherever there is any vagueness in the statement of work document there is an opportunity for the project to runaway from you - so be vigilant about not leaving anything open ended or vague.

The next step, once a statement of work is agreed to, is to put the project through an internal architecture process to architect out every detail prior to putting starting the design and programming. This architecture process is another opportunity for you to work with the client to ensure that you fully understand the scope of everything the client is trying to do. Through processes like wireframing you are able to give the client a visual representation of how the different pages will look and flow. This serves as another fail-safe point to ensure that your expectations are in line with the clients’ expectations and there are no surprises. Although it’s not good to have any surprises after the statement of work document is signed, at least if you discover these surprises during this architecture process you’re only a little way into the project and you can still make adjustments without it creating too much headache.

If you’ve taken the proper steps to write a thorough statement of work and architecture documents then no surprises should occur in development. However, clients do frequently change their mind about how they want their project to look or function. By having thorough statement of work and architecture documents, you can point out to the client that their new expectations are different from their prior expectations, and you can issue a written change order. This change order process should absolutely be followed anytime the client is changing project objectives or functionality, even if the change is not going to incur additional cost for the client.    

There is no absolute way to prevent runaway projects for occurring, but taking the steps above will help to significantly reduce the chances of a project running off course.

Share:

rating:

	Managing Client Expectations is Key! Posted 7/11/2007 by PeterV, VP, Marketing

My wife and I were just cleaning out some photos off the memory stick yesterday, and we came across this great photo.  This was taken on a vacation in Arizona. We currently live in Florida.  At first glance, I saw the sign and thought how ridiculous it was.  Then I realized they're just being honest.  Here in Florida, were always misled in terms of road construction.  All that does is set us up for disappointment.  At least Arizona can say they come in ahead of schedule!

The same is certainly true in the Web development arena.  Sure, it's a lot easier to sell a site design if I say it will be ready in a couple of weeks, but with the kinds of sites we do, that just isn't realistic.  Or fair.  A good site takes time.  You don't want to rush planning or creative.  And rushing programming or testing will just lead to more headaches down the road.

So hat's off to Arizona's department of transportation for setting realistic, yet absurd, expectations!

Share:

rating: