• Home
• ABOUT TENSTEP
• OUR PRODUCTS
• Consulting
• TRAINING
• Community
• PM Tool
• TenStep Store

The following techniques will help define scope on your project through the building of a work breakdown structure.

This supplemental content comes from the TenStep Project Management Process.

For more information on building a Work Breakdown Structure, see 5.3.02.1TS Work Breakdown Structure.

Work on the Project Definition and Project Schedule Simultaneously (1.2.P1)

There is not a sequential order implied between defining the work (step 1.0) and building the schedule and budget (step 2.0). That is, you do not have to completely define the work first and then build the schedule and budget second. Some of the sections of the Project Charter, such as the estimates for effort and duration, cannot be completed without starting to lay out the overall project schedule. At the same time, you cannot complete the schedule without gaining agreement on the Project Charter. For instance, you cannot build the schedule and budget without gaining a high-level agreement on deliverables and scope. Defining the project also involves describing an overall project approach, which is helpful to know before the schedule is completed.

To a certain extent, defining the work and building the schedule and budget need to be done simultaneously. The two main deliverables, the Project Charter and project schedule, should also be developed in parallel. You will find that as you gather information about scope and deliverables, you can start laying out a high-level schedule. As you gather more information about the work, you can fill in more details on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information to complete a high-level schedule. You can then use the high-level schedule to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Charter.

Break Large Projects into Smaller Pieces (1.2.P2)

The days of the mega-project are over. Very large projects are simply too difficult to manage and execute successfully. There are a number of problems with very large projects:

• The work is less clear the farther out in the future it is. Large projects are usually always long projects as well and that makes them very difficult to plan successfully.

• Since the future work is less clear, it is harder to make accurate estimates for effort, duration and cost.

• Business and technical conditions change over time, making planning assumptions in the future very uncertain. The business and technical certainties of today can change dramatically over time.

• You risk losing organization support if there is a long delay before delivering tangible results. It is very difficult to maintain organizational enthusiasm and support over long periods of time.

• It is very difficult to predict resource requirements and availability far into the future. Again, this gets at the difficulty of estimating accurately as you get further out in the future.

Very large efforts are much too difficult and complex to manage as a single project. The better technique is to break the work down into more manageable chunks, each of which is considered its own project, with its own Project Charter and schedule.

For instance, a long IT development effort can be broken into separate sequential projects based on the life cycle. A project is set up for the analysis work. Toward the end of that project a second project is established, based on what you know then, to do the design work. Then a construct / test project is initiated, and finally a project for implementation. Other large initiatives might be broken up into smaller projects that might run in parallel. Some large initiatives can have a combination of smaller projects - some of which must be done sequentially, but others that can be done in parallel. Each team will work to complete its smaller project, but all the work would be coordinated so that the entire effort is successful.

Set up a Program to Coordinate a Set of Related Projects (1.2.P3)

If you break a large effort into a number of related projects, there is still a need to maintain overall management and coordination. This is the purpose of setting up a 'program'. A program is the umbrella structure established to manage a series of related projects. Each project has a full-time or part-time project manager. The program is lead by a program manager. The program does not produce any project deliverables itself; the project teams produce them all. The purpose of the program is to:

• Provide overall direction, guidance and leadership for the projects

• Make sure the related projects are communicating effectively

• Provide a central point of contact and focus for the client and the project teams

• Determine how individual projects should be defined to ensure all the work gets completed successfully

Work With Your Client When They Cannot Completely Define the Project (1.2.P4)

Sometimes the project manager places too high an expectation on the amount of foresight and vision that clients have. In many cases, the project manager will go to the client looking for answers to help define the project and the client will not have all of the information needed. This happens all the time and it does not mean that the client does not know what they are doing. In many cases, especially for large projects, the client has a vision of what the end results will be, but cannot yet articulate this vision into concrete deliverables. They may also not know all of the answers on scope, risks, project organization, etc. 

Based on having less-than-complete information, the project manager may feel the need to guess on the details. This is not a good solution Instead, if you are faced with this situation, there are three ways that you can proceed.

• State up-front everything that you know, as well as everything that you do not know. If you are asked to come up with estimated effort, cost and duration, you will need to provide a high and low range based on the uncertainty remaining.

• Break the work down into a series of smaller projects (as described previously). Even if the final results cannot be clearly defined, there should be some amount of work that is well-defined, which will, in turn lead to the information needed for the final solution. You should only define a project to cover as far as you can comfortably “see” at the time. Then, define and plan subsequent projects to cover the remaining work as more details are known.  For instance, you could create a project that gathered business requirements, and then use the results of that project to define a second project to build the final deliverables. 

• If you are not allowed to break the project into smaller pieces, you should at least know enough that you can plan the work for the first 90 days. In this third approach, you plan the short-term work in more detail, and leave the long-term effort more undefined. Each month you should redefine and plan the remaining work. As you uncover more and more information, you can plan the remaining work at a more-detailed level. As you uncover more details, you can refine your estimates and work with the sponsor to make sure it is still okay to continue.

The Relationship Between Defining and Planning the Work (2.0.P2)

You will note that defining the work is step 1 of the TenStep process and that building the shcedule and budget is step 2. However, this numbering does not imply that these are necessarily sequential. You will usually find that you cannot complete the Project Charter without starting to lay out the overall project schedule. In many cases, these two deliverables need to be worked on in parallel. As you gather information around scope and deliverables, you will need to start laying out an overall timeline so that you can get your hands around estimated effort and duration. As you get more “definition” information, you will fill in more detail on the schedule. When the deliverables, scope, assumptions and approach are complete, you should have enough information in the schedule to estimate the necessary budget, effort and duration - which in turn are used to complete the Project Charter.

Break Large Projects into Phases and Stages (2.1.5 P7)

There are differing terms used to describe the ways that large projects can be divided and subdivided. A couple of the common terms are phases and stages. There may not be universally recognized definitions for these terms, but in general they mean the following.

• Stage: This is the easier term. This is usually always used to signify an internal breakdown of work on one project. For instance, you might refer to the gathering of business requirements, and all related work, as the Analysis Stage. Similarly, if your project requires the building of a prototype, you might call this the Prototype Stage.

• Phase: Phases can have two meanings. First, in many cases, the word 'phase' means exactly what was just described as a ‘stage’. For instance, a project may have a Requirements Phase or a Prototype Phase. In that context, phase refers to a high-level breakdown of internal work. If the term 'stage' is also used, it refers to a further subdivision of a phase. For instance, in the Analysis Phase, there may be a Business Requirements Stage and a Strategy Definition Stage.

The second use of the term “phase” refers to a series of independent but related projects. For instance, the original execution of a project to deliver basic functionality might be referred to as Phase I. A subsequent project to add more functionality might be called Phase II. A rollout of the package might be Phase III. In all these cases, the term 'phase' is used to imply a separate project, but one that is related to similar projects in a series that come before it and after it.

Use Previous Similar Schedules and Pre-Built Schedule Templates (2.2.P1)

A Work Breakdown Structure (WBS) technique can always be used to create a schedule from scratch. However, the WBS is not always the most efficient way to build the schedule. The best way to build a schedule is to reuse one that was created previously. For instance, if a similar project was completed in the past, start by using that schedule as your base and modifying it accordingly. This will save all of the effort associated with 'discovering' how the work should be laid out. This is especially valuable if the previous project manager kept the schedule up-to-date. Then you will have the actual schedule that was used to complete the similar project.

If you do not have the schedule from a similar project, see if your company has pre-built schedule templates for projects with certain characteristics. For instance, your company may have a life cycle methodology with pre-built templates for implementing a packaged solution, or an Internet solution, or an iterative development solution. In this case, you can see if the approach you are using for your project matches one of the templates. If so, it can be used as a starting point.

Be careful however. Pre-built templates from a methodology tend to be large and complicated because the vendor wants them to be applicable for all projects with certain characteristics. After determining that the schedule template is a match, the project manager must evaluate the activities in the template and determine the ones that are applicable to this project. Those activities that are applicable should remain in the schedule. Those that are not needed should be removed.