In software development, I have found that there is a solid, albeit cynical, rule about the expectations we should be setting for our clients and customers. This rule states that anything you plan to deliver will have, at most, 2 of the 3 following characteristics*:
- It can be done quickly
- It can be done cheaply
- It can be done well
Of course, you don’t want to list these rules in your negotiation process (sorry, but I feel I have to explicitly call that out), but you do need to keep them in the back of your mind. If the client is asking for all three, then at least one of those characteristics is going to eventually give. The first two items in that list are very tangible for you and for the client — due dates and payments are going to likely be your customer’s deciding factors in whether you get the contract — but the third is much more subjective, and harder to quantify. And perhaps using the word “well” is a bit of a misnomer; we must not ship crap. But there are ways to cut corners that allow you to get your product out the door on time, as well as within your client’s budget.
“We must not ship crap” means that we are not going to cut corners by cutting testing time. So if your testers say they’re going to need a certain amount of time given your current project scope, perhaps it’s time to revisit the scope. Does your contract say that you’re building a website and that you need to support browsers back to Firefox 1.0, Safari 2, and Internet Explorer 5.5? How will it affect your timeframes for development time and testing if you were to bump that to Firefox 2.0 or 3.0, Safari 3, and Internet Explorer 7.0? And perhaps, in addition to this website, they want 3rd-party API support, a custom Content Management System, and integration into their internal intranet that was developed by some highschooler six years ago for his senior project? Respectively speaking, could you defer part of the scope until a later release, use an open-source solution that meets all of the client’s requirements, or take the opportunity to pitch some new business (which may extend the timeframe, but see “defer”)?
There are a new set of challenges around how to work with a “deferred” or “enhancement” project plan, but that’s an article for another day.
One last thought: The characteristic of getting something done “cheaply” is not directly proportional to the financial responsibility to which the client is agreeing. If the customer agrees to a price that they believe is fair, but the developers, designers, and testers are keeping their noses to the grindstone nights, weekends, and lunch hours, you have assumed the extra cost; the project is no longer done cheaply. The return on investment that you will be getting from the people entrusted with building this product, if carefully quantified, will drive the overall price of the project shockingly higher.
*The initial “Two of Three” rule was outlined to me several years ago without much explanation by a professor. Over the years, I have had time to reflect on it, and it has not only held true in software projects, but also across other industries. I hope that you can find its applications in your own line of work.
0 Comments.