PMISuite

A cloud based solution for project managers, executives and functional managers.

Odoo text and image block

Change Management

Change Management used as Stakeholders Requirements Management, Risk Management and Hybrid Agile Framework.

 

Change Management

Change Management used as Stakeholders Requirements Management, Risk Management and Hybrid Agile Framework.

Change requests are handled as project requirements. For known requirements (known specification) define type requirement, for undefined requirements select type change and manage them as an agile project cycle where task stages are considered as iterarions (sprints). Assess (and manage risks) as type risk change requests (tasks are considered as an action plan to follow if the risk "happens".

Project changes of type request handled as Agile "User Epic" term, tasks handled as gap analysis lines (user story lines in Agile terminology).

Project changes of requirement handled as deliverable plan, deliverable lines confirmation workflow integrated with sale workflow. Price analysis on deliverables suggests a target budget (sale price) based on resource plan lines and chosen margins.

Communications and Change Management

The first information input in an organization is considered a lead. It's a message which was not examined and categorized yet. If the examination reveals, that the message in question is:

  • a commercial request: connect it to an existing project or create a new project for it and change the lead to an opportunity

  • an issue: change the lead to an issue

  • a request which triggers actions thus needs a change in current operations: change the lead to a change request since every new action means a change in the current project


A change request includes at least three project stakeholders:

  • the proposer: the person that triggered the change request (the author of the initial lead, could be an external party)

  • the requestor: the person from the project team that pushed the proposer request as a change request

  • the change manager: the person that is in charge to enforce the change

and optionally:

  • the enforcers: persons to whom tasks were assigned by the change manager


The main change request categories are:

  • schedule (requests concerning deadlines, resource assigning changes, priority changes and other changes concerning the scheduling)

  • cost (requests that affects the project costs)

  • scope (requests concerning changes in the original project scope, so called extra contractual works, additional works and unforeseen works)

  • deliverables (requests concerning changes in the final (delivered) products

  • testing/quality (requests concerning changes needed to respect the quality policy)

  • resources (requests concerning the changes in assets and resources)

  • regulatory requirement (requests concerning changes needed to comply to the regulations)

To describe a change request we need:

  • a reason for the request

  • a description of the planned change

  • a description of the effect we expect by enforcing the change

The change enforcing triggers/assigns one or more tasks that are needed to enforce/complete the actual change.

To be able to better manage the priority in a mass of change requests, we define the change proximity, which can be:

  • imminent (highest priority)

  • within stage (to enforce before the project stage is completed)

  • within project (to enforce before the project is completed)

  • beyond project (to enforce after the project is completed)

Until the change acceptance, a change request can be changed; it's important to notify the revision date for every such change.