by Aaron Froehlich

The Project Management Triangle is a useful framework for understanding the inherent tradeoffs in project development, regardless of the industry. The three corners of the triangle represent three competing values—scope, time and cost—while the triangle itself represents the overall quality of the product. Because the values are competing, it is literally impossible to prioritize all three: to do something quickly with many features will be expensive, quickly and inexpensively requires fewer features, while inexpensive and full-featured products take longer to build. For many web development companies, however, there is a relatively simple solution to the problem: convince the client that they can get all three, and then hide the quality tradeoffs from the client long enough to get paid for the work.

Over the past year we've "inherited" a handful of websites built by other firms who specialize in building products, but "don't do maintenance work." If that doesn't sound alarm bells in your head, imagine walking into a dealership and buying a car from a company who refuses to repair their automobiles, or a house from a builder who doesn't offer a warranty. What we've found is unsurprising: these clients' budgets are getting exhausted fixing bugs instead of adding new features, and new features themselves are more costly because of the brittle and/or patchwork nature of the original code.

Unfortunately, there are very real business pressures that drive decision-makers to choose lower cost vendors, the obvious one being project budget. Often, the budget for a project is fixed, which can leave a company feeling like they have no option but to choose the best of the low-cost proposals. This budget pressure is frequently compounded by real or perceived timeline pressures. What the decision makers can easily miss is 1) that cheaper alternatives shift costs from initial development to the maintenance phase, and 2) that there is a better option for them to consider that will give them a high quality product within their budget constraints.

Regarding the first point above, it's easy to overlook or underestimate the ongoing maintenance costs that will impact the Total Cost of Ownership (TCO) of your product. A wide range of factors can contribute to ongoing maintenance costs, such as the experience level of the developers, the design choices they make, how they choose to incorporate 3rd-party modules and APIs, and how well they understand your business needs, to name a few. While the technical nature of some of these factors may make it difficult for you to evaluate your vendor choices, other indicators can be really helpful, such as the number of long-term clients they have (and whether you can speak to them), whether they're tracking internal metrics such as the percent of time spent on bugs for a given project, and whether they write automated test suites for their products.

So what can you do if the company you want to work with is outside of your budget range? The Project Management Triangle provides the answer, but a story might help to illustrate. Recently, we bid on a project that we were well-equipped to handle. The technical requirements closely aligned to a project we had just completed, and we had a pretty clear picture of what it would cost to deliver the product. Unfortunately, we were also the highest bidder. To the client's credit, however, they recognized the strengths we would bring to their project. The timeline was fixed, as was the budget. "Okay, how much functionality can you deliver within our budget," we were asked.

The solution at which we arrived recognized the limitations of the Project Management Triangle. In this case, they were willing to reduce the scope of the project, and we are now happily working on delivering a high-quality, well-developed site that will meet enough of their functional requirements for this first phase. Even better, we're developing a trusting relationship so that they can continue to add features over time, and as their budget allows.

Obviously, I believe that this client made the right decision. Current research is also indicating that I'm right. Last month, the Harvard Business Review published the results of a fascinating macro-analysis of 25,453 companies over the course of more than four decades*. They were looking for patterns in the data that could explain greatness, and ultimately decided on 3 rules for success.

1. Better before cheaper
2. Revenue before costs
3. There are no other rules—change anything you must to follow 1 & 2.

I highly recommend the article, which offers an intriguing lens through which to view business decisions. A full discussion is outside of the scope of this article, but the first rule is particularly relevant to this conversation, and can be applied to both sides of the client/vendor relationship.

At Singlebrook, craftsmanship is one of our core values, and it permeates how developers think about solving technical problems. Because we prioritize feedback as an important tool for growth, our developers submit "pull requests" to other members of the team, which are basically opportunities for peer feedback on the code we're writing. Over time, not only do our developers improve and grow, but the code we write becomes more flexible and maintainable. I've also worked on teams where "better code" was not a priority, and unsurprisingly, thought for a long time that code debugging, rather than code crafting, was the essential role of a developer.

If you're a client, then there are some really interesting trends in software development for you to consider as you evaluate what "better before cheaper" means for your project. I highly recommend reading about "lean software development". You're not alone if you cringe at the thought of removing features from your RFP. Lean methodologies, however, promote the idea of a "minimum viable product", or MVP, which may be surprisingly smaller than your current vision of the product. If you work with a company that understands lean and how to use it, they can help you find ways of testing your assumptions about your product, and building cheaper alternatives that will help you verify that users actually want and will use the features before you pay to build them.

Unfortunately, not everyone in your organization is going to understand or agree with the Project Management Triangle. As one client recently told us, "oh yeah, I'm familiar with that. But in our case, we have to prioritize all three." It is my sincere hope, however, that by bringing this shadow side of web development to the light, you'll be better equipped to evaluate those tradeoffs as you choose your web development partner.

*See the April '13 issue of The Harvard Business Review, Three Rules for Making a Company Truly Great by Michael E. Raynor and Mumtaz Ahmed