Metrics – BLOG:JUEL:ME

11 July 2013

Digitization

For a couple of years now, I have been working on various digitization projects, both in the private sector and the public sector. A common characteristics has always been the pursuit of cost cutting, meaning that the basic premise for even starting the project was to lower cost associated with a given operation or process. Most of the times, a business case has been created in order to prove the actual benefit of said project.

These projects have always been ran as IT development projects, and always with a pretty tight deadline. In my experience, the deadline itself will at some point be the holy grail of the project for pretty much all the stakeholders. Anybody who has been part of a project like this knows that when the deadline approaches, we start to redefine the scope. In SCRUM we will prioritize which features we want first and which features are less important. More often than not, the result is a system that does not live up to the requirements of the business case. Or in other words, the system cannot yield the benefits that the business case assumes, thereby rendering the return on investment calculation invalid.

Now, don’t get me wrong. I am fully aware that there many reasons why we change scope. There’s a resource aspect – if we prolong the project the cost of manpower is going up, if we don’t start production on a given date, we miss savings opportunities etc. My point is just that by going through this exercise we violate the principles on which the project was started in the first place. The next question would then be, are we in a better position after we have released something to production than we were to begin with? We can really only hope so. I would stipulate that the business case is doomed to fail, any which way you look at it.

I suppose it would be possible to apply an equation here that would allow us to determine whether or not to proceed with a project, if the feature benefits are out scoped. Food for thought at any rate.

21 November 2012

New methods

I have been in my new job for over a month now, and I a better grasp of the development methodologies. Obviously, I keep comparing the methods to how we did at my old job, since the differences are quite explicit. Whereas before I was submerged in a SCRUM world, I am now working in a team that applies a waterfall model for development.

In all honesty, the beginnings were a little difficult to getting used to. For many years I have been moving at break neck speed with a release every two to three weeks. On top of that there were the ever present bug fixes and panic solutions that characterize that particular organization. This is not meant as a negative critique of anything or anybody since I thoroughly enjoyed most of it. However, the stark contrast between the two methods does merit a comment.

The waterfall approach is without a doubt more cumbersome than the agile approach – that goes without saying. However, I am starting to appreciate the actual analytics that go before actual coding starts. Unlike before, it seems that there is time to identify problems and intricacies a priori as opposed to dealing with them a posteriori. I am pretty excited to see if this actually makes a difference when we start the coding, but I have high hopes that the development phase will be a lot more controlled than what we were able to do when I was apart of an agile team.

One could argue that the comparison in this is invalid, since the agile team made commercial software, and the waterfall team makes software for internal use, which basically changes the premises for the whole reason for developing a piece of software. However, I believe it is pretty valuable to experience both sides of the fence in order to ascertain which parts are useful, and which parts are not.

12 December 2011

Resource utilization

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 Winking smile