Whenever we talk about benefits realization, we start from the idea that (we) project managers are always managing part of an organizational change. Such changes are expected to enable our organization to achieve at least a business objective that generates value. This whole process of getting from the current situation to the future improved or optimized situation is what we call a benefits realization lifecycle.
However, now and then people come to me in events and conferences saying, “But I don’t manage change at all. I just manage the production of deliverables that are requested and specified by other organizations. My projects deliver outputs to other entities (person, organization, etc.), and I am not aware of any benefits that may be expected from the utilization of those project outputs,” and then they usually ask, “So, how can I have any influence or participation in the management of benefits realization?”
That is when such generalization that has been created to make things simpler actually makes things more complicated to be understood by some people. At this point we may have project managers asking themselves if benefits realization really applies to each and every project, or even if by not managing change they can really consider themselves to be project managers.
The answers are yes, benefits realization does apply to each and every project, and yes—believe it or not—all project managers are managing part of a change process. Even when delivering products or services to an external client, the organization will be able to realize some measurable benefits such as increased market share, customer retention, and increased employee utilization, among others. In the same way, the projects are very likely to be helping the client to implement changes to their organization and then consequently realize benefits. The clients are expecting the investment made to generate some kind of benefit in return, although the project manager may not know what exactly they are expecting and the payment for the service might be the only benefit expected from the perspective of the organization that is delivering the project.
Let us go through an example. If the project is delivering software and the project team knows what benefit is expected from the utilization of the software that they are developing, it is much more likely that the team will work toward delivering a piece of software that can really enable the realization of such benefits. The team may even go further and build mechanisms into the system that will enable later tracking the benefits realization. The project team should be able to work with the client organization in some benefits realization management activities that are part of their benefits realization plan.
This approach is also very important in projects that are not delivering products, but rather services. Fields like consultancy, engineering, event management, research and development, and marketing usually have projects delivering services according to requirements. However, if the expected benefits are known by the project team, it is much more likely that the service provided will enable the realization of such benefits.
Therefore, firstly, managing projects is all about managing part of a change process, even if the change applies to an external client only. Secondly, even if a project delivers a product to another organization or person, the project team being aware of the desired benefits and being involved in the benefits realization process will make the project much more likely to succeed in enabling the realization of expected benefits and to be seen by the client as a success.
Carlos Serra will be presenting a free webinar with ITMPI on May 24! Sign up here: Benefits Identification and Tracking