5. Project Scope Management

The roots of project scope definition start already in the initiation phase of a project. The project scope reflects the project goals and objectives that further contribute to the fulfilment of company´s vision and strategy . The projects goals and objectives are on a high level described in the basic document: project charter (for further information, see PMBoK).

After the go-decision is made and a project proceeds into the planning phase, project scope is further refined with much larger focus on the level of detail. 

At first, an in-depth analysis is to be made. In case of IT projects (eg. new ERP system implementation), the main attributes to be analysed:

- current hardware, software, application and data architecture

- current business processes

- current business focus (customers, products, services ...)

- future business development plans within which the project will be implemented

- future vision of IT environment and its role in the company

- functional and non-functional requirements (incl. eg. security, maintenance etc.)*

- project implications to procurement and HR 

- key project personnel etc.

In this way, not only the current situation is described in adequate detail, but also the global and detail solution design incl. transition / migration process are set.

The outcome of the analytical stage with all the above mentioned information is usually called an analytical study. An analytical study represents a baseline for the further stage - a stage of implementation. Any changes and adjustments of the project scope are in further stages subject to a change management process.

Project goals must follow the SMART approach. That means that the goals must be:

• S - specific
• M - measurable
• A - approved (achievable)
• R - realistic (relevant)
• T - timed

We advice you to read more about the SMART approach here: https://www.mindtools.com/pages/article/smart-goals.htm

*Functional and non-functional requirements should reflect needs and requirements of all stakeholders involved in the project. When gathering and analysing stakeholders´ requirements, you should always keep in mind that:

- needs and requirements are not the same. Needs may be felt but unexpressed. 

- some needs/requirements may be conflicting (eg. scale of functionality vs. price/time). In such a case, decision on priorities must be made.

- users may not be aware of many IT innovations and possibilities - an IT professional should be there to assist them in understanding them thoroughly before the final project baseline is approved.

- when analysing user needs/requirements concentrate not only on what users want, but also what they donˇt want, what are they used to (observation), what do they expect and fear!

Take-away! Project scope must be clearly described, understood and accepted by all stakeholders. Without their support, contribution and acceptance is any project doomed to failure!!!

Change management

In the waterfall approach, all change requests that are raised after the project scope baseline is approved, must be subject to rigorous change management procedure.

A project manager is in charge of putting a change management process in place already in the beginning of the planning phase. The objective is that all project team members understand:

- who can raise a request for change and to whom

- where to find the change request template and how to fill it in (incl. the basic information set...)

- who and when makes a decision about the change request (depending on its type and impact)

- where will be the final decision documented and who is responsible for further implementation of the change in case it is approved.

Changes in a waterfall approach may be an expensive endeavour. If a need for change is recognised too late, it may be very costly to implement it. However, changes are not undesirable. In contrary - they may contribute to a larger project acceptance and success if managed properly. A project manager is always responsible for:

- setting up the change management process

- tracking, controlling and documenting all the steps related to individual change request

- and ... !!! keeping the project triange in balance!!! Any change that may have an impact on resources and/or time must be accompanied by steps that assure that all attributes are always kept in balance.