The Nature of Project Management

Why do many talented developers and IT professionals consider project management to be an obstacle, rather than an enabler? Why do clients often resist project oversight or try to minimize it? Does project management really allow projects to reach completion more quickly, or are speed and project discipline mutually exclusive?

We’ve explored the balance of speed and delivery and the nature of innovative projects in recent articles. Let’s tie these themes together and review techniques that help keep project management relevant to even the most unique and innovative programs.

Project bureaucrats

When I teach project management, I often draw a distinction between project managers and project bureaucrats. We’ve all had encounters with project managers who turned into bureaucrats. Project bureaucrats are more interested in ensuring that every step of the methodology is applied and every line of every form is filled in than in what’s actually happening on the ground. On the other hand, it’s common to meet project managers who apply minimal project methodology, yet, through their expert use of relationships and personal interactions, always seem to know exactly where the project stands.

In my experience, it’s the project bureaucrats who often leave a bitter taste with both the delivery team and the client. These project managers turned bureaucrats have forgotten one of the key rules of project management: don’t mistake the map for the journey. All the plans, charts, and milestones mean nothing if they aren’t consistent with the reality on the ground. And there’s the rub; especially in innovative projects, the plans and estimates are often based on a fallacy — there’s the idea that we can predict the progress of something that’s never been done before.

Project spec compliance = success? Not always

In his outstanding book Agile Project Management, Jim Highsmith offers two examples that emphasize the point. The movie Titanic, from a project management perspective, was a huge failure — over budget, over schedule, and plagued by unforeseen risks that threatened to derail the project at every turn. Motorola’s Iridium project, which spent billions of dollars launching satellites into orbit in order to make telephone service available worldwide, was a great project management success. Yet the market is the ultimate judge, and the project management compliance of Motorola’s venture didn’t save the project from failure, nor did the project management disaster (no pun intended) of Titanic’s production taint the film’s appeal to the public.

The lesson that project managers should learn from these examples is that compliance with project specifications does not constitute project success; in the ultimate analysis, only business results matter. Stated another way, the largest risk in any project is not that it will deviate from plan; it’s the risk that the final outcome won’t fulfill the real need. Predictive methodologies, such as the techniques championed by the Project Management Institute in its PM Body of Knowledge, can add tremendous value, especially for projects for which we have a historical basis to look to for precedent. For truly innovative projects, in which any prediction is little more than guesswork and for which we’ll be inventing never-before-seen products, we need to look for a new approach. Hence, the growing popularity of agile approaches.

Agile myths and truths

The central insight of agile methods is not that project overhead is a pain in the neck or that programmers like to be free; instead, it is the observable truth that, especially in innovative programs, customers can’t describe what they want until they see it, and prediction is inappropriate when there’s no way to visualize what the final result will be, let alone exactly how long it will take to build.

Unlike predictive methods, in which the planning, estimating, and risk assessment activities are all front-loaded and often are seen as a separate “planning” phase, agile approaches assume that the requirements will grow incrementally and iteratively as the project proceeds. This emphasis on “just enough” planning and requirements discovery is an acknowledgement of the fact that the key up-front activity in an agile approach is the creation of the first iteration of the product, so that the sponsor can see it and touch it, and discrepancies between the sponsor’s vision and the product created by the team can be modified to fulfill the current business need.

Agile project management is often misunderstood, as illustrated by the proliferation of articles about “agile myths.” Agile methods are not about “buying pizza and getting out of the way,” as these methods are often caricatured. Agile methods, from SCRUM to Highsmith’s APM Framework, are disciplined and structured approaches to product development, just as predictive methods are; these methods just address different types of problems.

Predictive and agile approaches have robust requirements discovery techniques, but agile methods acknowledge that requirements will evolve throughout the life of the project rather than up-front. Both approaches have stakeholder participation practices, but agile methods insist that stakeholders and sponsors are involved throughout the project in a collaborative, interactive manner. Predictive and agile both have mechanisms for integrating changing requirements into the plan, but the approaches use different techniques. Predictive techniques often apply restrictive change management procedures. Agile methods are specifically designed to encourage and implement beneficial change by providing an iterative, incremental approach to development focused on implementing, rather than controlling, positive change.

Innovative projects call for innovative methods, but that doesn’t imply, as many agile skeptics insist, that the benefits gained by applying structured project management techniques must be abandoned. Agile approaches are appropriate for creative, inventive projects because the methods integrate exploratory, collaborative techniques into the project process and acknowledge the mutating nature of exploratory IT projects into the PM methods we apply. Even PMI, in its newly published Body of Knowledge, recognizes the value of the iterative, incremental approaches advocated by agile proponents.

More to come

In subsequent columns, we’ll dig a bit deeper into the specifics of some of these techniques and explore ways that agile approaches can be combined with familiar, predictive techniques to apply exactly the right level of rigor to the project, no matter where it falls on the innovation spectrum.

Get weekly PM tips in your inbox
TechRepublic’s IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!

Rick Freedman is the author of three books on IT consulting, including “The IT Consultant”. Rick is a Director in the Global Services Division of NEC America, and a trainer and course developer in the Agile Project Management practice of ESI, the international PM training company.

Project Management Processes

Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements. Project management is accomplished through processes, using project management knowledge, skills, tools, and techniques that receive inputs and generate outputs.

 

In order for a project to be successful, the project team must:

 

·        Select appropriate processes within the Project Management Process Groups (also known as Process Groups) that are required to meet the project objectives

·        Use a defined approach to adapt the product specifications and plans to meet project and product requirements

·        Comply with requirements to meet stakeholder needs, wants and expectations

·        Balance the competing demands of scope, time, cost, quality, resources, and risk to produce a quality product.

 

The PMBOK documents information needed to initiate, plan, execute, monitor and control, and close a single project, and identifies those project management processes that have been recognized as good practice on most projects most of the time. These processes apply globally and across industry groups. Good practice means there is general agreement that the application of those project management processes has been shown to enhance the chances of success over a wide range of projects.

 

A process is a set of interrelated actions and activities that are performed to achieve a pre-specified set of products, results, or services. The project processes are performed by the project team, and generally fall into one of two major categories:

 

·        The project management processes common to most projects most of the time are associated with each other by their performance for an integrated purpose. The purpose is to initiate, plan, execute, monitor and control, and close a project. These processes interact with each other in complex ways that cannot be completely explained in a document or with graphics The processes may also interact in relation to project scope, cost, schedule, etc., which are called Knowledge Areas

·        Product-oriented processes specify and create the project’s product. Product oriented processes are typically defined by the project life cycle and vary by application area. Project management processes and product-oriented processes overlap and interact throughout the project. For example, the scope of the project cannot be defined in the absence of some basic understanding of how to create the specified product.

 

Project management is an integrative undertaking. Project management integration requires each project and product process to be appropriately aligned and connected with the other processes to facilitate their coordination. These process interactions often require tradeoffs among project requirements and objectives. A large and complex project may have some processes that will have to be iterated several times to define and meet stakeholder requirements and reach agreement on the processes outcome.

 

Failure to take action during one process will usually affect that process and other related processes. For example, a scope change will almost always affect project cost, but the scope change may or may not affect team morale or product quality. The specific performance tradeoffs will vary from project to project and organization to organization. Successful project management includes actively managing these interactions to successfully meet sponsor, customer and other stakeholder requirements.

 

The PMBOK describes the nature of project management processes in terms of the integration between the processes, the interactions within them, and the purposes they serve. These processes are aggregated into five groups, defined as the Project Management Process Groups:

 

·         Initiating Process Group

·         Planning Process Group

·         Executing Process Group

·         Monitoring and Controlling Process Group

·         Closing Process Group.