Software Engineering, Project Management, and Effectiveness
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.
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;
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.
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.
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 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.
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.
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.
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)
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.
Some of the key enablers are therefore;
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.
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, 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.