- “If you don’t know where you are going, any road will take you there.”
When we introduced “PRIDE” as the first commercial methodology for system design in 1971 we never realized the impact it would ultimately have on the industry. It spawned several competitors, both commercially and academically, many of which were various interpretations of the classic “waterfall” approach as implemented by colleges and CPA firms. Today, many companies avoid the use of methodologies as they are considered bureaucratic paper mills. In some instances, this is true, but the fact remains, you cannot build anything of substance, be it a system or otherwise, without a methodology. The question then becomes, how to construct a methodology suitable for your company or a given project. To this end, I offer this tutorial on designing methodologies.
INTRODUCTION
If we lived in a perfect world, there would not be a need for managers. Everyone would know precisely what their assignments were and would successfully accomplish them on time and within budget. However, the reality is we live in an imperfect world. We as human beings make mistakes; we work on multiple assignments concurrently, and require guidance. It must be recognized from the outset that project management does not come free, nor does it come naturally to people.
Traditionally, the typical approach to project management has most often been to find a project manager, provide resources, and then give them an assignment with no direction as to how the project will be conducted or controlled. Under this approach, the success or failure of the project is dependent on the abilities and experience of the project manager and how well the manager can organize and train the project team, plan the project, estimate, etc. Consequently, there is significant trial and error in the process. This approach usually results in a unique method for the particular project because it reflects the thinking of the project manager. Different managers use different techniques and ideas. In other words, it is quite common for systems projects to lack uniformity and consistency, thereby workers have to learn the methodology with each new project assignment.
Another common approach used was the “brute-force approach.” Simply stated, “I don’t care how you get the job done; just have it completed by (date).” This approach shows a lack of sensitivity to the complexity of project management.
There is more to project management than maintaining costs and time schedules. It is the process of applying resources to a defined goal and attaining this goal within time and cost objectives. Fundamentally, it is a people oriented function as opposed to an administrative or clerical function. Project management, therefore, is not a tool or technique, but rather a philosophy of management.
Project management is to a methodology, what production control is to an assembly line. Without the assembly line, production control is a useless exercise. Conversely, without a methodology, project management is useless.
The ultimate test of a methodology is if it can operate independent of project management. The two are not synonymous. Although they work in concert, there are distinct differences. Whereas a methodology dictates what work is required, project management controls the application of work. Just as an assembly line can produce a product without production control, a methodology can produce a product without project management. Therefore, a methodology is independent of project management, but project management is totally dependent upon a methodology.
A project is an application of effort towards prescribed objectives through the execution of a defined sequence of events. All projects have a life cycle; a beginning for planning, a middle for execution, and an end for review. Each project has a unique scope, set of objectives and defined sequence of events. The methodology thereby is the “road map” for a project. It provides organization and direction.
For any methodology, there should be a conceptual foundation explaining the rationale for its structure. In the case of “PRIDE,” we introduced the concept that “a system is a product that can be engineered and manufactured like any other product.” This was a revolutionary idea at the time, and still is to many system developers today. Nevertheless, this concept allowed us to use a hierarchical product structure to decompose a system top-down, and test/install bottom-up. This permits us to design and build the various parts of a system in parallel and concurrently, just as engineering and architectural projects are conducted.
“PRIDE” was a departure from the conventional wisdom that systems were developed using a linear approach, such as that found in the “waterfall” approach.
WORK BREAKDOWN STRUCTURE (WBS)
In order to perform project planning, we must resolve the following questions:
1. 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.
2. What are the steps required to meet the project’s objectives? 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 between work steps must also be defined.
3. What are the deliverables and benchmarks of the project? In order to verify a particular project task has been completed, it is necessary to substantiate that all aspects of the task has successfully been executed. An impartial and objective mechanism checking 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.
4. 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.
A WORK BREAKDOWN STRUCTURE IS A HIERARCHY
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. In systems development, such deliverables include such things as reports (e.g., Feasibility studies, design documents, program source code (and executables), data base structures, test data, test results, project audit, etc.). If the deliverable hasn’t been produced, we can conclude the work step wasn’t performed. If the deliverable was produced, there should be criteria to evaluate it, thereby providing a mechanism to review and correct if necessary.
Bottom-line, for each work step, we should define:
* What is its purpose?
* What will it produce (deliverable)?
* What is the criteria for substantiating completion?
* Who will perform the work (e.g., project functions assigned to the work step, such as analysts, programmers, managers, carpenters, architects, etc.).
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 work steps. Such dependencies are referred to as “precedent relationships.”
Project worksteps may be conducted either sequentially or in parallel (alluding to “branching”). Precedent relationships define what worksteps precede and succeed a single work step.
Precedent relationships can be defined between work steps 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 work steps 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 work steps 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 (Systems Engineering) and “PRIDE”-DBEM (Data Base Engineering) 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, we have provided 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
METHODOLOGY CRITERIA
In order to effectively organize a project it is important to recognize the basic elements of a methodology:
Mandatory Requirements
1. A defined Work Breakdown Structure (WBS) – consisting of a series of work steps in various levels of abstraction (e.g., Phases, Activities, Operations).
2. Defines the project functions responsible for performing the various work steps.
3. 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
1. 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.
2. 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.
3. The methodology structures should be reusable on multiple projects.
4. Provide for both sequential and parallel project execution.
5. The methodology structures should accommodate a product structure, thereby allowing parallel processing.
6. 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,” which include defined phases, activities, deliverables, precedent relationships and the functions to perform the work. This saves time in project planning and brings consistency to projects of like kind.
Then again, system designers and programmers tend to resist the discipline of a methodology; as such, the old adage is true, “If you don’t know where you are going, any road will take you there.” However, it is inconceivable to build anything of substance without a methodology; it is how bridges and skyscrapers are built, automobiles, aircraft, consumer electronics, highways, even medical care and food service. Come to think of it, just about everything requires a methodology. So what makes system designers and programmers special?
For more information on the “PRIDE” Methodologies for IRM, see:
http://www.amazon.com/PRIDE-Methodologies-IRM-Tim-Bryce/dp/097861822X
Keep the Faith!
Note: All trademarks both marked and unmarked belong to their respective companies.
Author: Tim Bryce, Managing Director of M&JB Investment Company
Tim Bryce is a writer and the Managing Director of M&JB Investment Company(M&JB) of Palm Harbor, Florida and has over 30 years of experience in the management consulting field. He can be reached at[email protected]
For Tim’s columns, see: timbryce.com
Copyright © 2015 by Tim Bryce. All rights reserved.