J.D. Meier's Blog

Software Engineering, Project Management, and Effectiveness

Paul Lidbetter on Value Realization

Paul Lidbetter on Value Realization

Rate This
  • Comments 5

This is a guest post by Paul Lidbetter.  Paul is a seasoned Enterprise Architect on the Microsoft Enterprise Architect and Strategy Practice in the UK.  His specialty is business value, strategic alignment, and Cloud transformation opportunities with customers.

Paul is also an active member of the Innovation Value Institute Consortium, a Chartered Engineer, Fellow of the BCS, and member of The Institution of Engineering and Technology (The IET).

Without further ado, here’s Paul on Value Realization …

Value realization is talked about, but is less frequently achieved because it is hard to deliver! Value realization tends to be thought of by many organizations as the magic that will happen at the end of a project/program.

Value Realization has evolved to become one of the most used phrases in project proposals, value propositions and investment discussions, but do we really know what the implications are or what we are promising by agreeing to Value Realization as part of a program of work?

Cost of ownership and business benefit measures have been and are still used as the focus for a business case, which is, at worst, simply a gate to justify a business investment, after which any focus on managing and delivering the expected business benefits, from the agreed investment, is long forgotten.

Why Value Realization is Hard

In my experience Value Realization is hard because it assumes some level of maturity for process, reporting, measures and decision making, as part of a value based culture, which supports long term ownership of change and value management over extended time lines. For example in the worst cases I have experienced;

  • The business that has little intention of making real changes and hence business and IT projects tend to stop at deployment and focus on tracking costs as a success factor. Hence Value Realization as part of a program is not on the agenda.
  • There is some focus on enabling change, but there is no consistent intention by stakeholders to actually deliver measured benefits and the business also has little expectation, based on existing cultures. This also makes it hard to measure value consistently as well as the business value that 3rd party services have delivered to a customer.
  • IT is measured on meeting deployment milestones and therefore has little or no interest in aligning to the business let alone ensuring that value is realized.
  • The investment period covers several years and hence the original stakeholders are long gone and who can remember what the project objectives were let alone what the Value Realization measures were….indeed is the project and benefits still relevant is a question often thought, but not so often asked.
  • Value Realization as a process at best becomes focused on the benefits (which may become a sub set of the original benefits as time goes by) and also forgets about the investment component. Program delays increase investments and may result in lower benefits both of which impact the NPV thereby reducing value regardless of any previously agreed financial measures. This can create a false view of the impact of what was realized on capabilities and also future decisions.
  • The benefits promised were not realistic, were not tangible, easily measurable and hence never achievable.

Value Needs to Be Measured Over the Life Time of Change

As Value: = (Benefits - (Operational Costs & Investment-Capital Costs)) Realized Value is impacted by delivering more or less benefits and/or incurring more or less costs/investments needed to deliver such benefits over time. Indeed the investment is very much part of Value Realization. Value therefore needs to be measured over the life time of the change, for example some metrics may be evident early in the adoption cycle and others such as overall ROI may take years. Because of the time line, investment time/resources needed tend to increase and benefits fall/become less relevant with time, thereby leaking value from the business also impacting opportunity costs.

Value Realization vs. Potential Value

Realization means that the value defined by the business case (or agreed sub set) is actually delivered, is visible and has an agreed impact on business goals, KPIs, revenue and budgets. Until value is actually realized it is remains as potential value and no more. For example finding a cost saving and then not reducing budgets or reallocating the funds to drive new opportunities is not Value Realization, it is pretending that value has been delivered.

clip_image002

A more top down approach may increase accountability for delivering benefits, but the very same people may not want the benefits (e.g. they see dis-benefits based on cuts to their budgets, staff, maybe major personal and career change), or they may want the benefits, but are still dependent on another group, who may own the budgets/resources and have other priorities on time and resource, to enable solutions and deliver change.

So stakeholder management and alignment are key issues that can be a source of delay and indeed failure to optimize Value Realization.

Value Realization Needs to Be Planned from the Start

Value Realization therefore demands a value culture or shift in an organization around value governance and increasing levels of maturity/capability to focus on qualifying decisions based on Realizable Value and managing value as part of delivery programs. Hence, successful Value Realization needs to be planned as part of any project/program from the start, not in panic at the end of the project based on smoke and mirrors. Of course if there are no defined measures to start with then smoke and mirrors can work every time.

It’s No Longer Good Enough to Pretend that Value Just Appears

Value Realization is/should become more critical to organizations as the ability to source new cloud services and capabilities accelerates and lowers the risk and costs for the design and deployment cycles, thereby throwing the internal focus on doing the right things and ensuring value is being created within shorter cycles. This is further driven by both business and accelerating technology trends which in some industries can be enabled to deliver value faster for competitive advantage. Being able to demonstrate that a program has delivered on time and on budget is no longer good enough, pretending that value just appears is no longer good enough to remain competitive.

Accelerating Business Value and Driving Adoption and Change

Some organizations focus on realization in the short term, in order to mitigate this issues above and also to ensure that opportunity costs are maximized. Indeed some organizations I have worked with, both commercial and public sector, have banked the benefits at the start of the project. For example a CFO reduced the travel budgets at the start of a Unified Communication program to accelerate the program, business change and adoption. The final value delivered is still dependent on the overall level of investment, but this did drive behavior and accelerate change.

A Focus on Value Integrated into the Program Management Office (PMO)

In a Telecommunications customer, although the initial discussion was with IT and around deployment, the focus for change was in fact the business (HR), which allowed both relevant measures and accountability to be established. Also the focus on delivering value was integrated into the PMO and associated change managers which enabled the Value Realization process to be part of the overall plan, as part of a Microsoft Enterprise Strategy Services engagement. In addition the number of measures where kept small and easy to verify. E.g. a cost saving metric, a productivity measure and a program acceleration measure (to demonstrate the value of the Microsoft Enterprise Strategy Services engagement)

Providing Snap Shots in Time of Value Realized

A further example from a financial organization had some of the challenges, but the approach taken ensured that a culture and process change was slowly introduced with support from Microsoft Enterprise Strategy Services. Projects/Programs were delivered with measures that were more about cost and time, but in order to demonstrate the value of both Microsoft Enterprise Strategy Services and customer projects, some projects were evaluated for post Value Realization in which the benefits were signed off ( or not, by stakeholders) and accumulated with investments to provide a snap shot in time of value realized. Importantly this also allowed potential value, to be identified along with a portfolio based value management process and relevant accountabilities to be successfully introduced moving forwards.

How To Enable Value Realization

Some of the key enablers are therefore;

  • Ensure the IT project/program is aligned to measurable business goals, or if not, then the focus is a default reduction of the IT Budget/improve Productivity.
  • An IT focus may be on transformation, for example moving operations to the cloud, which can drive hard strategic and metrics such % services on line, % reduction in data centers by a given date. Clearly the value focus is what does the transformation deliver? In terms of costs, Co2, business measures etc.
  • So in the last point the projects are measured on realizing the change to how services are delivered, the overall programs for transformation will be ideally measured on the business value enabled.
  • For effective change, adoption, and Value Realization, there needs to be good integration with the business change managers and the PMO so that adoption is planned alongside user scenarios and as part of deployment.
  • Use awareness, pilots to test scenarios for Value Realization and measurement options, this gains both business and user confidence based on outcomes and mitigates risk before a full business case, Value Realization plan and roll out.
  • Value management, processes and governance is based on clear roles and responsibilities. Focus on shorter delivery cycles where possible, to minimize risks, gain early wins and maximize ability to manage value.
  • If Value Realization requires significant change then top level sponsor needs to demonstrate adoption and drive incentives…..commitments, STOP other approaches, emphasize and communicate success….learn from mistakes and also success.

Value Realization is a powerful tool when you use it as an approach to help connect business and IT, justify investments, accelerate business value, and drive adoption and change.

You Might Also Like

Martin Sykes on Value Realization

Mark Bestauros on Value Realization

Graham Doig on Value Realization

  • These are good real world observations and ideas to overcome the far-too-common challenges we face.

    They also highlight that the Enterprise Architect's ability to understand, influence, drive and overcome non-IT challenges, e.g. personality, politics, financial disincentives, etc. are critical to success.

    Even after a "perfect deployment" these are the skills that are essential to value being realized, being actually measured, being communicated, and finally, actually being accepted by the key stakeholders. Thoughts?

    Imran Anwar

  • @Imran, thanks for the comments and yes these skills are becoming more essential for business success. The key issues is that these skills and involvement are required from the start and not just pulled in after deployment. I guess a question is do Enterprise Architects have these skills?

  • @Paul, thanks to JDM for posting this and helping get this conversation going. I would say that most of the colleagues I have met in Microsoft's Enterprise Strategy Program have the business savvy to cover many of these challenges. But it is all likely experience we acquired in life, work and years before joining Microsoft. I do not personally believe that formal EA programs provide enough of this angle in what they teach. But that is my subjective opinion. I also believe that too often sellers of EA type engagements do not totally understand the extra non-IT value that Enterprise Architects bring to their mutual customers. Lots of opportunity for more education all around I'd say. :)

  • Absolutely a wonderful article!  I can refer to a few customers who are looking at advances in their architecture organizations and most are looking squarely at how do we talk about value, measure value, and show it back to the sponsors of various projects.  There is a big challenge from the business side to justify the prevalent per-user tax, which often seems from the outside of IT to not return anything but a list of technologies implemented (i.e., not positive change for the users we're trying to enable).  

    On the practical side, a couple of pieces that might go along with this include shifting the funding mechanism to business-justified projects (how many times do we as architects have a value capture artifact and really just put project costs in there?), aligning IT portfolio of projects to business needs (how often do we prioritize an upgrade of an infrastructure system over a new capability for a smaller LOB?), and getting familiar as architects with constructing value cases.  

    Warren Buffett is famous for saying "cost is what you pay, value is what you get."  As a core part of architecture, we should challenge ourselves to frame problems in terms of what the customer is measuring, less on what resources we would need.  Even though not everything can be measured in currency terms, every change we make - especially as many businesses really are IT businesses with the basic work processes automated in computer systems - can be qualified in terms of benefits which can be measured at the end of the project.

    Thanks, Paul, for the great article!

  • Thanks for comments and great discussions.

Page 1 of 1 (5 items)