As the go-live of a project approaches, I sometimes hear project team members and stakeholders ask "what were the benefits of doing this?". Or, maybe there is a request from a senior stakeholder to document the business value of the initiative for a roadshow or go-live preparation materials. In all cases, this usually leads to a few blank stares and a closed door meeting with the output being a deck that then justifies all the great new process capabilities that are available with the new solution. But why was there so much stress and strain to answer this question? How did we lose site of the business value that was intrinsic to the success of the project? The answer lies in tracing the business value from the beginning of the project to understand how it is constructed.

In most organizations, project stage gates require that business cases or business value be defined in the project charter or project initiation documentation. The business value is usually a statement of expected benefits with some details provided. This is deemed as enough for senior leadership to sign-off on initiating the project. During the project lifecycle, changes happen such as decreased/increased scope of services or departments within scope, new resources, new timelines, changes in deployment strategies, etc. Additionally, major changes can happen in the business area where the project is being implemented. Throughout these changes, business value is not reviewed again to understand the impact to the expected value to be received at go-live. A better solution is to provide an engineered business value that is capable of being recalculated as inevitable project and business changes occur.

Engineering a value seems like a scary and daunting task. The term engineering is used because the value must be a robust calculation that is based on factors. If the factors change then the value must change. If a system implementation is going to cover multiple departments, the value calculation must identify what each department's value is based on how the system will improve processes. Some of the typical levers in business value are labor savings, productivity increase, and impact to quality (customer's perception). To get this level of data, you need to go deeper into the current state.

  • Labor savings – Current state staffing for processes performed is compared to the expected staffing in the future state. The value achieved grows as processes are expected to be streamlined and cycle time is reduced.
  • Productivity Increases – Departmental output in the current state is compared to the expected output after implementation.
  • Impact to Quality – Improvements in quality include reduced rework, decreased customer complaints, and improved customer interactions/satisfaction. The value here can be measured by customer surveys, customer queue time, and time spent in the rework loop.

With calculations in-place, the business value needs to be reviewed when project change request occur. The business value may also change if the business area experiences a change. For instance, the business may have a separate endeavor that reduces headcount prior to the implementation of your project. Therefore, the baseline data in your business value calculation needs to be redone.

Business value is often thought of at the very beginning of the project and at the very end. It should be a an active project management document that is developed with some process engineering on the front and modified with every change control request or change within the business areas in scope. Additionally, another benefit of having accurate and calculated business value for projects is prioritization. If value is more closely measured, prioritization of initiatives becomes easier. Those projects that have the best business value with the least risk of project or business area changes are selected for implementation.