Something from Nothing

Jeremiah Smedra
Software Technology Support Center

 

Project stakeholders can benefit greatly from implementing a common, defined project management methodology. Far too often, it is the pain of failure and crisis that motivates change. Rather than suffer the ill effects of failure and crisis, we should improve our projects now. This article presents an overview of the Project Management Institute's methodology.

E SHOULD NOT BE surprised when failure is the fruit of poorly-defined, ill-planned, and arbitrarily executed efforts. In the play "King Lear," Shakespeare writes, "Nothing will come of nothing." Projects are not exempt.
     Project management methodology provides the best possible framework for project success. Although all project management environments (software development, construction, defense acquisition, etc.) have unique qualities, they share more commonalties than differences. It does not matter whether you are a practitioner, mid- or senior-level manager. If we are not all dancing the same steps, success is difficult — if not impossible — to achieve. We may get the job done. However, it may not be fun, we may not look good, and we may not be able to call it successful.

Definitions
A project is "a temporary endeavor undertaken to create a unique product or service"[1]. Management generally is concerned with producing key or necessary results. Methodology defines how the project is managed without impacting the effort's uniqueness. If we can define a common project management methodology, communicate it to those we work for and with, and implement it consistently, we will be on the way to reducing risk and actualizing success.
     Since 1969, the Project Management Institute (PMI), a nonprofit organization consisting of practitioners and academics, has led the way in researching, organizing, and recording project management methodology. The culmination of its efforts is a work-in-progress, the Project Management Body of Knowledge (PMBOK). The PMBOK model is a structured identification of the skills, concepts and techniques common to the project management field. It is a description of the knowledge and practices commonly found in projects and not a formula to be uniformly applied to all projects. PMI also maintains a professional certification for project managers: the Project Management Professional (PMP). The PMBOK model is widely recognized as the commercially proven and accepted standard for project management. You can download a free copy at http://www.pmi.org/publictn/pmboktoc.htm. This article will present a basic outline of PMI's model for project management.
     The PMBOK model presents three primary dimensions of project management. These are the lifecycle, the process groups, and the knowledge areas. Each dimension is unique, although related and interdependent.

Life Cycle
The project life cycle is the big picture. The life cycle divides the project into a series of phases which provides better project control. The four common phases in a project life cycle are concept, development, implementation, and termination or closeout.
     Phases are easy to recognize. The delivery or completion of a major deliverable usually characterizes the end of a phase. For instance, a feasibility study or architectural design might conclude the conceptual phase. The developmental phase might conclude with the project plan. The implementation phase would conclude with the completion of the product or service. Termination might conclude with the customer sign-off, completion of a lessons learned database, and collection of any historical documentation. By treating each phase as a project, we separate complex projects into more manageable pieces.

Process Groups
The five process groups are initiation, planning, executing, controlling, and closing. They are "concerned with describing and organizing the work of the project. ... The process groups are linked by the results they produce — the result or output of one becomes an input to another" [1]. Figure 1 represents how the five processes relate.

Figure 1. Links among process groups [1].

     The following is an example of what the processes would look like for an actual project. A customer decides he wants to make a change in the product's requirements and the project's production/development is 50 percent complete. Initiation begins with the customer's request. However, the initiating process directs us to document our customer's request, perform an impact analysis, and meet with the customer to exchange expectations.
     During planning, we revise schedules, budgets, and other related documents (scope, work breakdown structure, and risks) that make the new requirement part of the project. In this example, executing and controlling are not significantly impacted by our requirements change. The product is built based on our new set of requirements, and measures would be used to direct corrective action as needed. Closing ensures that the customer's request to change requirements was documented to conclusion.

Project Processes/Knowledge Areas
At its most detailed level, PMBOK defines nine unique but often overlapping project areas. The four primary knowledge areas are scope, time, cost, and quality. The four facilitating areas are human resources, risk, procurement, and communication. The remaining overarching area is integration. Integration is concerned with properly coordinating the other knowledge areas. Each knowledge area consists of a series of processes.
     Each process includes inputs, tools and techniques, and outputs. (Figure 2.) Inputs are the items needed to complete the process. The tools and techniques define what to do to the inputs. The outputs define the product(s) of the process. The PMBOK guide defines and explains the items listed in the inputs, tools and techniques, and outputs.

Process	Inputs	Tools and Techniques	Outputs
6.1 Activity  Definition	• Work breakdown structure  • Scope statement  • Historical information  • Constraints  • Assumptions	• Decomposition  • Templates	• Activity list  • Supporting detail  • Work breakdown  structure updates
6.2 Activity  Sequenceing	• Activity list  • Product description  • Mandatory dependency  • Discretionary dependencies  • External dependencies  • Constraints  • Assumptions	• Precedence diagramming method  (PMD)  • Arrow diagramming method  (AMD)  • Conditional diagramming methods  • Network templates	• Project network diagram  • Avtivity list updates
6.3 Activity  Duration  Estimating	• Activity list  • Constraints  • Assumption  • Resource requirements  • Resource capabilities  • Historical information	• Expert judgement  • Analogous estimating  • Simulation	• Activity duration estimates  • Basis of estimates  • Activity list updates
6.4 Schedule  Development  Estimating	• Project network diagram  • Activity duration estimates  • Resource requirements  • Resource pool description  • Calendars  • Constraints  • Assumptions  • Leads and lags	• Mathematical analysis  • Duration compression  • Simulation  • Resource leveling heuristics  • Project management software	• Project schedule  • Supporting detail  • Schedule management  plan  • Resource requirement  updates
6.5 Schedule  Control	• Project schedule  • Performance reports  • Change requests  • Schedule management plan	• Schedule change control system  • Performance measurement  • Additional planning  • Project management software	• Schedule updates  • Corrective action  • Lessons learned

Figure 2. Time management [1].

Nothing from Nothing?
Although project management can be easily defined, it often looks like fire fighting. Managers and team members act like smoke jumpers. They parachute in on the hot spots, beat back the fire to a reasonable slow burn, and race off to fight the next flare-up. This method of project management is rarely successful. We expect something from nothing.
     Devoting resources to training, process improvement, and other similar efforts can be difficult to justify. It often feels and looks as if we are neglecting our primary responsibilities. However, these efforts pave the way for more efficient and effective work. Projects will benefit from the organization, attention to detail, and common language of the PMBOK framework. Rather than continuing to expect results without a firm methodology, we should contribute to teaching and implementing a proven framework for project success.

About the Author

Jeremiah Smedra is a consultant with the Software Technology Support Center. He provides support to Department of Defense organizations pursuing process improvement and project management education. He has a bachelor's degree in marine engineering systems from the Merchant Marine Academy in Kings Point, N.Y. He is a registered Engineer-in-Training (EIT) and a PMI-certified Project Management Professional.

Software Technology Support Center
Ogden ALC/TISE
7278 Fourth Street
Hill AFB, Utah 84056
Voice: 801-777-7230 DSN 777-7230
Fax: 801-777-8069 DSN 777-8069
E-mail: smedraj@software.hill.af.mil

References

1. Project Management Institute, A Guide to the Project Management Body of Knowledge, Project Management Institute, Upper Darby, Pa., 1996.
2. Adams, John R., et.al., Principles of Project Management, Project Management Institute, Upper Darby, Pa., 1997.

---

Project Management Services

The Software Technology Support Center offers a number of useful PM services to organizations within the Air Force, other government agencies, and their supporting contractors. Services include: PMBOK area specific workshops Tool training Executive sessions Consultation and mentoring All services are provided on a cost-recovery basis. To get your project management effort off to a good start or give it a shot in the arm, contact the author for further information regarding PMI and the PMBOK model.