Value Realization

Value realization, rather than potential value, is the value agreed to be delivered in the business case or original proposal that is actually achieved. JD Meier has two great guest blog posts on value realization. Understanding value realization is to understand what the customer values, execution to deliver that value through change + measurement.

Delivering a project on time and within budget is a part of value realization, but the entire story also includes the customer getting the return on investment (ROI) that was defined in the business case at the beginning of the project. To be in the game for the long-term and build a client base with repeat business it is not good to enough to only deliver a project on time and budget, but to make sure the value was realized by the customer.

Paul Lidbetter on Value Realization

“Paul is an Enterprise Architect on the Microsoft Enterprise Architect and Strategy Practice in the UK.” Here are the main parts of the topic Paul goes over.

  • Why value realization is hard.
  • Value needs to be measured over the lifetime of change.
  • Value realization vs. potential value.
  • Value realization needs to be planned from the start.
  • It’s no longer good enough to pretend that value just appears.
  • Accelerating business value and driving adoption and change.
  • Focus on value integrated into the Program Management Office (PMO).
  • Providing snapshots in time of value realized.
  • How to enable value realization.

Martin Sykes on Value Realization

“Martin has been involved with Enterprise Architecture and IT Strategy for 15 years and is today a coach in Microsoft Service’s Enterprise Strategy Centre of Excellence.” Here’s the main parts of the topic Martin discusses.

  • Value is in the eye of the customer.
  • Who cares?
  • What is value?
  • How can we be sure we are getting what is promised?

Invent to Learn: New Book About Makers

There is a new book titled Invent To Learn: Making, Tinkering, and Engineering in the Classroom that I came across recently. I have not read the book yet, but wanted to share it for the people interested in 3D learning, or how 3D printing or makerspace culture can be used to help teach students.

Like how the web changed learning with Google, Wikipedia and YouTube how-to videos, the new makerspace culture and tools will change how students learn a decade from now. The change will happen whether schools endorse it or not, but the teachers that embrace it will better prepare their students for the future than those that ignore it. For years, Wikipedia and other online resources was shunned by the school establishment in favor of paper books. A decade later, encyclopedias aren’t sold in large quantities door-to-door or on software DVD. Most information is available on the web.

All Work Is Not Created Equal – Work Smarter

There is urgent work and then there is important work. Are your conversations with your co-workers or subordinates centered primarily on when something is going to be done, if it is done yet or how much effort something is going to take and medium or high efforts are shunned. Then maybe the outcome of all your hustle and hurry will be low-value unimportant work.

What’s a smart way to differentiate demands on you or your business? There is demand on our time and effort from value and failure. John Seddon described value demand as work we do for the customer and failure demand as work we must redo or failed to do properly for the customer. He says that one of the fundamental issues with how a lot of service organizations organize work, is that they treat all demand as units of production. In other words, all work is work to be done. He describes a smarter way of organizing demand by breaking it into categories of value demand and failure demand. The classic call center story he tells, shows how banks in the 80’s introduced call centers that generated more failure demand and resulted in the need to build additional call centers to handle the extra traffic. The failure demand was different phone operators passing a customer from one department to another where the customer would have to describe his problem to the first operator, be transferred, then describe the problem all over again, then be transferred again and so on. The call centers were creating more work and it had nothing to do with serving the customer. So costs went up.

If you are treating all work as work to be done without thinking about it any further, then you might be hitting capacity in your system when it could hold more if you fixed the failure demand. By designing your system to reduce failure demand capacity opens up and you are able to flow more value.

Michael Gerber in his E-Myth book talks about the importance of working on your job, not just working in your job.

Parts of a System and Your Fit

In a business that makes software, it is well known that one tactic for making large software is to break the problem and work down in to parts. Then the work is assigned to different people. What is less well known, in my opinion, is that when a problem is broken down and divided among people there still needs to be understanding of the system among each of the parts. In essence, the people that start out with the big problem divide and assign tasks, but it is important to remember to also assign understanding of the system as a whole to each part.

Sometimes taking the time and effort for each part to understand the system as a whole is considered waste. It takes time that cannot directly be quantified as producing code. The code that is produced by the individual will be for their part, so why do they need understanding of anything other than their tiny little problem?

The parts need to be able to answer the questions:

  • What am I a part of?
  • How do I interact with the other parts?
  • Is the problem for my part designed correctly so that I may create the correct solution for the system? Read more about designing problems before designing solutions.

Interaction is not contained nicely within a part. Interaction should also be viewed from the perspective of the customer and not entirely from the perspective of the discipline of engineering.

For example, there is a large system that was developed at a company I know of where the mobile application used a red icon to represent a sale and the corresponding web site that displayed aggregated reports of sales used a red icon to represent that a sale was NOT made. Each part was certified to have accomplished their task individually correctly. In this case, the mobile application was considered a part of the system and assigned to an engineer and the web application was considered a part and assigned to a different engineer. Each was certified by the people testing to have accomplished their task correctly. Yet, the result was pure confusion if there was any user that was to use the mobile app and the web site.

What was lacking, was the mobile developer asking what they were building was a part of and the web developer asking what they were building was a part of. As engineers, they understood that the two sets of code were going to share a database. Yet, this fundamentally misses the point of understanding the system. Just because a database is completed and represents the entire set of data, does not mean it is the system. Even when implemented, the system is more a concept than any specific piece of technology. This is lost on some engineers that jump directly to implementations, pointing to specific tables of data.

If the question had been asked of each person who was responsible for building the parts, “What is this a part of?” and “How will this part interact with the other parts?” instead of saying “I have my part, I’m face down in implementing my part and I don’t need to waste my time with seeing what the other parts are up to.” then maybe a better system would have been developed from the perspective of the people who will be using the system. Something is always part of a larger system and to dismiss this in pursuit of optimum efficiency, getting your part out the door fast, is quick but not smart.

Successful software is the right software, not the fastest developed software.

Design the Problem Before You Design the Solution

In my role as a software engineer I am constantly presented with problems and as engineers we try to come up with a solution immediately. It’s almost like a reflex. In these situations, a lot of times we take the problem for granted and accept the context, constraints of the problem. However, over the past couple of years I have really learned to value designing the problem first. Sometimes this means dismissing the obvious and exploring the consequences, as Russell Ackoff would describe it.

Below are the two most common ways I am approached by others in engineering the tools that will eventually be used by people to accomplish their work.

When approached by project managers for example, sometimes the conversation will start with a problem the customer is having and it will be up to me how to solve it. For example, “The customer is saying they need a way to search for these specific types of incidents in their system.” The solution could be adding a search field to an existing screen or adding a new screen dedicated entirely to this scenario. This is approaching the problem from a literal view and starting my process of engineering a solution in a very direct response type of way. In the business of delivering custom line-of-business applications there is usually very little work done by a designer, so it is more Customer > Project Manager > Engineer. Sometimes there is more value in taking a step back and not jumping straight in to coming up with solutions, even if your role as an engineer is to eventually implement a solution.

Sometimes the problem is described and the other person prescribes a solution. For example, the project manager will describe a customer problem of needing to track addresses within our system. Then it might be described that the software needs to have a web page added that allows users to type in an address, Line 1, Line 2, City, State and so on. Presumably, this means the person prescribing the solution has already taken the time to analyze everything and synthesize what would be most useful. Sometimes this is legitimate, if this work has actually been done. The software engineer does not have to be the role that designs the problem and solution. In the most literal sense, the software engineer is responsible for implementing the solution.

If you find yourself as an engineer either accepting problems as-is or accepting problems and their prescribed solutions, even if another role like a project manager is going through the work of crafting the problem and solution, then I challenge you to question the other role and test if they really have designed the problem and solution. In a lot of cases, the decision to go with a specific problem/solution pair is based on time, effort and other tradeoffs. These are different for each person.

Delivering the right software is not always the result of matching a solution to every problem. Sometimes, changing the problem is the key to delivering the right software.