I am accountable. As a project manager, I am accountable. I am accountable for my role on the project. The actions I take are based on project need. Are the actions I take the same for every project? No. Is it based on the organization, the goal, the team, the method and a myriad of other variables? Yes. While the role is the same, lead the project, the actions will vary. That is true for every other team member on a project. Is it possible to define a role and then assign that role to an individual? Yes. The problem is that assigning a role is different than as having someone determine what they can and should do for a specific project. Too often we simply tell folks what their role is, we don’t solicit from them what their role should be.
When I manage a project, or more importantly when I have agreed to manage a project, I’ve made a commitment to achieve some goal. I am accountable for that goal. In order to be accountable I have to believe that I can understand and achieve the goal and as the project manager I need to ensure that the team is committed at that same level. It is easy to commit to delivering some form or piece of documentation. I can deliver checklists quite easily. It is possible to commit to delivering a piece of software. The real challenge is to be able to commit to delivering business value. Is it possible for a project team to commit to delivering business value? We are asked to deliver software to provide business value. How can we stop short of the value commitment by suggesting that the project is done when the software is implemented? Is the business the only accountable party when we talk about projects delivering business value? We won’t ever become partners in delivery until we come to an agreement that the project manager is accountable for the benefit realization, not just software delivery.
Changing our mind set to look at the end of the project as when the benefits are realized changes the dynamic of the project team. The project team is put in a position that requires them to commit to something greater than delivering software. The business sponsor is held accountable by their management and the project team regarding the business value of the project. The project team must understand the business case of the project. When we take a look at the entire project delivery process, from an idea to achieving business value, project close cannot occur until benefit realization has reached closure.
When a project manager is accountable for the benefits, they have the responsibility for ensuring that the benefits can be realized. Once the project manager knows the benefits can be realized they can make the commitment to build the solution needed to achieve those benefits. Project success is based on benefit realization, not software delivery. Why is this distinction important? Cancelling a project because there are no benefits is a successful project. The project team prevents money being spent chasing a non-existent target. Shared success and mutual commitment are what makes a project team successful. The project team must have the same goal. The goal must be business value. Delivering software is part of project delivery, the goal is business value. When discussing project delivery, the project manager must be accountable for the business value if we are to ensure project success.
Ride On, Manage On.
6 days ago
2 comments:
How do you maintain accountability for benefit realization, where the benefits may require months or years of the standard 'post-project' activity (that is, the period between delivering project outputs and realising the outcomes)?
All benefits should be able to be tracked starting at implementation so measurement should start right away. By doing so we can begin showing the trend which is an early indicator. I would also suggest that realizing benefits in terms of years may indicate a project that is more like a program - which should be measured differently -
Post a Comment