Last week I went to a Tech Talk at Microsoft where we talked about Lean Product Development, a topic that is near and dear to my heart. One of the main points was that resource utilization of 100% is not necessarily a good thing. Those of you who have a project manager or two breathing down your neck every day, know that they are usually looking to reach 100% utilization, because in their world that is where we reach optimal productivity. Now, don’t take this as me bashing project managers. They also have people breathing down their necks, because they have a release to deliver. If anything, this post should be seen as a polite reminder to top management that product development is very difficult to fit into an Excel spreadsheet.
So, now that I have gone to great lengths to be civil to everybody, what is my point? It’s very simple; the unpredictability of the software development process is so explicit that we need to leave room to fix the things we were unable to foresee when we planned the project. Don’t get me wrong, there are things we as product people don’t necessarily need in order to launch, but let’s face it, most of the time we deal with the issues that will severely impede the use of our product unless they are dealt with properly. By subscribing o this notion, I have essentially said that slacking on quality is a non-option. This leaves time and scope as the only variables we really want to touch.
I am pretty sure it is easy to come up with examples that contradict my point, however, there’s a reason why I think we avoid 100% resource utilization and why we should never compromise on quality. Uncharacteristically, the argument is an economic argument, and ties to my earlier rants about the brand. We cannot afford to have our users, and of course decision makers, being negative towards our product. The negative connotations and the reputation we encounter in the marketplace if our software “doesn’t work” will most likely impede impede on our ability to perform in the marketplace.
If we produce a Saas application, our financial model is based on an investment in a generic product, which more or less works for everyone. So, if we view our Saas application as our asset, we can calculate the Return on assets. Basically, our return will be dependent on our ability to resell the application after we have reached the break-even point. If we decrease the brand value in the minds of our users, by creating software that “doesn’t work” we are most likely not going to be able to capitalize on our initial investment.
ROA=Pnat:A
Where
ROA= return on assets
Pnat= net profit after tax
A= assets
In all honesty, I have never applied this equation to my own real work life, mainly because it is not something that is really part of my everyday tasks these days. However, I think that equations like this can work as powerful tools for PMs, when attempting to persuade management and other stakeholders why we should never go with a 100% utilization of resources.
I will update this post if my own CEO buys it 