Project Scope Management in IT Projects


A project is a temporary aspiration undertaken to create a unique product, service or result. The project is finished when the project objectives have been achieved or when the project is terminated because its objectives are not accomplishable any more, or when the need for the project no longer exists.

project scope management

A performing organization assigns a project manager to achieve the project objectives. As the project manager’s role involves managing scope, time, cost, quality, human resources, etc…, a business analyst (BA) can be engaged to perform project scope management.

Since the product and project requirements are provided by stakeholders, they must be identified at an early stage. The identification of stakeholders is a process of finding all people to be impacted by the project and documenting information regarding their interest, involvement and impact on the project. It is vital for the project success to identify them prior to the project scope definition. The failure to identify all stakeholders may lead to missing some requirements and as a result the project objectives won’t be met.

Project scope management consists of the processes necessary to ensure that the project includes all the work required to complete the project successfully.

Collecting Requirements

The first process executed by BA is collecting requirements. BA defines and documents stakeholders’ needs to meet the project objectives because the project success is directly dependent on the care taken to capture and manage requirements. Requirements must be brought to light, analyzed and documented in enough detail to be measured. The statement of work provided by stakeholders speeds up the process of collecting requirements and defining project scope.

There are several techniques and tools used to collect requirements. The most often used technique is interviewing. Information is obtained from stakeholders by talking to them using different communication channels. Face-to-face meetings are the most effective. Apart from that remote communication techniques are widely spread and BA uses skype opportunities a lot to elicit necessary information. Also, emailing is used to get short answers or schedule meetings.

We use a focus group technique involving several stakeholders into one skype meeting to discuss some issues. This technique helps to resolve disputes between stakeholders.

We rarely use Joint Application Development sessions to focus on bringing together stakeholders, consumers and the development team to improve development process. All these techniques and tools result in:

  1. the requirements documentation describing how a particular requirement meets the business need for the project. This document can include: business needs, business or project objectives, functional requirements, quality requirements, acceptance criteria, etc…
  2. the requirements management plan stating how requirements will be analyzed, documented and managed through the project.
  3. the requirements traceability matrix helping to ensure that requirements approved in the documentation of requirements are delivered at the end of the project.

Scope Definition

The second process is scope definition that is necessary for the creation of detailed description of the project and product and it starts when all requirements seem to be collected. The elaboration of the project scope is critical to project success and is built on project deliverables, constraints and assumptions. The scope definition process results in recording of product scope description, product acceptance criteria, project deliverables, project exclusions, constraints and assumptions. Relying on the collected data and documents, the technical persons make work decomposition and a project estimate.

Scope Verification

During the project execution some requirements are met and must be verified according to the acceptance criteria of the completed project deliverables. The completed deliverables are inspected with the customer to ensure that they are completed to a satisfactory degree and to obtain the customer’s formal acceptance. The accepted deliverables are marked as done while the unaccepted ones go back to the development process with additional comments.

The above described procedure is known as scope verification process. It is primarily concerned with acceptance criteria and does not involve QA persons. It is important to see the difference between scope verification and quality assurance because the latter is primarily concerned with correctness of the deliverables and meeting the quality requirements specified for deliverables and performed by QA persons before scope verification.

Scope Control

To save time these processes can be performed in parallel and customers are notified that the deliverables are currently under quality control. If during the scope verification process some new requirements and change requests arise, they are recorded in the change control board.

XBtrack usually serves as a change control board and a bug tracking tool. The tasks marked as a feature are change requests and the tasks marked as a bug are bugs found by QA persons.
When change requests are rejected the reasons for this rejection must be provided. And when change requests are approved they are added to the project scope then estimated, developed and verified.

This is scope control process aimed at monitoring and controlling product and project scope and managing changes of the scope. Controlling the project scope ensures that all requested changes, corrective and preventive actions are subject to change control. Uncontrolled changes often lead to project scope creep then overtime, missed deadlines and as a result the project termination.

Unfortunately, the scope control process is usually omitted as everything looks clear at the initial project stage. At further stages only a few minor corrections are added each time. And in the end it may turn out that the project scope controls us and the project itself is close to collapse. Let’s prevent that and get the project done.


give us a like
The following two tabs change content below.
Vitaly Hornik

Vitaly Hornik

Started as an ASP web-developer in 2000 and then dived into various technologies and web-development lines. Presently, he is deeply immersed in project management and mainstreams the best practices based on the knowledge of PMBOK and CMM for Software.