"PRIDE"-Project Management (PM) - M. Bryce & Associates

PRIDE

-PM

Project Management
PROJECT PLANNING

ESTIMATING SCHEDULING REPORTING CONTROL
SUPPORT FORMS

TRANSLATE THIS PAGE TO... Chinese (simple) Japanese Dutch French German Italian
Free Translation courtesy of ALS Chinese (traditional) Korean Portuguese Russian Spanish

CONTENTS

"You cannot put two quarts of liquid into a one quart bottle. If you try, you will lose a quart."
- Bryce's Law

This section contains the following:

INTRODUCTION

GENERAL DISCUSSION

INTRODUCTION

We as human beings have a natural aversion to planning of any kind. Some of us cannot plan a day of activities, let alone a week, month, year, etc. This is primarily due to an inherent resistance to organizing and structuring our activities. Planning requires discipline, something that is sorely lacking in most information systems organizations. To obtain the results of planning requires an expenditure of time and some serious thinking. There is no "free lunch."

Projects are often preordained to failure before they even start, simply due to the lack of effective planning. This may be caused by our temptation to "leap before we look." Emotional desire must be overcome by logical fact in order for planning to succeed.

In order to perform project planning, we must resolve the following questions:

What is the scope of the project? - The scope must state the project's objectives and the parts of the organization involved, both directly and indirectly.
What are the steps required to meet the project's objectives? The old adage is true, "If you don't know where you are going, any road will take you there." Performing work in a logical sequence gives direction to the project. The inability to do so results in lost time and effort. Therefore, not only do the required steps in a project need to be defined, but the precedent relationships within a project must also be defined. The methodology thereby becomes the "roadmap" for the execution of the project.
What are the deliverables and benchmarks of the project? In order to verify that a particular project task has been completed, it is necessary to substantiate that all aspects of the task have successfully been executed. An impartial and objective mechanism that checks the completeness of tasks is necessary. It is important to demonstrate tangible results from our project efforts in the form of accomplishments and deliverables. Any task that does not result in a reviewable or tangible result is an unnecessary step that should be eliminated.
What resources are required to perform the work? Assigning the correct resources to the appropriate work steps is a critical factor in every project. By properly defining the work steps and the benchmarks, it is possible to clearly identify the skills required to execute the steps. Resources with the appropriate skills and availability can then be assigned to the project tasks.

GENERAL DISCUSSION

WORK BREAKDOWN STRUCTURE (WBS)

All projects have a structure depending on the methodology used. The methodology defines what is going to be produced. It can be as simple as one step or as extensive as several phases involving multiple activities and tasks. The methodology represents the selected approach for implementing a project. It is structured into a hierarchy consisting of one or more phases of work. A phase represents a major "key event" or milestone in the project. Each phase consists of one or more activities representing "sub-events" required to meet the milestone. Each activity consists of one or more operational steps or tasks representing the individual actions to be taken in the project.

Each phase, activity and operation of a methodology should produce a reviewable result (work product) to substantiate completion of assignments. Otherwise, a methodology becomes a meaningless series of tasks.

The level of detail required to perform a project is ultimately left to the discretion of the Project Manager. If a simple project, perhaps the manager will only define a phase with a few activities. However, if a project is large and complex, the manager may wish to define and manage at the operation level.

PRECEDENT RELATIONSHIPS (DEPENDENCIES)

Up to this point we have only defined WHAT work is involved, not its sequencing. A methodology defines not only the various units of work, but also dependencies between the worksteps. Such dependencies are referred to as "precedent relationships."

Project worksteps may be conducted either sequentially, in parallel, or combinations of the two. Precedent relationships define what worksteps precede and succeed a single workstep.

Precedent relationships can be defined between worksteps in the same level of the methodology structure. This means:

PROJECT-TO-PROJECT relationships.

PHASE-TO-PHASE relationships.

ACTIVITY-TO-ACTIVITY relationships.

OPERATION-TO-OPERATION relationships.

This brings up two points:

Progression between project worksteps at the same level cannot proceed until the subordinate levels are fulfilled. This means you cannot move from one project to another until all of the phases from the first project have been performed; nor can you move from one phase to another until all of the activities from the first phase have been performed; nor can you move from one activity to another until all of the operations from the first activity have been performed.
You cannot define lower level worksteps until you have first defined the higher levels. In other words, you must define phases before you define activities, before you define operations.

The one exception to this is a PHASE-TO-PROJECT relationship where a separate project can be activated pending completion of a phase. This can be demonstrated by separate "PRIDE"-ISEM and "PRIDE"-DBEM projects:

NOTE: Although Project-to-Project and Phase-to-Project Relationships are permitted, they are uncommon. Most projects will only show inner dependencies (phase-to-phase, activity-to-activity, operation-to-operation).

Although "branching" (parallelism) can occur at any level in the methodology, the project manager will typically find less need for branching at the lower levels of the methodology structure. This means phases are more apt to branch than operations. Most operational steps within an activity are performed serially (sequentially).

To expedite the development of methodology structures, "PRIDE" includes a "Methodology Definition Worksheet" which is used to define the Work Breakdown Structure and precedent relationships. To illustrate:

LEVEL-1: DECOMPOSING A METHODOLOGY INTO PHASES

LEVEL-2: DECOMPOSING A PHASE INTO ACTIVITIES

LEVEL-3: DECOMPOSING AN ACTIVITY INTO OPERATIONS

To view and/or print a copy of the "Methodology Definition Worksheet" worksheet, see: "PRIDE" Forms

METHODOLOGY CRITERIA

In order to effectively organize a project it is important to recognize the basic elements of a methodology:

Mandatory Requirements

A defined Work Breakdown Structure (WBS) - consisting of a series of work steps in various levels of abstraction (e.g., Phases, Activities, Operations).
Defines the project functions responsible for performing the various work steps.
Defines the project dependencies (the precedent relationships between work steps).

Without these mandatory requirements, a methodology is illegitimate and should be referred to as something else.

Optional Requirements

Have a single phase to initiate a project, and a single phase to conclude it. Multiple starts and multiple ends are not desirable from a management point of view.
The methodology structures should be based on reviewable work products to verify completeness. If the methodology is not defined accordingly, the "Dance of the Fairies" phenomenon occurs - this is where a series of meaningless work steps are defined with no verifiable end result.
The methodology structures should be reusable on multiple projects.
Provide for both sequential and parallel project execution.
The methodology structures should accommodate a product structure, thereby allowing parallel processing.

Although these latter requirements are not mandatory, they are highly desirable features and have been incorporated into the methodologies in "PRIDE".

Project planning is made simpler by the existence of standard methodologies, such as "PRIDE"-EEM, ISEM, and DBEM, which include defined phases, activities, deliverables, precedent relationships and the functions to perform the work.