What is an easy to understand and communicate way to differentiate between Information and Communications Technology (ICT) design changes on a project which would not trigger a scope change request (variation), and an actual scope change which would require formal approval from the delegated authority?

I work in an ICT Project Management Office and need to come up with a simple blurb to be included in a new guideline to ensure that small design changes don't end up having to get approval from a Project Sponsor (usually the CIO) and include some examples to give people context and improve understanding.

  • 2
    What do you mean by "design change"? Changes in design of the user interface? Design of the architecture of the application? Some more details or examples would help to better understand the question.
    – Bogdan
    Apr 29 '21 at 9:51
  • This reads like you have an onerous change process you're trying to find a way to avoid. You open this door, you open debate about what is small. You'll experience all kinds of creep with those committing creep arguing how it meets your definition. Design a better change process. Apr 29 '21 at 15:02

Software developers use the term refactoring to refer to technical changes that have no impact on functional or non-functional requirements. An example might be a decision to develop a component in the Go language instead of Java. Typically that kind of change wouldn't need a sponsor's approval unless it had an impact on some other commitment.


Given the context of your question, I assume this is a waterfall development environment, as an agile environment deals with this type of question almost by default, as the Product Owner should deal with anything to do with scope.

At a very simple level, a scope change request would be required if "what" is being delivered (i.e. functionality) is changing even in a very small way, whereas "how" it is being delivered (implementation / technology) would not require a scope change request. I would suggest that there should be tolerances on this, however, so that you don't need to raise a change request for changes that are trivial in nature.

Do beware of cumulative trivial changes, however, which may be individually small but in combination they add up to something big enough to need approval. Some devious PMs may even play on this (shock, horror!), by breaking large changes down into lots of small ones, claiming that each is so small that it doesn't have to be treated as a change request and so doesn't need to go through the change approval processes.

However, it isn't always as simple as saying that scope changes only come about as a result of functionality changes. For example, changing the development environment may not change the functionality, but if it could change the look and feel of an application in some way, it may be considered as a scope change by some people.

The other aspect that you don't explicitly mention is where a change leads to a variation in timescale or cost, even if it doesn't change the functionality. In such cases, your sponsor is likely to want a change request unless it is within agreed tolerances. These are not technically "scope" changes (as you are delivering the same outcome - just delivery at a different pace or at a different cost).

Some project offices want change requests even where the change is beneficial (i.e. faster or cheaper), as they need to manage financial or people resources which may become available in such circumstances.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.