Project Management

The purpose of defining scope is to clearly describe and gain agreement on the logical boundaries of your project. Scope statements are used to define what is within the boundaries of the project and what is outside those boundaries. The more aspects of scope you can identify, the better off your project will be. The following types of information can be helpful in defining scope.

• The deliverables that are in scope and out of scope. You should definitely include deliverables in your scope statements. However, only describe your final deliverables and the project deliverable that are client-focused. For instance, the Business Requirements Report and Current State Assessment could be listed as project deliverables since they are both client-approved deliverables. You would not need to mention internal project documents such as the project workplan, Technical Design or Test Cases.
• The major lifecycle processes that are in scope and out of scope. For instance, your project may include the Analysis Phase only and not the Design, Construct or Test Phases.
• The types of data that are in scope and out of scope. Data types refer to financial data, sales data, employee data, etc. It is possible that your project works with some types of data and does not work with others.
• The data sources (or databases) that are in scope and out of scope. This is similar to the data types, except now you are referring to aggregated data, such as Customer Database, General Ledger, Billing / Invoicing System, etc. (These data sources may have more than one data type.)
• The organizations that are in scope and out of scope. In some cases, the organizations involved in the project help to define the boundaries. For instance, your project may focus on Human Resources and Accounting, but the Manufacturing Division might be out of scope.
• The major functionality that is in scope and out of scope. For instance, decision support and management reporting might be in scope, while overnight batch processing might be out of scope.

Use High-Level Objectives as Your Starting Point

When the project was proposed for funding, there should have been an initial set of high-level objectives and deliverables defined. Any information that was created earlier should be used as the starting point for defining the more detailed scope statements for the Project Charter. If you find that you do not have enough information to create a clear and comprehensive scope statement, you must work with the sponsor to gather additional information. That is one of the main purposes of the definition and planning process.

If you have project objectives, look at them to help shape the scope statements. By definition, there needs to be one or more deliverables created to fulfill each objective, and defining the project deliverables is one of the primary aspects of project scope. After you determine the major deliverables the project will produce, start asking other questions to determine other aspects of scope. The deliverables describe 'what' the project will deliver. You can also identify 'what' organizations are impacted, 'what' types of data are needed, 'what' major features and functions are needed, etc.

As a point of clarity and contrast, you can also identify out-of-scope conditions by describing what deliverables will not be created, what organizations will not be impacted, what features and functions are not included, etc. Of course, there are an infinite number of out-of-scope statements. For the purposes of scope definition, you want to include only those statements that help define the project boundary and touch upon related areas that the reader may have questions about. For instance, if you were installing financial software, you might state that a new Accounts Payable package is in scope, but the related Purchasing System is out of scope. This would make sense because the Purchasing and Accounts Payable processes are related and there may be questions as to whether the Purchasing System was in scope. However, you would not have to list every other system as out of scope – just the ones that the reader might have questions about.

It is a good practice to document those organizations that are in scope and those related organizations that are out of scope. The readers can then determine more easily if they are impacted or expected to assist in the project. Also, it may make sense to identify the organizations that are in scope so that you can have people from those organizations represented on the project team - perhaps on a steering committee.

Aligning Objectives and Scope

When you have completed creating your objectives and scope statements, go back and make sure that they are all in alignment. You should not have any objectives that make references to deliverables that are not defined in your scope statements. Likewise, you don't want to include deliverables in your project scope that do not help to achieve the project objectives. If the two areas are not in full agreement, either the scope or the objectives (or both) must be modified to bring everything into alignment.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let's have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

Consideration, inter-relationship and action of outside changes such as legal, social, economic, political or technological which may directly or indirectly influence specific project actions.

CAVEMEN INTRO NORM: _ _ _ _ _ | _ _ _ _ _ _ _ _ _ _ _

Last Week's Anagram.

Written Approval

MEND SENT ORE: ENDORSEMENT

Wideman Glossary Term of the Week - Dependency

• A relation between activities, such that one requires input from the other.
• See Logical Relationship.
• The next task or group of tasks cannot begin until preceding work has been completed, thus the word "dependent" or "dependency".
• A relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect the other modeling element (the dependent element).

Labels: Defining scope

For large projects, there is a tendency for the project definition process 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. For the most part, all the other deliverables will be produced as a part of the next follow-up project.

The Discovery Project should be planned and managed as a project. This includes defining the work, building a schedule and budget and subsequently managing the Discovery Project. You want to make sure you are clear on what is expected at the conclusion of a Discovery 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. 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 to define the work. Even thought he Discovery Project is small, you can assume that the final project deliverable will be a full Project Charter and a project schedule for the subsequent project.

For a medium-sized Discovery Project, you should follow the TenStep Project Management Processes for defining and managing 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. 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 is approved, the subsequent larger project can start at any time. However, the TenStep steps 1.0 Define the Work and 2.0 Build the Schedule and Budget will already be completed. (These planning processes 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. You would want a full Project Charter to define the Discovery Project, and you would want a full project schedule, budget and Project Management Plan. If the Discovery Project is a large project, the subsequent project will generally be huge - perhaps a program of related projects. Similar to a medium project, the Discovery Project would create the Project Charter, schedule, budget and Project Management Plan for the subsequent larger project (or program). Assuming that the Project Charter is approved, the subsequent larger project can start after the Discovery Project is completed.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Weekly Anagram

Let's have some fun! See if you can unravel this anagram. (Anagrams are a word or phrase formed by reordering the letters of another word or phrase, such as satin to stain.)

The class of tasks ancillary to analysis, design, and programming that are required to accomplish a software development effort; includes documentation (technical publications), quality assurance, test and integration, and the data center operations.

CREPE VISORS PUTS: _ _ _ _ _ _ _ | _ _ _ _ _ _ _ _

Last Week's Anagram.

An overview or introduction to a topic.

RATIO TOE INN: ORIENTATION

Wideman Glossary Term of the Week - Project Appraisal

• The discipline of calculating the viability of a project. Project viability is normally determined in largely economic or financial terms. However, it is normally extended to include issues such as environment appraisal and certainty of performance.

• The discipline of calculating the viability of a project.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Labels: Discovery Project