Contribute to Defining Project Scope

Defining the project objectives is the first step when defining the project scope. In this step, project stakeholders identify the project's overall aim. For example, to speed up a specific process, to solve a customer complaint, or to improve the quality of a specific service.

This step also identifies which project initiation documentation is to be used, who will develop the documents, and how they will be reviewed to ensure they are accurate and complete.

Essential Requirements of a Project Scope

To effectively scope the project, there are several items to be considered. These are essential as they will guide the project in attaining its ultimate goal.

These items are:

• Project Objectives
• Organisational objectives
• Project requirements
• Project initiation documentation

Project Objectives

To assist in identifying project objectives, you will need to participate in one or more meetings to assist the project team in identifying the objectives.

You may do this by accessing information from your team or your project manager in a face-to-face meeting or by using digital meeting tools, e.g. virtual meeting technology such as Zoom, Teams, Skype, etc.

Project objectives may include:

1. Specifications for products and services
   • Project objectives need to be specific, especially when it comes to the product or service being offered as well as some factors that may affect or at least define it, e.g. quality, accessibility, usability, etc.
2. Statements in a measurable format
   • Project objectives need to be measurable, which means the team needs to identify the current state (baseline) and the desired future state, expressed in numerical terms, e.g. reduce errors in the invoicing process from 3% to 1%.

     For this, baseline data needs to be collected and analysed to define a realistic, measurable objective.

A well-defined objective can be written by considering the SMART criteria:

SMART stands for:

• Specific: Describes clearly and simply what needs to be achieved.
• Measurable: Defines a numerical goal, e.g. five days.
• Achievable attainable: Ensures the goal is attainable, which is essential for motivation.
• Relevant: Ensures that the goal is linked to the broader organisational goals.
• Time-bound: Defines a target date by when to achieve the goal.

Example of how to write a SMART goal

The current problem:

An organisation that is producing books is experiencing customer complaints that are related to a specific quality issue. The issue relates to the bookbinding not being strong enough, causing the book to fall apart quickly.

The following steps outline how the SMART goal is developed step by step.

1. Be Specific
   • The quality issue must be defined so that it is clear which issue should be addressed in this project. In this case, the quality issue customers are complaining about is that the bookbinding is not strong enough.
2. Include Measures
   • Each goal statement must include a measurable goal. In this case, customer complaints should drop from 3% to 0% of customers complaining about the bookbinding problem.
3. Make sure the goal is Attainable
   • This means that the goal of reducing the complaints must be realistic and achievable. In this example, reducing the complaints to 0% may not be realistic, and a more achievable goal may be to reduce complaints from 3% to 0.5%.
4. Make sure the goal is Relevant
   • This means that the goal of reducing the complaints must be in line with the organisation’s strategic goals and objectives. The reduction of customer complaints would support the organisation's goals and success.
5. Make goals Time-bound
   • This means that a timeline for achieving the goal should be determined, for example, within three months or by 20/10/202X.

Finally, the SMART goal can be formalised into one or two sentences like this:

Organisational Objectives

The project objectives must support the broader organisational objectives. Organisational goals may relate to increasing market share, improving quality and reputation, developing new products and services, etc. Those are outlined in the organisation’s strategic plans, which you need to access and review to ensure that your project objectives support the high-level organisational goals and objectives. For example, improving the quality of an existing product is well aligned with the organisation’s goals of improving its reputation in the market. However, implementing a new internal data management software would not be aligned.

It is crucial to consider the organisational objectives during project scoping as resources will be expensed for the delivery of the project. Those expenditures could be considered a waste if the project does not help support the organisation’s strategic plan.

Therefore, referring to the strategic plan during the scoping meeting is a good idea to verify the alignment.

Project Requirements

The project requirements should be identified by the project team and the project stakeholders. These requirements, like project objectives, should also be specific and measurable.

These may relate to the following:

• Timeline requirements, e.g. project due date
• Staffing requirements, e.g. requirement for specific types of subject matter experts that must be part of the project
• Resource requirements, e.g. which materials, parts, or software are needed
• Budget requirements, e.g. budget of $20,000

The purpose of defining the project requirements at the start of the project is to define guiding principles and ensure that all project activities aim to achieve those requirements. By defining a project budget, for example, the project expenses can be monitored and compared to the budget regularly, e.g. weekly, whereby ensuring that any cost overruns are identified and addressed early to meet the budget requirements by the closure of the project.

The best way to identify the project requirements is by holding a formal strategy meeting with your project manager and the project authorities in order to identify, agree on, and document the specific project requirements.

Timeline requirements

Estimating the duration is essential, as a longer duration will inevitably lead to higher costs, even if they are just the administrative costs related to monitoring.

Your first starting point here would be to identify the deadline for the project from your project manager. The deadline is the expected project closure date. This may be a ‘nice to have’ deadline, or this may be driven by deadlines set by customers or other requirements.

If there is no deadline, then the duration of the project must be estimated from task durations. At this early point of the project, a work breakdown structure with detailed activities and tasks is usually not available. This means that at the scoping phase, a very rough estimation may be made based on experience and past projects to determine the project duration.

As the project becomes more detailed during the planning phase, the duration becomes clearer and can be updated and, if needed, renegotiated.

Staffing requirements

Each project must be staffed. This means that the most appropriate stakeholders are being selected to deliver the project. Those stakeholders will need to have the skills and knowledge required to deliver the project and may be made up of the project manager, project administrator, process owners, subject matter experts, customers, etc. For example, there may be a need for the head of the Information Technology (IT) department to participate in the project if the project requires a software specialist.

All stakeholders and their contributions and needs should be documented in the Stakeholder Analysis Form, discussed later in this topic.  

Resource requirements

The resource requirements relate to all resources required to scope, plan, implement, control, and monitor the project.

Those resources may include:

• Labour Cost – Labour costs relate to the time spent and costs incurred through the internal staff. The more hours they spend, the more costs are incurred, as labour is always based on a rate, e.g. hourly rate, daily rate, etc.
• Procurement Cost – The project may need external support. By engaging, for example, a contractor to complete parts of the work scope, the project will incur procurement costs. Once the contractor has completed their work, they will send an invoice and need to get paid.
• Purchases – The project may also require purchases to be made, e.g. for raw materials, licences, software, consumables, or others. They will get purchased and invoiced to the organisation and your project.

Budget requirements

The budget requirements are the required finances to acquire all resources, such as labour, parts, materials, software, licences, etc. The budget is established from the estimated resources for each milestone, activity, and task. These costs are best established after the work breakdown structure has been developed. Then, individual resources and costs can be estimated for all tasks and aggregated to the total project cost.

Project Initiation Documentation

Project initiation documentation means putting together and documenting essential information in a document, called the project initiation document (PID), that is needed to start a project. Its primary purpose is to define the project and form the foundation for the project management and assessment of the project's overall success.

The PID has four main uses:

• It guarantees that the project has a solid basis before the project board makes a significant commitment to the proposed project.
• It serves as a core document to be based on by the project board and project manager for the project's progress and any questions and issues.
• It provides a source of reference for other team members to find out what the project is about and how it is being managed.
• Once the project is approved, it is used as a basis for performance assessment throughout the project.

In preparing and creating a project initiation documentation, you need first to consult if your organisation already has its own PID template. This will help you get familiar with the information needed for the PID. It also helps maintain consistency and easy comprehension since you will be using the PID template again in another project. Of course, projects come in various forms, and therefore, you may customise the PID template to fit precisely your project.

If in case your organisation does not have a PID template, you should create your own PID for the project. To assist you, listed below are the documents and information needed in your PID.

Project Background

The project background describes the context of the project and how the project or its proposal came to be. You should discuss here the problems or the opportunities that arose as well as the relevance of the project to solve them. This part does not need to be detailed in the PID but may need supporting information later.

Project Definition

Simply put, the project definition establishes the project. The following points are needed to properly define the project:

• Purpose – It presents what the project is intended to do. You should describe the desired outcome of the project.
• Objectives – These are the specific results the project should achieve and may include the methods of measuring the success of these objectives. Take note that the number of objectives should only be small; four to five goals should do.
• Scope – It defines what is and is not included in the project. In defining the scope, you should consider your stakeholders’ perspectives on what is included and excluded in the project. Examples of areas to consider are the nature of work to be done, the specific location to be covered or affected, and specific aspects to deal with.
• Deliverables – Project deliverables are expected outputs (e.g. services or products) that mark the completion of a project, phase, or the project itself. Deliverables include the estimated date they are achieved or completed.
• Constraints – These are external variables that may be out of your control but still need to be managed as they influence the project.
• Assumptions – These are factors that are considered to be true or certain without proof or demonstration.  

Business Case

The business case presents the reason why you are proposing the project. It describes how the project will affect the company or organisation as well as the stakeholders and helps determine if the project is worth investing in and committing to.

The following points are needed to properly define the business case of the project:

• Benefits – These show the advantages of going ahead with the project. You should include information on how the benefits are measured.
• Alternatives – These are other courses of action that were considered as the project was being conceptualised. They provide options in case the project board and stakeholders do not approve the project proposal.
• Budget – It is the breakdown of the project costs and other finances related to the project. These can be estimated based on industry data and information as well as previous experiences and projects.
• Cost/Benefit Analysis – It is a financial analysis technique that determines the benefits/outcomes of the project against the total cost of the project.

Risk Management

Risk management deals with the identification of risks and their impact on the project. It is also concerned with implementing processes to control, manage, and monitor these risks. Specifically, the risk management process includes:

• Risk Identification – It pinpoints the risks that can be found in the project. Make sure to identify all risks in the project and list them in a risk register.
• Risk Analysis – This involves evaluating the impact of the risks to the project itself, as the risks can affect or even change the project objectives, deliverables, and other key aspects. The impact can be qualitative or quantitative.
• Risk Control – It describes the plans, procedures, and tools to use to eliminate, mitigate, or manage the risks within the project.
• Risk Monitoring – This is the process of tracking the existing risks within the project, as well as updating and reporting these risks.

Roles and Responsibilities

These identify and describe who consists of the project management team. Outlining the roles and responsibilities early on helps present what is expected from those participating in the project. The following points are needed to properly define the roles and responsibilities within the project:

• Project Organisation Chart – This indicates the structure and hierarchy of the project management team through a diagram. It also shows the line of authority.
• Project Sponsors – They are the ones who have authority and control over the project by providing resources and support to the project.
• Project Manager – The project manager is the key member of the team tasked to lead the project and achieve its objectives and deliverables. Indicated here also are the project manager’s responsibilities specific to the project.
• Project Team – Included here are the roles and responsibilities of the members, their contact details, the department they belong to, and their team leader or supervisor.

Initial Project Plan

The initial project plan provides general information on how the project would be implemented early in the project’s development. As the project progresses, you should update the project plan with more details. The details in the project plan include:

• Assignments – They comprise the tasks or activities that will be completed during the project, including specific milestones to be achieved in different parts of the project.
• Schedule – It indicates the estimated time involved in the project, including anticipated delays due to predictable events.
• Human Resources – It presents the number of staff, as well as their schedules needed to perform the tasks in order to complete the project.
• Project Control – It describes the processes needed for project monitoring, communication, and changes.
• Quality Control – It outlines the methods and tools used to monitor and assess the quality of work and outcomes of the project.

With the various information and details mentioned above, it is apparent that project initiation documentation is very crucial at the beginning of the project. It presents the overall purpose and framework of your project. Also, it helps present these details to everyone involved in the project so that they know what the project is about and how it is implemented.

Project initiation documentation may include a range of different documents, such as the following:

• Problem Statement
• Project Scope Statement
• Stakeholder Analysis
• Project Charter
• Business Case
• Feasibility Study
• Statement of Work

Problem Statement

It may be part of the project charter or other relevant scope documents. Like project objectives and requirements, the problem statement should be clear, specific, and measurable.

Project Scope Statement

The scope of the project comprises all the tasks and activities required and only those required to achieve project objectives and deliverables. In essence, it defines what the project will produce. Part of creating the project scope are:

• Creating a project scope statement, which describes the scope, deliverables, assumptions, and constraints of the project in detail
• Identifying client and stakeholder needs and requirements
• Selecting the final project requirements and deliverables, according to stakeholders and project organisation
• Subdividing the requirements and deliverables into smaller manageable components through work breakdown structure
• Planning on how to manage the project to adhere to its scope.

The project scope statement is a part of the overall project scope. The following elements are documented and detailed in the project scope statement:

• Project Name
• Project Scope
  • Inclusions (what is addressed by this project, e.g. a specific process)
  • Exclusions (what is not addressed by this project, e.g. specific process not addressed)
• Assumptions made
• Constraints (e.g. budget constraints)

Example of a basic Project Scope Document

The project scope document below shows which processes are within and out of scope, the constraints relating to the timeline and budget, as well as the deliverables to be achieved by the end of the project.

Stakeholder Analysis

Most projects have several different stakeholders involved. These stakeholders are collectively known as project stakeholders.

A project stakeholder can be:

• The sponsor of a project (the person or company paying for it)
• Anyone who has an interest in the successful completion of the project
• Anyone who may have a positive or negative influence in the process of completing the project
• Anyone supporting the project

Depending on the project, stakeholders may include:

• Project manager
• Sponsors
• Supervisor
• Project team members
• Consultants
• Suppliers and contractors
• End users/end customers

Stakeholder analysis involves gathering and analysing both quantitative and qualitative information regarding the stakeholders. The analysis helps to:

• identify the stakeholders’ interests, expectations, and influence on the project
• determine whose interests should be taken more into account throughout the whole project
• build stakeholder relationships, both with the project itself and other stakeholders.

Stakeholder analysis usually consists of the following steps:

1. Identify all potential stakeholders to the project and their information.
   • This includes their knowledge, interests, and expectations, as well as their roles, departments, and influence in the project. Key stakeholders include anyone with a decision making or managerial role who is impacted by the outcome of the project. Other stakeholders can be determined by interviewing identified stakeholders to expand the potential list.
2. Analyse the impact or support that each stakeholder could potentially generate.
   • You should classify them to be able to create an approach strategy. In this stage, you should determine if there are conflicts of interest between a stakeholder and the project and other stakeholders. When there are many stakeholders, you should prioritise the stakeholders to ensure you can communicate and manage their expectations well.
3. Assess how key stakeholders react/respond in a variety of situations.
   • This information is used to plan how to be able to influence the stakeholders to enhance their support and mitigate potential negative impacts. The assessment will help identify which stakeholders possess better judgement that will help when making decisions for the project.

Stakeholder Analysis Template

You can use the following template to help you identify all of your project stakeholders, their information needs (e.g. a weekly status report), and how to satisfy those needs (e.g. develop a status report and send it via email every Friday by 2 pm).

Click here to download a copy of the Stakeholder Analysis template. 

Project Charter

It is common practice to start a project by developing a project charter before developing the project plan. The project charter provides a high-level overview that the project manager needs before they can start working on the project plan.

This document formally authorises a project or a phase that documents the initial requirements that satisfy the stakeholder’s needs and expectations. It provides the overall high-level description of the strategies and goals of the project. The project charter covers the following important sections:

The following example shows the project charter for a high-rise building project:

Business Case

A business case combines the problem statement with the measurable project objective. The purpose of the business case is to convince the organisational authorities, e.g. the department manager, to approve the project. It must, therefore, clearly outline the benefits that may be gained through the project implementation. This is often done in terms of dollar savings but can also be related to improving the organisation’s image, market share, quality, etc.

A business case can also contain more information, such as the project approach, limitations, and approach.

Feasibility Study

A feasibility study evaluates the various risk factors and assumptions made, which may relate to technical, economic, and many other factors, to ascertain the likelihood of the project’s success. The success of conducting and reviewing a feasibility study establishes how feasible the project is to deliver on its objectives.

The feasibility study will differ depending on the project objectives but may collect and analyse data relevant to the following aspects:

• Resources and technology that may be needed to deliver the project
• Required resources that will need to be made available
• Likely legislative and organisational changes that may impact the project.

Statement of Work (SOW)

A statement of work is a similar document to the project charter. It also outlines the project-specific scope, deliverables, timelines, tasks, schedule, terms and conditions, etc. The project charter is often created after the statement of work has been agreed upon.

Other documentation that may need to be referred to during project scoping may include the following documents:

• Organisation strategic and business plans
• Business needs analyses
• Outcomes and recommendations of associated projects
• Lessons learned from associated projects
• Minutes of management or executive decisions
• Changes to internal or external organisations, legislation and/or regulations

Factors Impacting on Scope

Many factors can impact the scope of a project. Common factors that define and potentially limit the project scope are the availability of resources and the desired finish timeline. For example, the department may only have an available budget of $10,000 and a requirement to complete the project within two months. Those factors can dramatically limit the project scope, meaning that the project may only be able to focus on one particular product, service, or process rather than several others.

The following table outlines common factors:

Participate in Identifying Project Objectives and Requirements

Part of your role in the project will be to participate in identifying project objectives and requirements. This step requires that you contribute to project scoping meetings to the identification of:

• Project objectives
• Project requirements
• Project deliverables
• Measurable outcomes to be used in evaluating project performance

The identification of this information will usually occur in the form of a meeting, where you are required to contribute to the discussion, make suggestions, provide constructive feedback, and document the outcomes of the meeting using a meeting minutes template. You may use your organisation’s meeting template or the one provided later on in this learning material.

Participating in such meetings will require that you do so proactively and respectfully. This should include:

• Inviting relevant project stakeholders to the meeting by sending a meeting invite
• Developing and sending out a meeting agenda with the invite, including what to prepare and bring to the meeting
• Start the meeting by introducing the aim of the meeting
• Run the meeting by sticking closely to the agenda items, ensuring everyone can provide input, and taking meeting minutes
• Ensure the meeting is starting and finishing on time
• Provide ideas and input proactively, without being asked and listen to other’s suggestions
• Be open-minded to other’s ideas and assess them in a professional and unbiased manner
• Ensure the meeting stays on topic
• Allow short breaks if the meeting is long
• Thank everyone for attending the meeting
• Follow up by sending out the meeting minutes and agreeing on action items
• Ask for feedback and use this feedback to improve the next meetings

Review Project Initiation Documentation

Other stakeholders are developing the documentation that was discussed so far, and part of your role in the project will be to review the project initiation documentation. This review will include checking that all project initiation documentation is complete and accurate, including the project charter, the project scope statement, and other relevant documents discussed earlier.

This review aims to confirm:

• That the information in these documents is consistent with what has been discussed and agreed upon by the project stakeholders, and
• That the documents comply with relevant organisational policies and procedures.

You may use a documentation review form for this task to document the outcomes of the review. Refer to your organisational policies and procedures relevant to project initiation documentation during the review. These policies and procedures will provide information on which documents are to be developed, the required information to be populated, the level of detail, etc.

Check your understanding

Read the following statements and decide whether they are TRUE or FALSE to test your understanding so far:

Project deliverables are the tangible outputs that the project will produce. Those then lead to the achievement of the project objectives. They are also often referred to as ‘project products,’ which are produced as a result of the work performed as part of the project.

Every project has a set of deliverables to be achieved and delivered by defined milestone deadlines and at the end of the project.

Project deliverables relate to:

• Discrete products, outputs and services defined in the project scope

  These are outputs at the end of the project, e.g. a new or improved invoicing process, form/template, policy, procedure, or product design.

• High-level aggregations in the work breakdown structure

  These are outputs at the end of milestones deadlines, e.g. a draft version of the new process, procedure, or product.

You can contribute to identifying project deliverables by participating in the project scope meeting and suggesting deliverables that should be included in the project plan. The project client may partially define those; however, many deliverables will need to be still defined as part of the planning phase.

When identifying deliverables, consider that there are different types of deliverables:

• Planning deliverables, such as budgets, schedules, project charters, research outcomes, risk analysis
• Internal deliverables, such as reports, meeting minutes, prototypes, and test results
• External deliverables, such as a drawing, manuals, and procedures that you would provide to the client as part of the handover at the end of the project.

Check your understanding

Read the following project objective, then think of possible deliverables:

"Implement a new customer relationship management (CRM) system to improve customer data management, streamline communication, and enhance customer support for the company by the end of Q2."

As discussed earlier, it is critical that the project scope statement and project charter, and all other relevant project information, contain measurable outcomes, including:

• Measurable objectives
• Measurable requirements, such as:
• Timeline
• Staffing
• Resource
• Budget

These measurable objectives and requirements are essential, as they enable the project team to:

1. Set a target
   • This allows everyone in the team to know what the project aims for.
   • For example, the process target is 10 minutes; the task should be completed by 20/2/2021.
2. Set a limit
   • This provides limits to the project team.
   • For example, a limit on spendings through a defined budget of $5,000.
3. Monitor progress and outcomes against targets
   • Measurable outcomes and targets allow stakeholders to measure progress against targets and identify the status, e.g. in front, behind, or on target.
   • Identify the gap towards targets
   • For example, the goal may be to reduce process time by 10 minutes, and a 6-minute reduction has been achieved. This means that there is a gap of 4 minutes.
   • Identify if a scope change is required
4. Identify the gap towards targets
   • Identify if a scope change is required
5. Identify if a scope change is required

Project performance can be measured in the following ways:

• Monitoring of costs and budget
• Monitoring of the schedule
• Monitoring of the quality parameters
• Measuring the Return on Investment
• Stakeholder and customer feedback

Check your understanding

The scope management plan describes how the scope will be defined, monitored and controlled. Its purpose is to ensure that the project scope is met and kept up to date to reflect the required scope changes.

Developing a Scope Management Plan

There are many components of a project scope management plan. These include, but not limited to, the following:

Established change control procedures

Procedures that should be defined as part of the scope management plan include:

Watch

The following 5-minute video explains what a WBS is and how to create it:

As mentioned before, a work breakdown structure should be made from the detailed project scope statement. As the name suggests, a work breakdown structure is a visual display of a project, product, process, or service broken down into smaller components. Working with your team in creating the WBS is an essential step to take in order to identify all project milestones, activities, and tasks, as well as to correctly determine the project scope, plan, and cost.

The WBS identifies all project milestones, activities, and tasks where:

• Milestones are high-level project steps,
• Activities are medium-sized steps within the milestone, and
• Tasks are small steps within each activity.

Hence, the WBS follows a format suitable for a step-by-step identification of these elements. The format is shown below:  

For instance, in the construction of a building, the primary functions could include certain milestones and activities as outlined below:

• Foundation work
  • Excavation
  • Laying foundations
  • Utilities
• Structural construction
  • Exterior framework
  • Interior structural columns
  • Lifts
  • Doors and windows
  • Utilities
• Decorating
  • Painting
  • Carpets
  • Furnishings
  • Signage

This can be represented by the following WBS:

Theoretically, each of the items can be divided and subdivided down further. For instance, painting (under decorating) can be subdivided into tasks.

See the example below.

• Decorating
  • Painting
    • Attain materials
    • Preparation
    • Painting
    • Cleaning up

This can be broken down further into specific tasks:

• Decorating
  • Painting
    • Attain materials
      • Order paint
      • Order painting equipment
      • Order other consumables
    • Preparation
      • Fill holes and cracks
      • Sanding
    • Painting
      • Undercoat
      • Low sheen topcoat
      • Enamel skirting boards, etc.

As you can see, you can use the WBS to break down a project into numerous milestones, activities, and tasks. Breaking it down into multiple levels will assist significantly in the planning of the project and its costs.

Performance measurement indicators

The project's performance can be measured against target key performance indicators and agreed scope management processes and procedures. The performance should be measured on a frequent and regular basis, e.g. weekly. This allows for gaps and variances to be identified as early as possible before they become a massive problem.

Measuring performance against key performance indicators

Key performance indicators (KPIs) are measurable objectives. For example, a targeted process should be reduced from 10 minutes to 5 minutes. This is measurable and, therefore, easy to identify if your project has or has not yet achieved the target. It also helps to identify the gap to the target, e.g. 4 minutes.

Key performance indicators require data to be collected and analysed to identify the baseline and current performance. In this example here, the baseline of the process is 10 minutes. This would have been identified by collecting data over time and calculating the average process time.

Examples of KPIs:

• Number of sales per month
• Hours of overtime per week
• Process time in minutes
• Task duration in days
• Defect rate in %

Measuring performance against agreed scope management processes and procedures

This can be done by auditing the project regularly against the agreed processes and procedures to establish compliance with those and identify any non-compliances and variations.

A measurable indicator would be an audit score. For example, each established process could have a check criterion and a score from 0 (non-compliant) to 5 (compliant). By adding up the total score at the end of the audit, the performance indicators can be established, which will indicate how well the project stakeholders are following the agreed scope management plan.

Internal audits can be conducted using a range of methods to ensure a thorough assessment of processes and compliance. Here are some common methods:

Click on each method to learn more.

Documenting a Scope Management Plan

Documenting and communicating the scope management plan is essential to ensuring that it will be followed. In this way, project stakeholders can refer to the documented plan at any given time, using it as a reference. Scope creep can be an outcome of not documenting and following the scope management plan. Scope creep refers to uncontrolled changes to the baseline scope. For example, the project timeline may creep out from what was planned without being accounted for in additional time or budget. If the project management plan is documented and followed, then such creep may have been identified very early and prevented. However, by not following the scope management plan, the scope creep can become massive and put the entire project at risk.

Scope Management Plan Template

A scope management plan is best documented using a simple template such as the one below. The information will be identified as part of a project team meeting with your project manager and relevant project stakeholders. Alternatively, the plan can also be documented using a formal workplace procedure template.

Click here to download a copy of the Scope Management Plan template.

Technology in Project Management

Project management software, such as Monday.com, Jira, Asana, Trello, Smartsheet, etc., enhances organisation and communication. This can be essential for the success of larger projects or projects with multiple stakeholders working from different geographical locations. You can create a variety of project documentation using a project management software of your choice.

In Asana, for example, you can consider the main project as the "Portfolio," which encompasses the overall initiative or program. Within this portfolio, you can create individual projects for specific components such as risk management, scope management, and other documentation. Each of these individual projects would then contribute to the larger portfolio, allowing you to track and manage their progress while maintaining an overview of how each part fits into the overall objective. This structure helps ensure that all aspects are aligned and contributes to the success of the main project.

Using a project management software like Asana to create a scope management plan offers several key benefits:

• It allows project managers to clearly define objectives and deliverables, break them down into manageable tasks, and assign responsibilities, all within a centralised platform.
• The software provides real-time updates, which helps track progress and ensure accountability.
• Features like task dependencies, deadlines, and automatic notifications ensure teams stay on schedule.
• Additionally, Asana’s collaboration tools, such as comment threads and file attachments, streamline communication, while built-in reporting features help monitor scope changes and maintain alignment with project goals.
• The software improves accountability and risk management through clear task assignments, tracking, and detailed reporting, enabling more effective project execution and decision-making.

Watch

The following 12-minute video explains how to create and set up a project on Asana.

For a more detailed step-by-step tutorial on how to set up a project on Asana watch this video.

The project scoping phase can be concluded by the time all project parameters are established and accurately documented using the correct project initiation documentation.

Once you have checked that all documentation is complete and accurate, you can submit the final project scope, together with all relevant information (e.g. stakeholder analysis, business case), to the relevant project authority for review to confirm all data is accurate and complete and for approval.

Relevant project authorities typically include:

Click on each to learn more.

Read the following case study, then try to answer the questions that follow to see whether you can interpret a project brief: