Simple Cost-Benefit Analysis

Wednesday, May 12 2010

I've been thinking about this for a while, and the catalyst for me to write about it was a short, simple post that Scott Watermasysk put up. It's so short, in fact, that I'm going to repeat it here in addition to the link (Scott, if you read this, and don't want it copied here, just let me know):

Before scheduling a meeting, try to use the following equation:

Number of attendees * $100/hr = MMC (minimum meeting cost)

Then ask yourself, would you spend MMC to hold this meeting? In my experience, the answer is no a vast majority of the time.

Pretty simple, if you think about it, and definitely true. I've had numerous meetings where the client pays me to sit on the phone for an hour (or more) to go over a few basic things that could have been covered easily in an email that would take me 10 minutes to write. Now, I don't mind getting paid, of course, but wouldn't it be a much better use of my time (and that of everyone else on the phone) and the client's money if that hour were spent actually working on the system they would like built?

Also, take into consideration the attendees of your meetings. Does a status meeting for a project that one developer is actively working on really require anyone more than the project manager and the developer? Isn't it kind of the project manager's job to pass any pertinent information along to all of the business stakeholders in the project? I have had meetings where there were at least seven people in the room, and at least five of those people were only there "for their information". One person taking decent notes during the meeting can provide that same group of people with the same amount of information and it doesn't take up seven total man-hours to do so.

This doesn't just apply to meetings, either. It can also apply to system features quite easily. It's a pretty similar formula:

Number of hours to develop feature * $100/hour (minimum) = total cost of feature

The number of hours to develop the feature isn't just development time either. It includes a lot of things:

  • Requirements gathering (Business Analyst)
  • Technical requirements gathering (Software Architect)
  • Technical design (Software Architect/Developer)
  • Test Plan development (Business Analyst)
  • Development (Developer)
  • Unit Testing (Developer)
  • Integration Testing (Developer)
  • Regression Testing (Developer)
  • System Testing (QA team)
  • Documentation (Software Architect/Developer/Business Analyst)

Even if you consider some of these items sunk costs (such as requirements gathering) since you can't actually estimate a time to develop without some form of requirements, that's a lot of steps and a lot of hours spent on a given feature.

A recent example I had with this involved a custom breadcrumb control for use in Telligent Community because the client wanted the site to have very specific breadcrumbs showing up on two pages (literally) in the Community site, so they would match some semi-related pages on their non-Community main site. My estimate was in the range of 30-40 hours to get what they wanted done, and that's even if what they wanted was technically possible (some of that time was just to research the capabilities of Telligent Community in this regard). At one point, you really need to question the importance of a feature, and I would say that the $3000 to $4000 range (as a minimum) would definitely be a time to start questioning the feature.

Another common example I have to deal with fairly regularly is designers that have a say in the final rendering on the browser, especially when the designers have no real background in HTML or CSS. Too many times to count I have received "bug reports" where the only issue is that the design is off by a couple of pixels in Browser A or in Browser B. Browsers render things differently - it is a fact of life that isn't going away anytime soon. Is it really worth spending thousands of dollars of company money to get a design 100% identical in every single browser, especially with fairly complex designs? At one point, a project manager needs to start saying no to those things. If you are looking for a cost-benefit analysis for making a website design pixel perfect across multiple browsers, you won't be able to find one. The reason? The benefit of doing this is zero, so any cost greater than zero is going to lead you to a benefit cost ratio of zero and a negative net benefit - telltale signs that you are throwing money away.

Some designers may try to argue that the benefit of a pixel perfect design representation is greater than zero, but all I have to say to that is those designers are wrong. The only person that is going to notice a few pixels difference is the designer that created the design. Anyone using the site is not going to know there's a difference or care in the slightest (as long as you don't tell your users that you are giving them a different experience than other users). In fact, I would guess that at least 99% of your users will never visit your site in multiple browsers, so they would never even have a secondary frame of reference to compare their experience to.

Yes, I know that spending all that time working on trivial things like this does make me money (and quite a bit, sometimes), but my job is not just to do what a client asks. My job is to make sure that the client is getting the best value out of their money and ends up with a product that will help them realize their business goals as efficiently as possible. Sometimes, this does involve questioning what the client wants. Helping a client see the value (or lack thereof) of a certain course of action is a very important and relatively simple task to perform. Convincing them may not be simple, but once the facts have been presented, there is little more that can be done - it is up to the client at that point.

Similar Posts

blog comments powered by Disqus