Over the past couple of posts I have been covering the topic of small change projects.  Change that falls between Business As Usual (BAU) and change projects.

This post is going into more detail of the tools and processes you need to implement a small change process.

Small Change Project Criteria

Before you define the criteria to be used to determine if a request is a small change, a more strategic decision is required if there is a need to run a small change project.  If there is no need or no appetite for senior management to support and fund a small change project, then it is pointless designing and implementing a process.

On the assumption the benefit is recognised and, a budget assigned, then you need to determine the scope of the small change project and criteria for what is defined as small change.

For larger organisations, there may be more than one small change project.  For example, there may be a small change project to support enhancements for Finance, another for Sales and another for Operations.  Each will be assigned a budget (usually for the year) and each one will have a criteria for what is determined as a small change project.

More details on defining the criteria can be found in the post, Criteria for identifying small change projects.  Once you have defined the criteria for each small change project, make sure it is documented and communicated to all interested parties.

Request Form

Every new request should be presented on a simple one page form that outlines the request and benefit.  The form should contain enough detail in order that the request is clearly understood and that it can be evaluated to ensure that:

  1. It meets the criteria of small change project
  2. It can be evaluated and prioritised

This ensures that stakeholders do not try to get enhancements approved that should really be a much larger project.

The request form should include the following:

  • Small change project name – to ensure correct criteria / budget is applied
  • Request name – concise name of enhancement request
  • Requester – person making the enhancement request
  • Date – when the request has been created
  • Date Required – when the enhancement is required
  • Overview – explanation of request
  • Driver(s) – why the enhancement is needed
  • Impact – what is the consequence if enhncement not approved

There should also be a section that can be updated by the person / team reviewing the request that will include the following:

  • Assessment – impact review of the change
  • Effort – typically effort in days
  • Cost – cost of the enhancement

More fields can be added as required.  However, as this is small change, a balance needs to be maintained on getting suffiicient information without creating a process that costs more than the enhancement.

Prioritisation Process

There needs to be a mechanism for reviewing and prioritisation of the requests.  If there are many requests and competing priorities, a good method is to use a regular meeting that allows all requestors to present their enhancement and for a collective decision to be reached.

The benefit of the approach is that it provides complete transparency and ensures that only worthy enhancements are approved.

The prioritisation meetings should be scheduled at a regular frequency based on demand i.e. weekly or fortnightly.  There should be standing representatives who can make a decision for each area.  Then those proposing enhancements can be invited as and when they have a request to present.

There should be a clear process of the steps and timelines for submitting a request so that it can be considered at the meeting.  This is important as it allows an initial review to ensure the request form is complete and for the details of the request to be shared with attendees ahead of the meeting.  This helps to ensure sufficient time for the representatives to review.

Each request should be listed on the agenda.  Then each requestor should present their enhancement and the audience can ask questions.  The aim at the end of each presentation is to reach agreement to approve, reject or defer.

There is a choice on how the approval works.  Either single step or two step process.  This depends if the Assessment step is completed before the initial presentation.  This is preferable as it means that the effort and cost can be taken into consideration as part of the review.

The other approach is the first approval is that the enhancement makes sense so should be assessed.  Then it is presented for a approval when cost and efforts are known. This approach saves wasted time of assessing enhancements that will not be approved.

The decisions from the meeting should be captured, ideally on the central tracker for small enhancements.  Work should commence on the enhancements as agreed.

Tracking Process

All of the enhancements should be tracked on a central register.  This will mean there is a single source, status of each enhancement can be quickly understood and cumulative budget tracked.

The tracking register should include the following:

  • Unique ID – unique reference for each enhancement
  • Request Name – as captured on request form
  • Requester – person who requested change and / or sponsor
  • Description – you may want to have a brief description of change
  • Date Requested – date request was raised
  • Date Approved – date request approved
  • Start Date – date enhancement work commenced
  • Completion Date – date work will be complete
  • Effort – typically effort in days
  • Cost – cost of the enhancement
  • Actual Effort – actual time taken for enhancement
  • Actual Cost – actual cost for enhancement
  • Status – Pending, Approved, In Progress, Complete, Deferred, Rejected

The register is then maintained on a regular basis and used as an input into the prioritisation meeting.

Summary

Implementing a robust and pragmatic small change project process does not have to be complex.  In fact you only need 2 templates.  The process is simple to follow while allowing control and oversight of what enhancements are approved.

The PMO can play a pivotal role in defining and managing the process.