The Importance of Scope Control in an IT Project

The scope of IT projects - also known as the perimeter - is one of the most influential factors on the outcomes of a project. As such, inadequate scope control will certainly impact the famous performance triangle and therefore affect costs, deadlines, and potentially the quality of the project. In this post, I aim to raise awareness about the importance of scope control in managing an IT project. This applies regardless of the nature of the managed project.

First, what is scope?

La portée définit l’envergure du projet ou encore le périmètre.  Elle détaille avec précision les inclusions et exclusions.  On utilise souvent le terme anglais, « project scope« .D’abord, dans le cas des implantations ERP, on a l’habitude d’inclure dans celles-ci les inclusions du projet sur différents plans: emplacements géographiques, lignes de produits, processus d’affaires, etc.  On prendra soin également de préciser les exclusions: par exemple, tout développement de rapports ou développement de personnalisations, etc.  On suivra le même principe dans les projets applicatifs.D’autre part, dans les projets web, on a l’habitude de préciser l’envergure des sites web en identifiant les contenus qui seront couverts, les langues disponibles et les fonctions de gestion de contenu requises.

The scope defines the size of the project or its perimeter. It precisely details the inclusions and exclusions. The English term, "project scope", is often used. Firstly, in the case of ERP implementations, we usually include in them the project's inclusions on various levels: geographical locations, product lines, business processes, etc. We also take care to specify the exclusions: for example, any report development or customization development, etc. We follow the same principle in application projects. On the other hand, in web projects, we usually specify the scope of websites by identifying the content that will be covered, the available languages, and the required content management functions.

How can we ensure that the scope is clearly defined from the start?

We first define the scope at the very beginning of the project, during the planning phase. Normally, the project manager plays a key role, and depending on the size of the project, a business analyst may support them during this exercise. A very critical activity is the approval of the scope by stakeholders. We first involve key people from each of the business lines and concerned departments. These key individuals do not necessarily need to have experience with IT projects, but they must be able to know if the project, as defined, covers all needs and that no part is forgotten. It's all well and good to have an approved scope, but if it is approved by the wrong players, we risk having surprises later on. Scope control is therefore essential!

What can happen if the scope is poorly controlled during the project?

A poor ability to manage the scope properly will translate into events like the following:

• Analysis and configuration of a process not planned for the project.
• Evaluation of features for which we do not have authorization.
• Discussions with organizational units normally outside of the project.

In short, we will work on "extras" that are not authorized and that will certainly have an impact on the project's cost, time, and quality objectives.

How do we exercise good control during execution?

It is up to the project manager and their team of business and functional analysts to guard the project's scope. It is crucial that the project manager has a very clear understanding of the scope and that they perform some surveillance of the project's deliverables to ensure that we respect the project scope defined at the start. It is also up to business analysts and application or functional analysts to pay attention to the project perimeter. Whether during their work workshops or while writing analysis documents, they are very well placed to identify "out of scope" elements. The change request management process takes care of analyzing and evaluating the relevance of out-of-project elements.

The contingency allowance

Furthermore, a well-planned project normally integrates a portion for unforeseen circumstances into its budget. We call this element a contingency allowance. The contingency allowance usually serves two purposes:

• To compensate for the uncertainty and difficulty of estimating certain project tasks.
• To carry out tasks not included at the start (change requests).

Change request management: an important process

That said, it is important to submit any change request to a rigorous analysis and evaluation process. Everything culminates with approval from a committee that can be more or less restricted. The project manager certainly has good judgment, but ultimately, it is up to the project stakeholders to make the decision.

Conclusion

Finally, scope control is an activity at the heart of IT project management. This activity must be carried out, regardless of the size of the project and the experience of its manager. Ignoring it is inevitably heading towards a situation where it will be difficult to explain observed deviations. Lastly, carrying it out rigorously is keeping the project on track and demonstrating that activities are under control.

Recommended further reading

I encourage you to familiarize yourself with the following documents related to project control activity. They were particularly useful to me in preparing this post.

• Scope Change Control, by the Project Management Institute (PMI).
• Scope Management, by the PMI.
• Scope Control, on Project Management Knowledge.
• Scope Control, by Tools Hero.

This article was written by the founder of Brome Conseil, Simon Chamberland. Working in the field of information technology since 1995, he has over twenty years of experience in information technology and management. Note that this article was first published on the Brome Conseil firm's blog.