Change is inevitable have a strategy to manage it

Change management is needed to cover several important aspects of project management.

  • The project product scope as represented by the project product description and product breakdown structure
  • The project work scope as defined in the Statement of Work (SoW).
  • Changes in team members
  • Change and the product scope

    Knowing what product or output will enable us to deliver the right capability is often unclear at the start of a project. Having a strategy to manage uncertainty and the inevitable changes is a good practice. This will enable the project team to deliver the right output and ensure that the capability to realise the needed benefits is delivered.

    Following is a simple change management strategy for a software development project that you can use to as the starting point for developing your own strategy.

    Introduction

    The purpose of this strategy is to create a common approach to how issues and change will be approached and managed in the project.
    During the development phase it is possible and very likely that changes will need to be made to meet changes in the market or changes in understanding as to how the product can deliver the capability required by the business. The change management process will enable The Client and Supplier to retain visibility and control of the project throughout the build process. Decision makers will be kept informed and be able to take business decisions based on clearly defined criteria.
    The commercial agreement for the project is made based on the knowledge of what is required prior to the project development phase commencing. Changes in the project product will need approval from both Supplier and the Client to cover financial adjustments.

    General Guide Lines

    1. Analysis and estimation of ”Requests for Change” is not included in the cost of this project.
    2. The term ”Bug” is often misleading or incorrectly used, for clarity issues will use the definitions given below.
    3. The Client has the responsibility for defining acceptance criteria, where acceptance criteria has not been defined the Supplier personnel will decide on what the acceptance criteria is based on information available. NB: Under these circumstances it is advisable to have the client and supplier working very closely together.

    Issues & Changes will be classified as:
    1.Request for change
    A proposal for a future change to a baseline. This includes the baseline for specialist products and management products.

    2.Off specification
    A product or feature that is within the scope but has not (or will not) been included.

    3.Defect repair
    A product or feature that has been built, but does not meet the documented specifications and acceptance criteria.

    4.Warranty
    Anything covered under “Off specification” or “Defect Repair” that is identified within 4 weeks of UAT starting for projects over 2000hrs of effort and 2 weeks for projects or work streams under 2000hrs of effort.

    5.Problem or concern
    Any other issue the Project Manager needs to resolve or escalate.

    To ensure clarity and consistence when documenting the above the following patterns can be used:

    Request for Change

    The ”Request for Change” type of issue needs the requirement to be explained and then how it will be tested. It is important to define the acceptance test so that the development team knows what criteria need to be fulfilled in order to close the work and gain acceptance.

    Structure of the requirement
    This can follow the same structure as a US&AT

    The Request for Change type of issue when documented correctly has the following characteristics:
    • Understandable,
    • Well-formed & Correct
    • Independent,
    • Negotiable,
    • Valuable (Must add business value),
    • Can be estimated
    • Testable

    Off Specification

    The “Off Specification” type of issue can be raised under a couple of circumstances:
    1. A feature that is being demonstrated clearly is missing some functionality that is explicitly documented in the existing set of agreed and approved (baselined) requirements.
    2. There is a feature that is within scope but the client has decided to remove it from the build, before the development work begins. If the development work has begun or is completed then a “Request for Change” must be submitted.

    Defect Repair

    The “Defect Repair” type of issue can be raised when a requirement does not work as defined in the agreed acceptance criteria. If there is no acceptance criteria then the issue will be classified as a ”Request for Change”.

    Before a ”Defect Repair” issue is accepted for further work it must be documented with the following information:
    1. The steps taken to create the unexpected behaviour / fault
    2. The browser(s) on which the fault appears
    3. The devices on which the fault occurs
    Without this information the issue will not be attended to.

    The Issue & Change procedure should cover these activities
    1.Capture the issues
    a.Determine issue type
    b.Determine severity/priority
    c.Enter in Daily Log or Issue Register

    2.Examine
    a.Assess impact on project objectives, Business Case and aggregated risks
    b.Check severity / priority

    3.Propose
    a.Identify options
    b.Evaluate options
    c.Recommend options

    4.Decide
    a.If outside authority level then escalate to Project Board
    b.Approve, defer or reject

    5.Implement
    6.Baseline the product

    Demonstrations & Quality Review’s

    TO BE TAILORED FOR EACH PROJECT
    Demonstrations will be held at regular intervals during the development phase to show what has been developed and to get feedback from The Client. Prior to the demonstrations the production team will create a list of features that will be demonstrated. The Client’s team needs to give written feedback within 3 working days confirming acceptance of the features demonstrated or raise an issue. In the absence of written statements the features demonstrated will be passed as accepted. Any changes later will be treated as a request for change.
    In the event that Supplier only wants to show what has been done but is not ready for a Quality Review then this will be explicitly stated to the Client’s personnel

    Change and the project scope

    A well-formed Statement of Work (SoW) will describe who or which organisation will do what jobs along with any dependencies and assumptions. During the life of any project it is possible that that an individual or organisation will not be able to fulfil their commitments. It is advisable to have a strategy guide line on how to manage these situations.
    EX when building an eCommerce solution it is normal for the eCommerce company (client) to supply test data to the supplier for use while building the solution. In the event that the client does not supply test data and the supplier has to take on a couple of extra staff to generate test data. This is an increase in scope of the project work the supplier needs to do in order to get the project product built and delivered.

    Comments are closed.