WISHBONE

One Size Does Not Fit All

One of the main issues we development agencies face when engaging in the bidding process on projects is that we often cannot gauge the complexity of a project until we are in the throes of it. Some clients appear to know precisely what they want— come equipped with Word docs of content and folders of image files ready to ftp— but in reality, what they think they need quickly changes in development and we face issues of scope creep.

Many of you have also witnessed the demise of agencies with tons of potential to succeed. We have seen projects that paid $8,000 in which the cost of development was calculated at over $20,000. Venture capital or not, a business can’t float long on those numbers. We have to avoid, at all costs, getting upside down on projects. We, and others like us, run a very real risk of misallocating time, miscalculating resources required to complete a job, and losing everything that experience and our wits have helped us build.

In the old days, we had a very clear picture of what it would take to put a company’s brochure on the Web. Content could possibly change a dozen or so times a year, competition wasn’t overwhelming, the sites were fairly simplistic in function although they could be quite complicated in look and feel/design. We spent a lot of time building websites that were very beautiful with tons of Flash that existed to be an online elevator pitch/ad for a company and nothing more.

Today we operate a Drupal shop. Drupal, at its very core, provides the basic building blocks that create complex web architectures by exploiting database relationships. How these relationships form, relate to the data, and transmit new results (content) to the site are highly involved algorithms. Sometimes the relationships present a new puzzle, one that has not been tested in Drupal, something that has to be developed, tested over time, ensured by the client to have the desired results. Often, more than not, the clients decide that their needs change midstream— often because they failed to grasp the potential of Drupal on the outset— more often because viewing their idea in development gives them new and improved ideas. All of this is fantastic fun, of course, until you examine the hours spent on the project and realize that it has been grossly underbid and that every 2 hour conversation you have with the client is leaking the lifeblood out of the business. The biggest time-wasters, we have already discovered, occur with the addition of a middle man, project manager, account manager who deals directly with the client and actively participates in the the ever-changing scope.

I don’t want to sound all doom and gloom, like there is no hope for a streamlined pricing structure in which sales partners can hope to obtain estimates. There are dream clients out there and for those one could give highly competitive consistent prices all day long. But far too often the scenario is like the one described above.

Some questions to consider for agencies hoping to sell web development and act as front men for your multimedia agency: If there was a standard pricing structure, would they write in the ability for you to bill them separately and additionally when the project left scope? If a sales team would be willing to provide some level of insurance for us, as developers, in working with their clients, then it would make our ability to provide general pricing easier. Do technology salesmen understand the nuances of Drupal development? Do they understand that varied data requirements coupled with varying user permissions (for instance) take an octopus with 8 legs and give it hundreds of tentacles? The complexity of a website changes exponentially when new and varied requirements are introduced to the database.

Would a proposed sales team be willing to have us (the design/development agency) interface directly with the clients on the web project? Sales could act at PM, but for the process to be efficient, the middle person must be removed during the development cycle. Don’t you agree?

To this point, we have been able to see success in our endeavors because of our efficiency. Bid a project, develop it, deploy it, bill it— repeat and rinse. We will not succeed in the rhythm of: bid a project, talk it to death, wait around for rooms full of people to decide what the product is, listen to tons of discussion about the design, listen to arguments about the content, redesign, redeploy, leave up as a test site, train site managers, retrain site managers, never get paid, lose money, lose time, go insane...

How can we communicate the need for the pricing schedule to be slightly modified on a case by case basis due to the myriad nuances involved in web application development?