I recently heard a vice president at a Fortune 500 company discussing the challenges associated with evaluating investment decisions.  This man stated that it was extremely difficult to do because every program labeled their benefits differently.  Even if it was as simple as “Grow Revenue” or “Increase Revenue” it still was impossible to effectively and efficiently roll up results across the program, let alone across the investment portfolio.

Thus enters another reason to utilize standard benefits management practices across the enterprise. 

If you consider a benefit to be an object (which it is) and objects have attributes (which benefits do) and the attributes can be stored in a benefits register (which they should) then you have the foundation for consistent reporting.  Consistent reporting will allow executives to quickly see across all the investments, which ones for contributing to a specific class and how they are performing.   It will also allow a sponsor or program management to do more precise reporting and analysis during program reviews.  It is a win win.

It doesn’t have to be difficult.  The first things many organizations will try to do is define a canonical list of all possible benefit classes.  They end up mixing different levels of benefits and have scores of items on their list that end up being too confusing and thus unusable.  The Benefits Classes should be structured in multiple levels with a high level defining HOW the benefit contributes value.  There really are only a few ways this can happen.  Ultimately you are increasing revenue, decreasing cost, or adding a new product or service to your customers.  These should represent the highest level class.  You may then use subclasses to further granulized the categories.  And the benefit itself should be the lowest level of detail including the recording of the results and the expected value of the measured results after the change is implemented.  But I digress.

Going back to the class level, I want to focus on what I consider to be the minimal set of tangible benefit classes you might have in an organization.  These values should be mutually exclusive and assigned to a benefit.  This list includes:

Of course, I would be remiss if I didn’t reiterate that these classes represent the type of benefit measurement that will be utilized, not the benefit itself.  The benefit is not a 10% reduction in time to process an order.  The benefit is reducing time to process an order, the target measurement is 10% (and this is probably a class of Business Efficiency).

The power of this benefit class model is that it provides a high level category for macro reporting, but it can easily be used as a super class and the business define sub classes for further granularity.  For example on Business Efficiency, you might have a subclass of Currency.  This subclass may then be Time for measured per unit time, or it might be Financial for reducing cost of a part in the product.

This high level classification provides a capability to structure the benefits for reporting within the program and across all programs within a portfolio.  Combining it with defined subclasses allows for a means of organizing your benefits and also ensuring that you have done due diligence on all types of benefits during your planning phases.

We're All In This Together !!!
Dave

Hand Sketch Graphics Have Better Retention

There is a growing trend of using hand sketched icons, symbols, and graphics in documentation and presentations to emphasize main topics, increase reader retention, and better communicate the message.  More publications and tools are embracing this trend and providing a much better overall user experience.

I recently had the pleasure of reading the book: The Practitioner’s Guide to Project Management – Simple Effective Techniques that Deliver Business Value.By Lynda Carter.  Lynda is a Project Management Consultant and Custom Training Development Specialist.  She has done work for Baldwin Wallace University and owns Competetive Edge Consulting ( http://www.cectraining.com/ ).  She has developed an extremely easy to navigate reference guide on project management.  She developed this with project management classes in mind and has had great success in using it as a reference for her project management training classes.

From a content perspective the book I spot on.  It lays out a very logical flow, set of reusable/scalable tools, and the business logic behind project management.  It includes many real life examples including real-world needs such as using KPIs as a leverage point to stakeholder relationships.  Her approach has provided me a new tool in my tool box.

But where the book stands out is the layout, it is top notch.  The book encompasses a great use of white space and a FANTASTIC use of supporting graphics and sketches. The picture below demonstrated this use of icons in defining components of the project and they are reused throughout the book.  I can see a lexicon like this being used throughout a project and words such as “the piggy bank” being used as the metaphor for financing.

Ms. Carter is utilizing an effective means of communication and taps into a growing trend.  I recently talked (if I call exchanging email, attending webinars, and exchanging Facebook posts talking) to Michael Deutsch, the product manager of Mindjet, about hand-sketched graphics, and he told me that there is a study that shows how hand-drawn sketches on slides help increase retention by a factor of 20% or more.  He indicated that one of the significant features of the new release of Mindjet Mindmanager is the inclusion of a set of hand drawn icons in four different colors.  They provide an effective visual message and categorization of thoughts, without the invasiveness of manufactured clips. 

Although I don’t see dominate graphics going away and being completely replaced by hand drawn sketches, the two have a great opportunity to work together.  And a project manager can now use simple sketches to tell the story of the project and propagate the message through many different communications in the project lifecycle.

One of Ms. Carter’s most effective techniques is establishing repeatable icons for use throughout the book.  When she introduces roles she does so with a graphic, as demonstrated in the image below, and then uses the icon at different points to emphasize the role in that aspect of the project.  For example, the big fingered sponsor is used later when the responsibility of the sponsor is discussed.

The book is available online at http://www.amazon.com/Practitioners-Guide-Project-Management-Techniques-ebook/dp/B00MH69UEW/ref=sr_1_1?ie=UTF8&qid=1413760743&sr=8-1&keywords=The+Practitioner%E2%80%99s+Guide+to+Project+Management+%E2%80%93+Simple+Effective+Techniques+that+Deliver+Business+Value in both hard copy and electronic (Kindle) versions.

The net-net of this post is 2 fold.  First, using hand-sketched graphics in your communication facilitates retention and allows for visual reference through the project lifecycle.  Second, I highly recommend The Practitioner’s Guide to Project Management – Simple Effective Techniques that Deliver Business Value. As a reference for project managers at all levels, but especially entry level or “accidental” project managers.   

·         The graphics in the book were composed by David Balan, Illustration & Sequential Art www.davidbalan.com

** Full disclosure, I have previously worked with Lynda Carter and know her outside of this blog. We actually collaborated on a Leadership research project that was delivered as a PMI webinar.  If you are a PMI member, you can view it online at:    http://www.pmi.org/Knowledge-Center/On-Demand_Webinars.aspx.

Defining Benefits: Forced Extraction

The benefits definition, qualification, and quantification process can be somewhat confusing to many people.  Defining a benefit can be tricky and misinterpreted, especially by upper management.  There may be some members of the team who look at all results as a function of benefit realization, while the true definition of Benefits Realization rests in organic improvements as a result of change. One item that causes confusion is called a force extraction.

A forced extraction is when a company forces financial results on an organization.  For example the budget for a department is cut by 10%.

While that forced extraction may provide economic results to the company, it is not considered a Program Benefit.

Program Benefits are identified as a result of the outcomes of the components.

It is important that benefits are identified as a result of the outcomes of the components and not as a direct result of a business allocation of resources.   While a factor in the overall program may be a budget reduction, it should not be tracked as a program benefits because it is not a result of the outcomes delivered by program components.

The Project Management Institute® (PMI) has defined a Benefits Realization model for a Program Manager to use to help the company capture the expectations of an investment.  The concept of the model is to provide a structure from the initial planning through to actual realization (or booking) of the benefits into a new Business As Usual change.  The five steps are loosely structures to be hierarchical in flow, but allows for a progressive elaboration approach as more information becomes available during program implementation.

Benefits Identification

This is the initial step of capturing the potential benefits that can be realized by the program.  This step is analogous to a brain storming session and will result in a canonical listing of potential benefits.  There are many sources for gathering this information including business documents, brainstorming sessions, extraction from a business plan, external factor analysis, organizational strategic objectives, and expert knowledge.  Many organizations will group the list into various categories to assist in analysis and eventual ownership.   The outcome of this step should be a list of potential benefits in a benefits register.

Benefits Analysis and Planning

This is the means of qualifying and quantifying benefits.  If the benefits Identification step produces a canonical list of benefits, then each benefit needs to pass a “test” to see if it truly qualifies as a benefit, or to help prioritize benefits.  The benefits register should contain the associated algorithms and business rules/logic required to define the value of the benefit.   The analysis will also include setting an expectation for the value of the benefit and a relationship of the benefits against sequence, time, and dependencies.  A significant portion of this step is to align company performance metrics (KPI) to be able to measure, demonstrate, the results of the implementation.  The end result of this step should be the Benefits Realization Plan (BRP) which formally documents the activities required for achieving the program’s planned objective.  Included in the Benefits Realization Plan is a program roadmap which documents the expected delivery of the value of the benefit against time.   The BRP will also define how the benefits will be transition to operations at the end of component deliver and the sustainability expectations.  The Benefits Realization Plan is a control document and needs to be baselined and managed under strict change control throughout the life of the program.

Benefits Delivery

This is the means of actually placing the changes into the business and the start of seeing the expected benefits in the business reporting infrastructure.  Since Programs will include multiple components, the delivery will be an iterative process and will span from the first project completion through to Program Closure.  Using the baselined BRP, the program resources will conduct monitor and control activities to analyze the results and prescribe corrective action.   Part of this prescriptive corrective action is to ensure the Benefits Register is aligned with the monitor and control activities.  The final litmus test of the benefit delivery is to ensure the results are properly accounted in the company Profit and Loss (P&L) applications (or  they are “booked”).

Benefits Transition

This is the means of recognizing the programs have defined ends and that benefits might be realized long past the closure of the program.  The Benefits Owner will eventually assign benefits realization to an operations function where it measures the benefits as part of a “Business As Usual” process.  This implies that monitor and control and associated prescriptive action is no longer the responsibility of the Program manager, but not the operations manager.

Another important aspect of the Benefits Transition is that operations team will often view a suite of benefits as one item.  For example there may be six benefits included in a project software enhancement, the operations team will most likely look at that as one enhancement.  Therefore, the benefits transition process, and associated artifacts, will consolidate coordinated benefits into the package to east transition.  The outcome of this phase will be the standardized reporting of benefits to associated benefit and business owners.

Benefits Sustainment

Finally, benefits need to be sustained over the lifecycle of the change initiative.  Many times the benefits will be forecasts over time, as defined in the benefits roadmap, and the time frames will expand past the life of the program.  After benefits are transitions, they need to be sustained.

Monitor and control and taking corrective action is a portion of the sustainment steps, but it can include much more.  It is possible that during the lifecycle of the change that previously unidentified benefits are realized, these “emergent” benefits should be documented and through the use of structured change control, incorporated into the benefits reporting models. 

Conclusion

The PMI Benefits realization model defines a structured set of phased to support the identification of, analysis of, monitoring and control of, the transition of, and the sustainment of benefits throughout the lifecycle of the change.  The model also encompasses the “care and feeding” of benefits after transition to operations and helps to validate the true return on investment to the organization.  Benefits Management needs to be incorporated into an organizations knitting and be considered in all aspects of the program.

Sources

Letavec, Craig J. Strategic Benefits Realization: Optimizing Value through Programs, Portfolios and Organizational Change Management. Plantation, Fl.: J. Ross, 2014. Print.

The Standard for Program Management. Vol. 3. Newtown Square, Pa: Project Management Institute, 2013.

We're All In This Together !!!

Dave

Of Course I Know What Benefits Are

Adopting an organization that is benefit’s centric as opposed to project centric involves many dimensions.  At the heart of this adoption is change management and mindset realignment.  The model that Benefits Management is directly aligned with a Cost/Benefit Case study is the first, and probably, the most difficult, mindset to change.  A fundamental question is:  “are you willing to look at costs benefits over what the new ability being delivered to the business, over the cost and benefit of completing an activity to deliver a product or service?”

I like to call the project benefits focused mindset as an “activity centric” approach to organizing and managing the work.  An activity focused approach establishes a foundation of what will be done (scope) when it will be done (schedule) and how much is it going to cost me (cost).  Once the baseline is established for the work – the project manager monitors and controls against this triple constraint and measures its success against the activities that are completed (requirements, development, testing, etc.) until the product or service is complete and moved to operations.  Benefit centric organizations, while they treat projects as important, consider the benefits of the work in progress and delivered as the critical component in decision making.

One of the common challenges I have face when trying to introduce benefits realization to an activity centric organization is the roadblock that:  “We already know about Benefits”.  Their paradigm (and I don’t mean this as a buzzword) is in relation to Cost Benefits cases and it’s relevance to projects.  One of the first mindset changes in moving from an activity centric environment to a benefits centric environment is that benefits are realized from many components, not just a specific product or service.  Projects (in which a product or service capability is built) are one factor in the benefit equation as well as other components such as workflow modification, licensing agreement changes, supplier costs, etc.

The shift in a benefits centric organization is that the benefit comes first, not the triple constraint of the project.  The benefit is directly aligned with a strategic intent of the organization and various components delivery things to contribute to the benefits.  If the benefits forecast change, the overall amount of work being done might change.  You might decide not to do some projects, or cut the scope of projects.  While in an activity based organization, you traditionally focused on something changed in the ability to create the product/service and deal with accordingly with no alignment with how it meets the benefits once it goes live.  While a benefits centric organization truly tries to answer the question, did the work we did – return the results we expected.  It doesn’t end when the project does.

This concept takes a little while to grasp and does represent a new mindset.  We are approaching it slowly as there are several concepts that must be understood before getting into the mechanics of benefits realization.

We're All In This Together !!!

Dave