Introduction
In the past, most people measured the success of projects by the three traditional criteria of cost, quality, and schedule. These three traditional metrics fall short today because the importance of stakeholder satisfaction is being recognized as more important that any of the traditional measures. That is, the project is considered a success if the project stakeholders are happy with the results.
In an ideal world of perfect projects, all metrics would be met and all stakeholders and participants would be happy with the delivered products. The reality is that some projects are abject failures. Failed projects are those where the stakeholders are not only dissatisfied with the results, but walk away at the end of the project wishing they had never been involved. This can happen even on projects that have met all of the traditional metrics of cost, quality, and schedule, but have simply failed to meet stakeholder expectations.
This is either because their expectations were too high or because the participants fail to accept the project as their own and embrace the opportunities that the project delivers. Even when the project is accepted, if the opportunities presented by the project are not maximized, the project is, at best, only a partial success. Hence, project success depends heavily on setting and delivering all of the expectations of the stakeholders and obtaining their concurrence on that achievement.
The only way to deliver projects with a high probability of success is to assemble a project team that is comprised of the right individuals from the right stakeholder community. This means that the ultimate owners of the project should be active participants from the start. The start of the project is where the greatest opportunities exist for setting and managing end-user expectations. Setting stakeholder expectations and assembling the appropriate project team is the first and most important phase of change management.
For certain types of projects (software delivery projects are a good example) there are still what you would call "change orders", "change requests", "scope changes", "contract variation orders" or whatever name you like to call the changing of scope, cost, quality, or schedule of activities. Of course, we need to foresee, capture and manage these items under the heading of "project changes" and our preference is to call this project management process "change order control" or "technical change control". All projects will have some exposure to these same types of "technical changes" that need to be managed.
"Change management" as described in this paper does not relate to management of the aforementioned changes to technical items, but rather is the management of the end user expectations, awareness, and preparedness. This set of activities should be accomplished by implementing a strategy to ensure that the ultimate owners and end users are "onboard" with the project team and its deliverables. However, it often happens that on these types of projects where the setting and management of expectations is not done at the project's outset, a "change management" firm is brought in towards the late stages of the project to implement fixes for some of the enterprise change problems that have arisen. The members of these firms tend to view themselves as "white knights" riding to the rescue to help "soften the blow" to the end users. They also tend to be very, very expensive!
The point of all this is that enterprise preparedness is a fundamental part of change management (as defined) and must be considered as one of the essential deliverables, and not some separate initiative or adjunct activity that is suddenly found necessary to salvage the project.
To take a construction example, if we build a new gas plant and deliver it successfully from the purely technical standpoint only, is it a successful project? If no one knows how to operate it, or they are incapable of maintaining it themselves, then the answer is a definite no! If there is no provision in the project plan for the involvement of operations and maintenance people in the development of the project plan and training strategy, how do you ensure that they will be ready for the effective and efficient operation of that facility? There must be a strategy to ensure that they are engaged and are willing, ready, and able to take ownership of the facility when it is transferred into their custody and control for operation. This is equally true of software implementations, or any other types of projects for that matter.
|
Abstract
