5.2.01.3TS Scope Definition - Process - Large Projects

The following sections show how projects are planned. A small project might be planned and approved through a Service Request Process. Larger projects need more formal approval processes and more formal Project Plans.

This supplemental content comes from the TenStep Project Management Process.

Large Project Overview (1.1.3.P1)

Large projects definitely need time up-front to define the work. If you do not adequately define a small or medium project, the consequences will probably not be too drastic. Even if your project is estimated to take 500 hours of effort, and it takes twice as long to complete the work, it still won’t be catastrophic for your company. However, you don’t have that same luxury in a large project. For instance, if you estimate the work at 10,000 hours based on an inadequate definition process, and the actual project takes 20,000 hours instead, the results could have a material impact on your organization and your entire company.

In general, the larger a project is, the more time it takes to define the work. You also need to make sure that you have enough information to validate that you know what you are doing. You need to have enough information defined and documented so that you can gain agreement with your sponsor on the project objectives, the deliverables, the estimated cost and duration, the scope, etc.

Click here to view flowchart for this process.

The process of defining a large project is similar to that of a medium-sized project. The difference is that there is more information to define, and the length of time required to complete the definition process is necessarily longer and more complex.

In addition to a Project Charter, large projects also need a more formal Project Management Plan. This Plan contains the detailed plans that you will use for managing the project, including a Communications Management Plan, Risk Management Plan, Scope Management Plan, etc. These individual plans are referred to as “Subsidiary Plans”.

These subsidiary plans are not required for small and medium-sized projects since the project management processes are more straightforward. For instance, let’s focus on risk management. A medium-sized project can probably get by with a standard risk management template that contains information on the risks and what you plan to do about them. On a large project, there is more to consider in terms of how you will manage risks. This Risk Management Plan can highlight the same risk management template as the medium project, but you might also need to consider risk management tools, a Risk Manager role, external audits around risk management, etc. This more complex management of project risk on a large project is the reason a standalone Risk Management Plan may be needed.

There are two major components to defining the work on large projects – creating the Project Charter and Creating the Project Management Plan. Both of these important deliverables are described next.

Create Project Charter (1.1.3.P2)

his section focuses on the process to create a Project Charter for a large project.

 

Role

Defining a Large Sized Project

1

Project Manager

Gather baseline information.

Look for all the information that may already be available for this project. This includes any previous project deliverables, memos, emails, etc. In many cases, before the project begins, the client must perform some type of high-level cost/benefit analysis or value proposition, although this might not be mandatory for these medium projects. All of this information should be gathered as a starting point for understanding the work to be done.

2

Project Manager, Sponsor

Determine the approval process.

Work with your manager and the project sponsor to understand the approval process for the Project Charter. For instance, determine whether the sponsor wants to approve the charter before other stakeholders, or whether the sponsor wants to have the final approval after the other stakeholders have reviewed the work. You should also determine the people that actually have to approve the Project Charter versus those that should just receive a final copy.

Scope Definition (1.1.3.P3)

3

Project Manager, Key Stake-holders

Meet with the key stakeholders to define the work.

Meet with the appropriate stakeholders (managers, clients, team members, interested parties) and try to understand their perceptions of the work being requested. Before you meet with the various stakeholders, make sure that you are familiar with the basic information that is required to define a project of this size. If you are not sure of the information to gather, you will not be prepared to ask the right questions. You can review the Project Charter deliverable template to see what is required. This information includes:

  • Executive Summary (optional). The full Project Charter document may tend to become large and difficult for the senior managers to digest. You can include an Executive Summary for managers to read. The Executive Summary is an overview of the actual Project Charter document. It is not just an overview of the project.

  • Project Overview. State the purpose of the project and what it is trying to achieve. Discuss the business benefit of the project. Share the overall business goals that this project is contributing to.

  • Project Objectives. State the objectives that the project will achieve. The project objective should support the business goals and objectives. The deliverables produced should support the project objectives. For further information on goals and objectives, see 1.2.1 Define the Work / Goals and Objectives.

  • Project Scope. There are two parts to the scope section – deliverables and boundary statements. For each deliverable, provide a high-level description. Also add information that describes what the project will not produce. In other words, what is out of scope? It is very important to be clear about what things the project could produce, but will not. This will make it much easier to manage scope change throughout the project. In addition to the deliverables, you should further describe scope in more specific terms such as:

    • The data the project needs and the data that is out of scope

    • The organizations affected and those that are not affected

    • The business processes that are in scope and out of scope

    • The business transactions that are in scope and out of scope

    • Any other projects that are impacted

    • Any other in-scope / out-of-scope qualifiers that make sense

    • See 5.0.1 Defining Scope for more details.

  • Estimated Effort Hours. Estimate the effort required, and provide information on how the estimate was prepared. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate (± 10%). For further information, see 2.1.1 Build Schedule / Estimating.

  • Estimated Duration.  Once the effort hours are known, you can estimate how long the project will take to complete (duration) based on an assumption of how many resources will be applied. If the start-date is known, the estimated end-date can be determined as well. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate (± 10%). For further information, see 2.1.1 Build Schedule / Estimating.

  • Estimated Cost. Estimate the cost for labor based on the effort hours, and add any non-labor expenses such as hardware, software, training, travel, etc. You may need to be working on the schedule at the same time as you are working on the Project Charter to be able to provide an accurate estimate (± 10%). For further information, see 2.1.1 Build Schedule / Estimating.

  • Major Assumptions. There may be external conditions or events that must occur for the project to be successful. If it looks more than likely that these events will occur, they should be listed as assumptions. (The definition for assumptions is stated with more precision in the 7.0 Manage Risk section.) Assumptions can be identified through your own experience of knowing the activities or conditions that are likely to occur in your organization over the life of the project; brainstorming sessions with the clients, stakeholders and team members; and by looking at items that were identified as low risk in the risk management process. For further information on assumptions, see 7.1.2.2 Assumptions and Risks.

  • Major Risks. There may be future external conditions or events that will cause problems to the project if they occur. If there is a good likelihood that any of these events will occur then they should be identified as a risk. (The definition for risk is stated with more precision in the 7.0 Manage Risk section.) For further information on risks, see 7.1 Manage Risk / Process.

  • Project Constraints. Constraints are events or limitations that are outside the control of the project team and need to be managed around. They are not necessarily problems. They are not risks since they are 100% likely to occur. They are facts. Date constraints, for instance, imply that certain events (perhaps the end of the project) must occur by certain dates.

  • Project Dependencies. List any other projects that are in progress of pending that have a dependency with your project. These dependencies are deliverable-based. That is, a project will pass a deliverable to you or you will pass a deliverable to the other project.

  • Project Organization. The organization chart for a large project usually has many boxes that reflect involvement from various stakeholders. For instance, the project may have a formal project manager from the client organization that also reports to the project sponsor. There may be a high-level executive sponsor, as well as a lower-level project sponsor to represent the sponsor on a day-to-day basis. Key stakeholders may be organized into a steering committee to provide overall strategic guidance to the project. Vendors or suppliers may have a formal role and would need to be represented in the organizational structure (the three major ways that project teams are organized are described in 1.2.4 Project Organization). Many of the specific project roles are described in 1.2.2 Roles and Responsibilities.

Large projects may also benefit from defining how deliverables get created and approved. This is described in further detail in 1.2.3 Responsibility Matrix.

Another helpful technique for larger projects is to perform a stakeholder analysis to make sure you understand who the stakeholders are and what their needs are. This is further defined in 1.2.5 Stakeholder Analysis.

Template: Project Charter 

4

Project Manager

Create your first draft of the Project Charter.

A draft of the project schedule and budget should be started, given as much information as is known at this time. Information from the schedule is used as input into the Project Charter, and information from the Project Charter is simultaneously used to help build the schedule and budget. See 2.0 Build the Schedule and Budget for more information on building the schedule. Make sure you write the content for the benefit of the reader- not for your benefit. The information should be easily understood by the reader.

5

Project Manager

Circulate initial draft of Project Charter.

Circulate the Project Charter in draft form to gather feedback and build consensus. The first drafts may go to a small group of interested parties. The project schedule does not normally need to be circulated unless there is a specific request to look at it.

6

Project Manager

Update the Project Charter based on accumulated feedback.

Update the Project Charter with any feedback from the initial draft circulation. All the feedback will not be valid. The project manager and sponsor should determine what feedback is appropriate and adds to the clarity and completeness of the document.

7

Project Manager

(Optional) Circulate the revised documents to a larger group of interested parties for one more round of feedback

Update the documents again based on this feedback.

Scope Verification (1.1.3.P4)

8

Project Manager

Get the Project Charter approved.

Use the same approval process that was defined earlier in step 2 above.  See the 1.2 Define Work / Techniques section for information on how to circulate the document and options for signifying approval.

9

Project Manager

Circulate approved Project Charter to all interested stakeholders.

After the approval process is complete, circulate copies of the approved Project Charter and Project Management Plan to all interested stakeholders, including the project team members.

Create the Project Management Plan (1.1.3.P5)

It is important to document the Project Management Plan ahead of time and get buy-in from management, team members, clients and other important stakeholders. For instance, it is much easier to resolve a scope change request by following an approved procedure than by having to invent the procedure and resolve the scope change at the same time.

The larger your project, the more formal and disciplined your Project Management Plan need to be. If you have procedures defined from a similar project, or if your organization has a common set of procedures defined already for large projects, use them as your starting point. 

The Project Management Plan contains the Project Charter and the subsidiary plans that are needed to manage the project. Although the documents can certainly be referenced individually, the Project Management Plan can be used to group them all together.

The Project Management Plan can include the following deliverables:

Use a Separate “Discovery Project” to Define the Work for a Large Project (1.2.P10)

For large projects, there is a tendency for the project definition work to become very lengthy and unfocused. Defining the work for very large projects takes enough time that it should be structured as a project itself. This is the purpose of defining a separate Discovery Project.

This should make sense. If the project is ultimately going to take 50,000 effort hours, it may take a number of months to get the project defined and approved. In these cases, a distinct first project is established to define the second larger project itself. The final deliverable for a Discovery Project is a completed Project Charter, Project Management Plan and project schedule for the subsequent large project. All the other project deliverables will be produced as a part of the next follow-up project.

Discovery Projects, like all projects, come in all sizes. You should estimate the effort and duration required for the Discovery Project. Based on the effort required for the Discovery Project, you can categorize the Discovery Project itself as small / medium / large using the same project criteria described earlier. Remember that this is the relative size of the Discovery Project, not the final project. Depending on the size of the Discovery Project, you again have three options on how to define the work. 

For a small Discovery Project, a service request can be created, but it is not required. For this size of effort, just continue to do the definition work, as defined in the 1.1.2 Define the Work / Medium project. It is assumed that if you are defining a Discovery Project the final project will be large enough to require a full Project Charter. 

For a medium-sized Discovery Project, follow the TenStep Project Management Process for a medium project. The Discovery Project should have an Abbreviated Project Charter and project schedule, and be managed just like any other medium-size project, including managing issues, scope, risk, etc. (A Project Management Plan document does not need to be created for the Discovery Project itself.) When the Discovery Project is complete, the Project Charter, Project Management Plan and project schedule for the subsequent project should be created. The approval process for these documents should be a part of the Discovery Project. Assuming that the Project Charter has been approved, the subsequent large project can start at any time. However, steps 1.0 Define the Work and 2.0 Build the Schedule and Budget will already be completed (these were the purpose of the Discovery Project). The project management process for this subsequent project can begin in Step 3.0 Manage the Schedule and Budget.

If the size of your Discovery Project is, in fact, a large project itself, you should follow the steps required for defining large projects. Let’s look at an example. Let’s say you are trying to define a very large project – perhaps even a program (a set of related projects managed as a whole). Let’s further assume the Discovery Project itself takes 5,000 hours.  If the Discovery Project is a large project, the subsequent project actually being defined would have to be very, very large. The Discovery Project would then be managed as a large project. When the Discovery Project is completed, the larger project can start, since the Discovery Project deliverables include the Project Charter, schedule and Project Management Plan.

[ Previous Page - 5.2.01.2TS Scope Def - Process (Medium Projects)]  [ Next Page - 5.2.02TS Scope Def - Techniques]