Return on Software: Maximizing the Return on Your Software Investment

I have a copy of Tokey's book. The concepts covered are still relevant, as are the concepts covered in Boehm's Software Engineering Economics. I'd have to dig deeper to get more information, but if you're interested in the applications of economics to software development, I'd have to say that it's still a relevant book. It is a bit dense and can get mathematical, though.

I would like to deeper my knowledge about maximizing the return on software investment.

Why not consider maximizing value, bearing in mind that this is not necessarily the same thing?

Hi Ian,

Thanks for your reply.

Indeed that's a relevant subject. I believe value can be measured in several ways, and each stakeholder understands it differently. 

In my case, the client is a large corporation with 50k employees, several departments, and a complex relationship among them. My challenge is how to align the product's vision with all these people. Initially, I thought that financial measures would be the fastest and easier way to show results. 

We've conducted a 4 months long product discovery with a clickable prototype and several user testing. Now the MVP is in the final development stages (3 months total), and we are planning the continuous development for the next 6 months. 

Which questions would you challenge me to ask my client regarding value? 

Br,

7 months is a big leap-of-faith before receiving an MVP. In Scrum, the leap-of-faith is never more than one Sprint.

I'd want to know how value has been accounted for at all, by the Product Owner, over such an extended period of time. How has he or she maximized product value, given that no usable product increments were delivered and no progress has been empirically evidenced?

Bear in mind that value is not necessarily a dollar amount. Validated assumptions, which minimize the leap-of-faith being taken, are also valuable.

Thanks for your reply, Ian. 

Your question makes sense. Before start working with our agency, the client has never tasted the agile flavor, and one of our biggest challenges is dealing with their bureaucracy for internal approvals. During the first 1 month, we interviewed 20 people from our target group and understood their pains. In the second month, we've created the first low-fidelity prototype, and in the third month, we were testing the prototype. Only that was a great value to my customer. He has never had the chance to show anything tangible to their teammates. The fourth and fifth months were prototype iterations and interview after interview. We spent most of the time scheduling and negotiating time to talk to users. In short words, we've been showing users new stuff every 3  weeks, but the real MVP coded, tested, with accurate data connected to their ERP, had a 3 months scope. I tried to convince my client to reduce the scope to a minimum. Still, his main concern was that "an app that does not look ready won't interest users, and it'll create a bad reputation to me, I can't afford it, So during development, we keep users engaged showing new prototype ideas, the plan is working, and the MVP will be released in 3 weeks. 

Still, the main challenge is how to define value when the target group is composed my 5k employees from different countries, which have other challenges. Would you suggest cut down the target group only for a few early adopters and later expand as needed?

Appreciate your comments!."

If your client prefers work that looks ready, but isn't ready, then the work is not Done. That puts you and your client on a slippery slope with regard to technical debt.

In Scrum, a team would take care not to release work unless it is truly of release quality. Instead they would choose to cut scope. Closing the empirical feedback loop on Done work by engaging early adopters with a debt-free MVP sounds like a wiser strategy.

Thanks again, Ian!

I think our main challenge is how to implement the DoD properly. I'll try opening this topic to the PM team leader and see what he thinks.

Back to you soon, Ian, take care!