In this interview, Michael Harris, the president and CEO of David Consulting Group, explains his five-step Value Visualization Framework. He discusses how he came up with the idea, how it can help your team right now, and its similarities to the agile methodology.
Josiah Renaudin: Today I'm joined by Michael Harris, the president and CEO of David Consulting Group. We'll be covering his five-step Value Visualization Framework and the significance to your team or organization.
Michael, thank you very much for joining us.
Michael Harris: Thanks.
Josiah Renaudin: All right, first, could you tell us just a bit about your experience in the industry?
Michael Harris: Sure. I've done a lot of things in the industry, so I guess it's been over thirty years now. Most recently, for about the past ten years, I've been president, CEO, and owner of David Consulting Group. We focus on helping our clients improve their software development. More and more, we focus on helping them deliver value from software development, and that theme's going to come back again and again as we talk today, I think.
Before that, I was head of a fairly large software development group and a company called Sanchez Computer Associates, who were acquired by Fidelity Information Services. A lot of my thoughts, lessons, challenges that I see in the industry have come from that time.
Josiah Renaudin: Now, before we really dig into the meat of the interview, in short, can you explain your Value Visualization Framework for the software development lifecycle, and how you came up with it?
Michael Harris: Sure. Maybe I'll answer those questions in reverse order. How I came up with it was that I've been both in the trenches and working at an executive level with teams doing software development, and what I see happening is that, although within the context of software development all the developers, all the testers, all of their team leads and everything else work with the best interest of moving the software forward, often there's a disconnect to the business in terms of what the business actually gets out of it at the end.
This was brought into sharp focus in some work that I did in the UK with a major client in the UK probably about two years ago now, where there was a tremendous amount of money being invested in software development. It was core to their business value proposition, and yet the businesses were turning around to their software development and asking him to justify the value that he was providing for the money they were investing, and he couldn't do it, it was hard to do. He had a tremendous number of metrics, knew exactly what productivity was, was working with a lot of offshore vendors, but couldn't actually pull out a statistic and say, "This is why we're delivering value." As we dug into that a little bit, we saw that half of the problem was the business actually wasn't really providing the information to allow the software development group to prioritize by value, as opposed to prioritizing by other things.
Over a period of time, what's evolved is this Value Visualization Framework. It's a way for people in that sort of situation of, "Justify what you're doing and maximize the value you're delivering to us." To actually go through a series of five steps and come up with some metrics around value. This has to be a collaborative process, so when I talk about the five steps, the first one is to define the units of value delivery. You can't do that without a conversation between the business and the software development group. The units of value delivery might be, say it's a website, it might be the number of subscribers, it might be the hours saved in a particular business process if it's an application for in-house staff. There's a unit of value that the business consider, "We'll be getting value if we have some of these units of things.
Then for a particular project or story or feature or epic, you need to define the value of that particular story or epic in specific units. If we're using number of subscribers for instance on a new website, then you have a number for that, so, "We think that this particular story or epic will produce maybe fifty new subscribers once we deploy it." That really is, again, a heavy interaction with the business, but now the IT and the software development team have to come in and say, "Well, just how big do we think this particular story might be?" We can define the size in a number of ways. What we're really looking for here is to get an agreed view, an early stage of, "Is this complicated? Is it going to require a lot of resources? Is it going to take a lot of time?" Story points is not a bad proxy for this, but there are other things you can do it with function points and other things. The key is that step three is to define the size.