Defining the scope of your project is crucial to the project's success. From an early stage, it's important both to know and to control the project outcomes and benefits. Scope management is defined as the process required to ensure that the project includes all the work required and only the work required to complete the project successfully. It is primarily concerned with defining and controlling what is and what is not included in the project. Scope management is centred around three main endeavours. Firstly, defining the scope. Secondly, controlling changes to the defined requirements of the project. And thirdly, managing scope creep or similar problems. Let's consider the main phases of scope management as described by the "Project Management Book of Knowledge", the PMBOK. The first phase is the project planning, the scope planning. At this stage, the project team formulates the project's scope statement, the management plan, and any other documents aiming to define the project's scope. The second phase is the scope definition. The project team refines the project scope statement as the basis of future project decisions. At this stage, the project team develops the so-called Work Breakdown Structure or WBS. The WBS is a hierarchical representation aiming to break down the complexity of the project. It breaks the project down into workable and easily manageable chunks. During the scope definition, the project team starts developing the WBS: in particular focussing on the aggregate or higher levels. After this, the next phase is the scope verification, which is focussed on the verification of the work identified in the previous stage. The final phase is scope control, which involves comparing the planned scope and the actual work and making decisions based on these. At this stage, you can either accept the work performed or implement mitigating actions to adjust unexpected scope performance. The complexity of the scope management process depends on the type of project considered. Before introducing major projects, let's think about more simple projects, like projects internal to corporations, such as the development of a new product. Internal projects are carried out within a single organisation and therefore, they are simpler in terms of scope management. In internal projects, the organisation begins by providing a project statement, which is a kind of definition of the project. The project statement is the first instrument: it outlines the objectives of the project and it defines its boundaries in a concise and descriptive narrative, which is around one or two pages in length. This is the starting point for the scope management. The second instrument called the project charter provides a more defined and clearly articulated definition of the project's scope. The project charter provides additional information as it introduces the internal project team. This means that the project charter has clear implications on the institutionalisation of the project team as it attributes power to the project managers and other their relevant responsible people. In addition, the project charter provides the formal process to manage and authorise changes in the project scope. Generally, the project charter includes the background of the project, the key assumptions, and the commercial needs. In practice, the project charter is built on the project statement and it provides further information. It: outlines the scope of the work, identifies the key activities, budgets, and dates, provides a short statement about how the project is to be managed, it introduces the role of the project manager and finally, it outlines the reporting structure. In summary, the project charter provides a general normative structure for the project. Typically, the project charter assumes a specific documental form. As we can see here, it provides the title of the project, specific information, such as codes and the identification numbers related to the project to address all the items we have already listed. The project charter provides a clear line of responsibility internal to the project. Now, let's look at something more complex and focus on the scope management in external projects. This project is not necessarily a big project, but it is external to the client. Therefore, in this case, the project charter is insufficient in identifying responsibilities and outlining the scope. In the simplest case, the project involves two actors: the client and the contractor. In such scenarios, part of the scope management focusses on the relationship between these two actors. For example, the client engages an external contractor to carry out the work. Part of the scope management is handled by the project contract, specifying a number of things: including the scope of the project, the terms and conditions, the responsibilities and roles of the two parties involved, the economic compensation that the client provides to the contractor, and how this compensation is provided. It also includes provisions related to how to handle the relationship between the client and the contractor, either in normal working conditions or in case of litigation. The contract introduces a workable framework to amend the project scope during its implementation. Obviously, changes in the scope during the project's implementation are expensive, and the contract assigns decision making powers, as well as the method to quantify and to assign the extra work that is created by such amendments. If the contractor is a single organisation, it can work in the way we have outlined. So, it can produce a product charter to manage its own role in the project. In internal projects, the project statement is included into the project charter. Conversely, in external projects, the project statement is included in the project contract and then included in the contractor's project charter. In construction projects, the situation is often more complex. Sometimes, the contractor itself subcontracts part of the work to a subcontractor. This means that the scope is further broken down by means of multiple contracting transactions. As we can see in this later case, scope management is much more complex because it is fragmented across multiple instruments and it is co-managed by multiple organisations. In major projects, the level of complexity is even greater. So, as we can see here, with respect to the scope management, there is not only one contract, but a network of contracts. In this case, the scope management is handled similarly to external projects because there are many contracts which are interlinked. There is an additional layer of complexity. As a result, the relationship ordinarily managed by the project contract, is far more dispersed and more complex. As we have seen, it's very difficult to generalise about scope management: we need to consider the specific context. We have seen that in major projects, there are specific challenges because there are many parties involved in the project. The fragmentation of both the project scope and the organisations involved in the scope management activities create significant challenges.
