With more project managers earning Project Management Professional (PMP) certifications from the Project Management Institute, and more organizations following the concepts in A Guide to the Project Management Body of Knowledge (PMBOK), PMI’s book on project methodologies and practices, it’s no surprise that PMI’s concepts have found their way into IT.
And just as IT pros are adopting some of the PMI’s definitions and concepts of project work, they’re also embracing the organization’s project process groups, concepts designed to instill in project managers a set of techniques and methods that they can apply wherever they are in the project life cycle, and whatever type of project they are tackling. I’ll discuss their application to IT consulting engagements.
Second in a series
The previous article in this series explored the growth of PMI standards among IT projects.
Project process groups
In the PMBOK, PMI defines the basic project process groups as:
- Initiating: The actions required to start a new project or new phase, such as defining the business need, identifying sponsors and stakeholders, assigning project managers and project teams, and analyzing the costs and benefits of a project.
- Planning: Creating a plan to accomplish the project or phase, and to maintain that plan throughout the life of the project as circumstances change.
- Executing: Coordinating teams and resources to carry out the plans and to produce the deliverables. Providing leadership, managing quality, and communicating project status information are all considered execution activities.
- Controlling: Ensuring that project objectives are met by performing such activities as measuring progress against plan, holding status meetings, and correcting divergences from schedule or budget.
- Closing: Bringing projects or project phases to an orderly end and formally turning over project deliverables to the sponsor and stakeholder groups.
Each process group is broken into various activities. For example, the Planning process group includes Scope Planning, Resource Planning, Cost Estimating, and Project Plan Development. (I’ll review these in my next article on the PMI.)
As you can see from these descriptions, the PMI process groups aren’t designed to represent a life cycle that will lead project managers through an engagement in a straight line. In my project management classes, I often find that rookie project managers struggle with this concept—they come to the PMBOK expecting a “canned” life cycle that they can simply apply out of the book; they find instead a set of processes that they must master to be prepared to take on their PM roles.
Why this approach?
Why did the PMI decide to present the Body of Knowledge in this way? As the PMBOK points out, different types of projects have different life cycles, but project processes are universally applicable to all kinds of project work. For example, the project life cycle for a construction project will differ substantially from the life cycle for a pharmaceutical product-development effort. Yet both require the project manager to apply the basic project processes, such as project planning and scope management.
Every organization needs to create its own project methodologies and life cycles that reflect its business needs, culture, and operating circumstances. Each organization must determine the unique blend of rigor, structure, and freedom that will make up its methodology.
Rather than enter this philosophical debate over methodology, the PMI offers these process groups as a series of activities that all PMs must know how to conduct, whatever the life cycle and methodology they work under.
How is this useful?
Understanding how to plan a project or phase properly—so that the activities, tasks, and resources are clearly defined and understood—is a make-or-break ability. Knowing how to take a client’s vague and ambiguous scope statement and expand that into a task-level plan that can guide our daily execution is a critical talent.
Rather than merely presenting a methodology that says “build a project plan at this point in the life cycle,” the PMBOK presents all the project processes required to develop a complete plan, from activity definition to activity sequencing to risk planning, and offers instruction in those skills so that they can be applied throughout the life cycle.
The skills taught in the other PMI process groups are just as critical for IT professionals. For example, the team development and quality control processes that make up the Executing group are very different from the technical delivery skills most IT consultants have mastered, yet they’re vital to our delivery success. Knowing how to control changes to scope, manage costs, and respond to risks are crucial Controlling process skills that mean the difference between satisfied clients and never-ending rework.
Advantages of project process groups
While life cycles vary based on the type of projects we’re delivering, PMI’s process groups and their associated activities are constant and recurring. Planning processes, for example, occur throughout the life cycle, as plans are refined and optimized based on new requirements or circumstances. This realization, that project plans change and evolve throughout the life of a project, is one factor that differentiates modern project philosophies from some of the less adaptive approaches of the past.
For example, the “waterfall” approaches common to earlier IT life cycles assumed that requirements were defined, set in concrete, planned, and delivered in a straight line, progressing inexorably toward an implementation date.
Modern, iterative, agile development life cycles, on the other hand, accept the reality, especially in IT, that new needs, expectations, requirements, capabilities, and business imperatives will be revealed as we work towards our project goals. This in turn requires us to reapply our Planning process skills repeatedly throughout the project delivery cycle.
The same is true of the other PMI project process skills: As new phases are begun, new tasks are executed, older phases are closed out, and deliverables are presented to clients.
Process groups in practice
Let’s look at a real-world example that illustrates the difference between project life cycles and project process groups. In my IT consulting work, I typically apply a “4D” life cycle to my engagements:
Last year, I took on a project to design and deliver a UNIX-based data center for a small telecommunications startup. Clients typically want an estimate of the expected budget and schedule for their projects, and this client was no exception.
To satisfy the client’s need for some preliminary idea of budget and schedule, I created a rough project plan, including the tasks I expected to perform based on my experience and expertise in delivering data centers. During the Discovery phase of the engagement, I performed a number of tasks, including the discovery of:
- The client’s existing data center facilities, including space, power, ventilation, and security provisions.
- The client’s server and router inventory and configuration.
- The operating systems and applications, and their revision and patch levels.
- The existing data types and storage capabilities.
As usually occurs, these tasks revealed information that changed my viewpoint about the complexity, risks, and constraints associated with this project. In this case, I discovered that the client’s network operating system would not support the messaging software they expected to run, and would require an expensive and complex upgrade. I had to reapply my Planning process skills to revise my project plans.
Armed with this new knowledge, I proceeded to create a preliminary design for the client’s new data center. I periodically reviewed my designs with the provider of the messaging software, and their input required me to make changes in my designs to accommodate special features and requirements of their product.
I repeated this process throughout the project: As new design ideas triggered revisions and optimization of the project plan, the results of pilots and prototypes required me to modify my blueprints and estimates. The point is, rather than looking at planning, risk management, and design as simple steps in a life cycle, I used the process skills that PMI teaches, such as risk identification, schedule development, and resource planning, to respond to new circumstances all through the delivery life cycle.
This pattern is common for those of us in IT consulting. We can’t know certain things until we get deeper into the discovery, design, or development of the project at hand, and we constantly need to revise our plans to accommodate that new knowledge.
Clients, likewise, often can’t visualize what a Web page, or report, or a data-entry screen will look like until we show them a prototype, and their reaction to that first glimpse will often drive us back to the drawing board, forcing us to again use our project process skills to enhance our designs and better satisfy our customers’ needs.
Focusing on the project process skills that the PMBOK contains prepares us with a complete set of tools for dealing with situations that arise, no matter where in the life cycle we are. IT consultants with a firm grasp of the processes presented in the PMBOK can confidently pull out the appropriate tool at the right moment in the engagement.
How to get the PMBOK
If you’re interested in buying a copy of the PMBOK, visit the PMI Web site. For the 2000 edition—which is the most recent—prices range from $35.95 for the paperback to $49.95 for the CD-ROM or the hardcover editions.
Rick Freedman is the author of three books on IT consulting, including "The IT Consultant." Rick is an independent consultant and trainer, working, through his company Consulting Strategies Inc., to help agile teams and organizations understand agile practices and migrate successfully.