QValue - Managing Your Technology Portfolio by Value

Over the past few years, I’ve created a Portfolio Valuation model that helps organizations develop a set of strategic value factors that when aligned with a comprehensive intake and planning process provide a value-scoring mechanism that will prioritize and fund work for their teams.  The model is called QValue which stands for Quantifiable Value.

 QValue design is based upon the Efficient Frontier model, created by Dr. Harry Markowitz.  This model is leveraged by investment fund managers across the world and provides them the ability to build a portfolio of securities (investments) that will yield a maximized return relative to accepted risk.  To simplify the intent of the model, it essentially helps fund managers develop an investment fund that maximizes the return they seek within the context of quantifiable risk.  Fund managers create investment portfolios that contain a set of securities that will be expected to provide a stable return, from which fund participants can select various portfolios in their 401k and stock portfolios to reflect their individual investment risks profile.

Organizations need to take a similar approach to manage their technology investments.  Your organization is the portfolio, and all your technology projects and initiatives are the various securities that when combined should provide a quantifiable return relative to quantifiable risk.  The QValue scoring model provides the framework for your organization to build a risk/return profile for all your technology investments, providing you with the ability to quantify value directly related to your strategies.  This represents a fundamental mindset shift from traditional cost management approaches to project funding.

You can’t effectively improve the flow of work to your teams if you don’t have an effective way of planning and prioritizing by value.  Non-value-based planning with its focus on cost benefits does not provide the most effective way to plan and prioritize with its lack of focus on value and return.  Understanding the actual return, you are getting from your team’s work, allows you to make better investment decisions and not over-invest in work that has diminishing or little value related to the cost of development.

Rethinking Your Organizations IT Planning, Investing in Value

If your organization is typical, then you spend anywhere from 4%-9% of your annual budget on technology projects. The key word here is budget. If your focus is on a budget, then the way you plan your technology projects will inherently be centered around the cost of those projects. Though we typically accompany these projects with lofty rhetoric identifying the benefits of doing this project the reality is that we don’t quantify outcomes and the focus of the project management of these projects is on budget and scope.

To begin to reshape your mindset that emphasized cost, you need to adopt a modern investment theory that quantifies both the risk and return for specific investments (aka stocks or bonds) that are part of an overall portfolio of investment. To apply an investment approach, you need to view your organization as a portfolio that would include work to enhance business capabilities, and process improvements, as well as to ensure your infrastructure is stable and up to date. A portfolio is a diversified set of individual securities (eg - technology projects) that have a portfolio objective associated with it that defines the risk and return that the organization is willing to accept as managing their investments.

By moving to an investment mindset, you change your focus towards quantifiable outcomes that are strategically aligned as defined by your portfolio/organizational objectives. Too often annual planning processes concentrate almost solely on the cost of the project. Making investment decisions based primarily on cost, we miss the important value conversation that must come with it. We need to know if the cost of acquiring the value exceeds the value returned. We want to make informed decisions before investing. This is the only way to maximize ROI.

My QValue Technology Investment Model provides organizations the ability to quantify both tangible and intangible value so that we properly diversify our IT investment across the organization.

Moving from Project to Team based Funding in Agile

When we move to Agile we typically form our teams and then happily keep our waterfall project based funding structure in place.

We do this for a few reasons:

1. We think it’s the only way to show the cost of the work that we are asking to be delivered.
2. Projects are easily understood from an operational standpoint as they have a defined start and end date which is tightly aligned with the cost of the project.
3. It’s the way we’ve always done it.

As part of our project based funding model we have an annual project funding request process, where we  spend weeks/months identifying the things that we think are important (note I’m not using the word valuable here) so that we can obtain funding.  Things move above or below the approval line and when the dust settles we have a book of work that is committed to, with freshly minted project plans and a cadre of project managers to manage the money we just gave to these projects.

An annual project funding request process also means that we ask for what we need and then everything else we may or may not need.  We ask for a Ferrari when perhaps all we need is a good dependable family sedan.

There is power in money, who has it and who controls it typically drives what gets funded and what doesn’t.  It’s not uncommon for Sr. Leadership to commit to work even though their team doesn’t have any experience in the product solely to get the money to keep their teams funded and employed.

If you see a lot of potential waste here then you are correct.  We see waste just in the amount of people and money needed to manage our project money.  If a money market fund had as much overhead associated with it, I and everyone else would leave because that overhead just cuts into profitability. 

Next let’s more waste related to developing the stuff we didn’t need and may not actually use.  All of this extra stuff we develop has an expense associated with it and this is a long term expense.  We have it built into our architecture negatively impacting our systems scalability, performance and security.  We have to test it every time we build new stuff.  Bet you didn’t take that into account when you did your Cost/Benefit analysis for the project.

When we move to Agile we have an ability to really simplify our IT funding function.  It’s really quite simple – it’s the cost of your team. 

In most organizations this cost typically hovers around ~$40k per sprint or over ~2 million annually.  So as a financial manager trying to manage things like cash flow, depreciation and the like, this makes financial reporting much simpler.  Each team becomes a fixed line item cost on my balance sheet and operating statements.  I don’t have to worry about cost overruns from project funding since the team is a fixed cost.  Product Owners ensure our teams work on the most valuable things in a consistent manner and at the end of the year we should/can be able to gauge the value of that work to some accuracy.

So here’s a challenge that we face, how do we actually assess value?  How do we value things like reducing technical debt to make applications technically better?  How do we value writing an input validation security framework that makes our application safer for the user and ourselves?  How do we value things that our customers aren’t asking for, but in the end benefit from?  That is the core element of software development, there is significant value in the things that the customer never sees yet we place little effort or priority in delivering these elements.  Instead we focus on the visual functionality and throw quality and architecture down the drain in favor of meeting project timelines.

If you get the fact that you have a fixed development cost it actually should foster better conversations regarding what is really valuable for the entire organization to be working on.  Not your pet projects, not the projects you agree to only to get funding to keep your people employed, that’s not how real value and efficiency happens and it’s time we stop thinking that it does.

Agile highlights very quickly that an organizations planning and funding functions are broken. It also typically becomes clear that we don’t have a real grasp on what our real value streams are and finding them often means removing political barriers that have built up over years.  Agile requires that we redefine what value is and organize our delivery across these streams over organizational silos.

The traditional PMO also goes under a dramatic shift, moving from managing projects and funding to ensuring that programs align to the organizations value streams, are well understood and organizational impediments are removed for the teams.

So if you are looking to move your organization to Agile you must understand that your funding and planning functions must change to align to a new mindset and paradigm.  Funding is easy in Agile, really it is (remember it’s the cost of your team), uncovering your value streams and maximizing the work that flows to your teams that delivers that value, now that’s harder (but not impossible).