Symbiosis of change and project management

From apppm
Revision as of 23:51, 23 March 2022 by S213053 (Talk | contribs)

Jump to: navigation, search

Abstract

In the last few decades, the value of project management was a bit misunderstood. Weáve got to a point where we label as project management different processes or activities that are actually not in this field. Projects can be really different in terms of their scale, their funding, and it really depends on what happens within their corporate framework. We can safely assume that the success of a project rests on how well it is prepared, how receptive are the ones who try to achieve it, and how positive or negative is the attitude towards the specific project. A lot of times these properties are more important, than the actual professional competence of the worker, employee, or manager. In this article, I would like to investigate the necessities and needs of change management in relation to project management, since in practice these too cannot exist without each other's logical background.

If we look back 10-15 years in the past, in the operation of big companies changing to new IT systems and computers was great challenge management wise. And change happened under the umbrella of project management. How did this actually happen?

The CEOs of the companies had big expectations regarding the use of computers instead of human-centered work. They wanted shorter intervals between the ordering and payment processes, a decrease of the administrational staff, or better customer service. However to implement these technologies they needed to link the introduction of IT systems to a wide range of organizational changes (Bingi – Sharma – Godla, 1999). Although the employees of the companies looked at this conversion in a bad way, they felt that this is an obstacle to their daily work habits or as a restriction to it. At this point, we can see how the management of change is as equally important as the project itself.

Contents


The success criteria for projects

Reasons why a project could fail

Since in practice, the realization of a lot of projects fails, we should clarify what's the success criteria of a typical project. A project is successful if:

  • It's considered finished within a specified time frame
  • Uses a budget from within a specified spending limit
  • Fulfills the intended purpose

At the same time, a project is considered unsuccessful if:

  • Before or during the implementation phase, it is interrupted or stopped
  • It reaches the implementation phase but doesn't fulfill its purpose
(Fitz-Gerald – Carol, 2003)

Because of the high number of unsuccessful projects, we should look at the reasons behind it more deeply:

  • The strategic goals of the project weren't clearly defined, Not just the goals, but the expectations of the project weren't clear enough.
  • The top of the management is not working with the defined system of the project, the responsible leaders do not see the essential and key changes which are introduced and are not actively monitoring the implementation process.
  • The project management underestimates the scope, size, and complexity of the project:
    • Unrealistic timelines are made, and communication is not sufficient for the amount of the expectations
    • There is no consistency between business expectations and the chosen system
  • The organization is not behind the change:
    • Employees naturally seek the status quo and do not feel the need for change
    • Workers are afraid of the new system, maybe it can make their work more difficult, or maybe reduces the place and value in the company, or even makes their work obsolete or unnecessary.
  • The project team is not skilled enough
  • Users are unable to operate the new system properly, due to a poor design or insufficient training
  • Data quality is not ensured, inaccurate data leads to loss of confidence towards the project. Employees set aside the new system and get back to the old, reliable one.
  • After organizational changes, performance indicators are not fitted properly
  • The involvement of different supply sites for the project has not been adequately addressed
  • Technical problems with implementation difficulties

(Umble - 2003)

Success criteria

Personal tools
Namespaces

Variants
Actions
Navigation
Toolbox