What Is Scope Creep in Project Management?

a male developer trying to debug his project

The issue of scope creep has bedeviled project managers since the ancient Egyptians wondered if three pyramids might be more impressive than just one. It isn’t a difficult concept to understand. However, heading off scope creep often requires a great deal of effort and expertise.

Key Takeaways: Scope Creep

  • Project scope is the project’s goal and the process for achieving it.
  • Scope creep in project management is when changes are made to the scope that don’t aid in its successful completion.
  • Creep can be caused by stakeholders making requests or team members making unauthorized changes.
  • Scope creep can cause a project to fail, so is an important concern of project managers.
  • Preventing scope creep requires a clear scope, a method of handling change requests, and fostering communication between team members and other stakeholders.
  • There are a wide array of tools to assist in managing scope creep.

What Is Scope Creep?

While scope creep is one of the most common reasons projects fail, there is no single agreed-upon definition of scope creep. Broadly speaking, it refers to the addition of tasks outside the original, defined project scope. Another way to think of scope creep is as uncontrolled or unexpected changes that may be opposed to the requirements of a project.

Some people would add that scope creep only occurs when unauthorized changes are made. By that definition, any scope change approved by someone in authority doesn’t qualify as scope creep. Others have determined that changes of any kind, approved or otherwise, can impact a project’s success and therefore be considered scope creep.

An example of project scope creep might be adding a feature that recommends mechanics halfway through the development of a car buying app. Requirement creep like that might introduce useful new features, but it’s not part of the goal of the project. Additionally, it adds to project cost and time.

To understand scope creep and its effects, we first have to look at the project scope itself.

Project Scope and Product Scope

The scope of a project is both the product it will produce and the process needed to produce it. The initial scope is referred to as the baseline scope, including the scope statement and work breakdown schedule. 

The product can be anything from software to a new building. Whatever it is, the product has its own defined scope which needs to be part of the project plan. 

Scope creep occurs in both product scope and overall project scope. Either can be a factor in project failure. In general, the more detailed and precise the project scope is, the less likely scope creep is to occur. As a result, the chances of successfully completing a project increases.

Agile Projects

Agile projects is a project management methodology that has been criticized as a sort of organized form of scope creep. When a project manager uses Agile methods, the product scope is not defined at the start of the project. Instead, project teams follow a process of defining and redefining the product throughout the project. That can seem like a recipe for continually redefining scope.

However, this is where separating product and project scope can be helpful. Agile methods generally have fixed resources and schedules, which are initially defined as part of the project scope. Changing either of those in the course of a project could qualify as scope creep.

How To Identify Scope Creep and Its Causes

Some degree of scope creep is often inevitable. Particularly at the rate at which daily life changes in the modern age, project requirements are likely to change in the midst of work. However, it’s the job of a project manager to keep it to a minimum. 

Despite that, there is no simple method for identifying scope creep.

Successful project management means accomplishing goals outlined in the project scope within budget and according to schedule. When scope creep occurs, it draws further on resources and takes up more time, but doesn’t contribute toward reaching goals. 

Generally speaking, methods of identifying creep involve assessing project progress while monitoring resources. Expending resources without progressing is usually a sign of scope creep. Project management tools along with project management software can be a great aid in this process.

A more effective method of managing creep is often to identify causes of scope creep and then, putting measures in place to control them.

What Causes Scope Creep?

The causes of scope creep on a project can vary depending on the nature of the project itself. Creep in software development may have a different origin than in construction. However, there are some common causes, including:

Five common causes of scope creep
  1. Unclear scope definition.
  2. Poor communication with project stakeholders.
  3. No effective scope management.
  4. Improper collection of project requirements.
  5. Length of project.

Unclear Scope Definition

The first, and perhaps most common, cause of scope creep is an insufficiently defined scope. If you don’t know what the goals of the project are, you can’t have a clear idea of how to reach them. Those issues have to be worked out in the midst of the project, leading inevitably to wasted time and resources.

Agile methods are ideal for use in contexts when outside factors could affect the scope during the project. However, Agile projects still require some aspects of the scope to be clearly outlined.

Poor Communication With Project Stakeholders

The project sponsor is the person who will overall be held responsible for the outcome. They also often don’t have the knowledge or time to precisely define every aspect of a project. 

Stakeholders are those individuals who either are involved in the project or will be affected by it. They may have agendas or desire features that would draw resources away from primary goals.

Part of a project manager’s job is managing the relationship between interested parties. If that’s not done properly, it is possible to waste time and resources due to disagreements. Too many stakeholders also cause problems, as the more difficult communication becomes, the more likely creep is.

No Effective Scope Management

It may be inevitable that the scope of a project will change. Agile methods were developed specifically because requirements or resources change so frequently during a project. If project managers recognize this and put an organized method in place of changing scope, uncontrolled change can be much reduced.

Improper Collection of Requirements

Another aspect of working with stakeholders is a clear process for collecting requirements. Stakeholders may see opportunities to add new features, find aspects they personally like and wish to be included, or otherwise add ‘requirements’ that don’t actually work toward the overall goal. 

A clear process for collecting and assessing requirements can help prevent that wasted effort.

Length of Project

A longer project doesn’t necessarily lead to more scope creep. However, it does mean there is more opportunity for it. 

What Mistakes Were Made To Allow It To Persist and Build?

Scope creep tends to stick around for two reasons:

  • Unclear scope definition: If it is never clarified, an unclear scope can continue to drive creep.
  • No process for incorporating changes: Some changes may be unavoidable. A defined process for making those changes can assess which are necessary and how to alter the project with minimal impact to project timeline and budget.

Fixing scope creep in any particular project usually means addressing these two issues.

How To Fix Scope Creep

The estimated percentage of successful projects varies but is usually around 30%. That means that most projects either fail or are not completed satisfactorily, in many cases likely due to the effects of scope creep. There may be no simple way to mitigate scope creep in project management, but it’s vital to successful completion. Methods for addressing creep include:

3 ways to fix scope creep
  • Create a clear PSS.
  • Put a change management process in place.
  • Improve stakeholder communications.

Project Scope Statement

The project scope statement (PSS) provides a basis from which to make all project decisions, direct project effort, and communicate the project’s scope. It can also be a way of defining the boundaries of the project. The statement is important when creating a work breakdown structure, a clear project schedule, and a breakdown of project management phases, among many other things.

As a tool for communication, a PSS can foster a better client relationship. It can also clarify when changing requirements or adding additional features would cause scope change. Creating a statement or improving an existing one can help limit change.

Change Management Process

Some scope changes may be inevitable. In some ways, it is in the management of scope creep, project management finds its underlying purpose. Managing to control scope creep while also adhering to the project schedule and budget is difficult, and requires a clear scope management plan.

One of the most important aspects is the process for handling change requests. Requests for changes from stakeholders are a key reason for scope change. A clear process makes it easier to decide what changes are necessary.

Stakeholder Communications

A stakeholder is not just a client or project sponsor. They can also be team members, end-users, and other interested parties. Communicating the project’s status clearly is important, as are reasons for project delays. 

A project’s success is greater when new requests for change taper off as the project nears its end. Doing so helps prevent feature creep and prevents the change control process from controlling the entire project. The best way to accomplish that is by collecting all the needed requirements from the start.

A quality project management software may help in improving communications between various team members.

How To Manage Scope Creep

As we’ve mentioned, it may be impossible to entirely prevent scope creep. Instead of trying to figure out how to avoid scope creep, it’s better to have a process to manage scope creep. 

The strategies for fixing scope creep we’ve already mentioned can also help prevent and manage it, including a formal change management process, defined PSS, and process for stakeholder communications. 

Those are broad approaches to handle scope creep and it might help to focus on some tools for accomplishing those goals.

While project charter and statement of scope are sometimes used interchangeably, they are not quite the same thing. A charter is a document that launches a project and gives it the initial goal. A PSS delves into greater detail and answers questions the charter may not. Creating a PSS is part of the initiating phase of a project.

Creating a Project Scope Statement

Elements of a Scope Statement

A PSS is a bridge between the initial idea and the actual work needed to accomplish it. It fills in the outline provided by the charter with specific practical steps. A PSS includes elements such as:

Elements of a scope statement
  • Business or project objectives: Describe the characteristics of the goal and specific objectives to reach it.
  • Product acceptance criteria: Create some criteria or processes to determine when goals have been met.
  • Project deliverables: Describe the end products, including products, processes, deliverables, etc.
  • Critical success factors: Describe what the project must absolutely achieve in order to be considered a success. 
  • External entities and exclusions: Address issues, organizations, or goals that may be related to the project, but not associated with it.
  • Project constraints: Outline limiting factors, such as budget, schedule, and more.
  • Project assumptions: Outline contexts and factors that can affect the project, but in any case are outside the project’s control.

Defining the Project Scope

A PSS is a complex document and creating a clear statement of scope can potentially be difficult. Defining the edges of the scope and developing a plan can both present a challenge. Some tools that can help you clarify scope include:

  • Context diagram: Identify outside factors that can impact the project. Recognizing those factors can outline what the project needs to address to achieve goals. It can also identify stakeholders and prevent scope drift.
  • Use case diagram: Identifying the needs that have to be met by the project plan can reveal all the additional features that need to be included in the end product.
  • Product backlog: Use stakeholder and user feedback to create a wishlist of requested functions. Prioritizing such requests can offer a clear view on scope.

Creating a Change Management Process

If defining the project’s scope is difficult, changing it once the project has begun is even more demanding. Despite that, managing changes to the scope is an imperative part of a project manager’s job. A few basic guidelines can somewhat simplify this challenging task:

  1. Be lean: Particularly when a project manager is coming in from outside an organization, try to keep the process as simple as possible. Doing so can often keep things moving efficiently and with minimum disruption.
  2. Properly define the project scope: If a clear PSS isn’t created, how can you know when it’s changing? A clear scope is necessary when managing scope creep.
  3. Understand sponsor final acceptance: Project sponsors put the project in motion and will often have the final say over its completion. Understanding their requirements allows you to aim project work toward specific goals for success.
  4. Define change request process: Provide a clear path for change requests to be evaluated and then put into action. 
  5. Document and communicate change process: Outline the process and, vitally, make sure project team members understand it and are on board.
  6. Manage change: You’ve determined a change is needed, now it’s time to put it into action. This is a complex topic that deserves study of its own scope change.

That covers the high-level goals of a change control process. However, in practical terms, it also has to fulfill several functions to be successful, including:

  • Prevent changes outside the change control system.
  • Review requests quickly.
  • Maintain the integrity of the baseline scope.
  • Decide which requests to approve.
  • Manage each approved change request.
  • Coordinate approved changes through the project.
  • Document the changes made.

Understanding Stakeholders and Requirements

Managing the communication between project team members and key stakeholders, as well as managing a client relationship, are arts in themselves. However, there are a few tools that can help. Some can help you understand stakeholders in a more abstract way, while others bring them together to discuss issues directly. Described below are tools for both approaches.

Facilitated Workshops

A common tool in software development is the joint application design workshop. Similar gatherings can be used to help develop a complete understanding of scope for other types of projects, as well. The goal is to gather representatives from the different groups of stakeholders to discuss the project and reach a consensus.

A neutral facilitator can lead, which may not be the project manager, and may include a variety of activities to aid in communication. As an example, the participants may identify the strengths and weaknesses of the project, as well as any opportunities or threats. 

Workshops should end with outlining the next steps in the project’s progress. A collaborative process of this sort provides a roadmap for the project team and project managers that can help in preventing creep. 

Stakeholder Analysis

Stakeholder analysis is a range of tools used for several reasons. The goal is identifying stakeholders and understanding both the communicated and uncommunicated requirements they have for the project.

Stakeholders are at the heart of every aspect of project management. Analysis helps the project team best align their efforts with the project’s goals. Tools used in stakeholder analysis include:

Tools used in stakeholder analysis
  • Stakeholder analysis context diagrams.
  • Stakeholder interest and impact table.
  • Interest-influence classification.
  • Stakeholder participation matrix.

Frequently Asked Questions (FAQs) for What Is Scope Creep

Final Thoughts: So What Is Scope Creep?

Scope creep has been the cause of any number of failed projects. Managing it can seem like an incredibly expensive game of whack-a-mole. However, with a clear plan and some elbow grease, you can avoid scope creep or even turn it into a positive.

Project Scheduling: What Is a Schedule and Scheduling Management?

A project scheduling calendar with pinned dates

Anyone who has been responsible for a work schedule knows how complicated they can be. Imagine how much more complicated the schedule for producing an app or even constructing a building must be. Project scheduling is an involved topic that can be bewildering. However, those who take the time to understand it will discover a powerful tool for project managers.

Key Takeaways: Project Scheduling

  • Project scheduling is a multi-part process that takes the plan and turns it into concrete steps.
  • At minimum, a project schedule contains an estimated start and end date for the project.
  • Usually, a project schedule is a complex document that contains a lot of information, such as task lists, estimated task durations, and more.
  • Techniques like the critical path method and program evaluation review technique can be used to analyze the project schedule — looking for critical tasks or providing expert time estimates.
  • Modern project scheduling software is a great tool for project scheduling.
  • During the project, the projected schedule may change due to real-world variables.
  • As the project continues, the project schedule can be used for what-if scenarios, baseline comparisons, and performance assessments, among other things.

Project Scheduling Overview

The process of arriving at a complete and even vaguely accurate project schedule is no easy task. However, it is a critical one in the field of project management. Not only does it allow for more detailed project planning, but it is also a vital aspect of determining resource allocation and even determining project success. A project schedule is one of the most useful tools a project manager has at their disposal.

In some ways, project scheduling is the first place the ideas underlying project planning come into contact with the real world. The project scope —the goal and the process for achieving it— has to be broken down into project tasks. Project details have to be determined and taken into account. 

At the end of the project scheduling process, those disparate factors are translated into estimates and concrete dates. Key tasks that can’t be delayed in the project process are identified. A roadmap of goals and requirements, the project schedule, is developed to keep the project on track and on time.

What Is Project Scheduling?

A project scheduling process analyzes task sequences, durations, requirements, and constraints in order to develop a project schedule. The project schedule itself is the planned dates for performing those project tasks and meeting milestones.

There are a number of steps to create a project schedule, including developing task lists and a work breakdown structure (WBS), as well as putting together a project timeline. 

However, once the initial schedule has been developed, work has only really just begun. The schedule can then be used by project managers in further project planning, to estimate usage of organizational resources and identify critical tasks.

In complex projects, a well-defined schedule can be the only way of keeping things organized, so that prerequisites are met and the project isn’t delayed. Finding critical tasks means resources are directed where they can do the most good. Some types of analyses can also call on the expertise of team members to get informed opinions.

The schedule will most likely change throughout the project as hazards and efficiencies are discovered. However, once there is a draft schedule, project management tools allow managers to anticipate obstacles, create budgets, and more. Techniques like crashing and fast-tracking can also be used to change completion dates. 

Why Create a Project Schedule?

While other aspects of a project plan detail the what, where, and why of the project, a detailed project schedule provides the who and when. In other words, creating a project schedule is the first step in turning a plan into a product. Schedules play a critical role in project success in several ways, including:

Why you should create a project schedule
  1. Create a project timeline.
  2. Serve as a control tool.
  3. Efficient resource allocation.
  4. Portfolio management tool.
  5. Serve as a communication tool.

Create a Project Timeline

A project’s timeline adds actual, if estimated, start and end dates to a plan. That is valuable in its own right for a number of reasons, but one important one is the work breakdown structure. The WBS is the list of tasks and the logical order in which they have to be done. 

In project scheduling terminology, it helps identify predecessor tasks, which have to be completed before another task, the successor task, can start. The WBS can be expressed in several ways, including Gantt charts or network diagrams.

Project scheduling also provides tools for identifying risk and avoiding it. The critical path method, as we’ll see later, produces a list of tasks that can delay the entire project. A project manager might therefore devote more resources to those tasks.

Serve as a Control Tool

An initial schedule is an estimate and inevitably things will change, disrupting project progress. A schedule can help clarify which changes are worth making despite the hit to a project’s progress. It provides a baseline against which delays and costs can be gauged. Controlling changes to the project scope is vital to completing a project successfully.

Efficient Resource Allocation

Using a schedule, it’s possible to begin to allocate resources where and when they’re needed. A schedule can also reveal when there is a shortage of the resources required, potentially delaying the project. 

On the other hand, a schedule can also be used to effectively manage techniques like fast-tracking or crashing, where more resources are devoted to a task to complete it more quickly.

Serve as a Portfolio Management Tool

Most companies work on more than one thing at a time. With the schedule of each before you, it’s possible to make informed choices regarding project portfolio management. In other words, selecting the projects that will have the greatest benefit. It can also clarify how to distribute resources to each project in resource planning.

Serve as a Communication Tool

The schedule can be a great tool for communicating with team members and other stakeholders. With a clear schedule, everyone is on the same page regarding deadlines, resources, and other important information.

A clear schedule is also a prime use of PM software for startups, showing investors what they can expect at each step.

Project Scheduling Steps

Creating a project schedule is much more complicated than just coming up with a timeline or project calendar. It involves parceling out work, estimating duration and resources, and juggling a range of crucial issues. An outline of the process for creating a schedule might look like this:

Project scheduling steps
  1. Develop the WBS.
  2. Define tasks and logic.
  3. Estimate task duration.
  4. Define resources.
  5. Analyze the schedule.

Develop the WBS

A WBS is sort of like a step-by-step process for accomplishing the goals set out in the project plan. However, the relationship between each step may be more complicated than a simple consecutive task list. 

Working out those relationships is one of the more important and complex tasks project managers may be responsible for. As part of the project scheduling process, each step is further broken down into work packages. 

Define Tasks and Logic

In this step, the work to be done is further broken down into individual tasks. Project tasks are specific pieces of work, sometimes also called project activities. Project managers may decide how many tasks there are, or other factors may come into play.

The logic underlying task dependencies also have to be defined. In other words, individual tasks can relate to each other in different ways. Some examples include:

  • Hard logic: One task must be completed before the next can begin.
  • Soft logic: One type of task is usually performed before another, even if there’s no strict requirement.
  • False logic: An arbitrary order because you can’t work on all tasks at once.

Additionally, the requirements of the logic can be defined according to need. The most basic is finish-to-start, meaning one task must finish before the next can start. Another is finish-to-finish, which requires one task to finish before the next can be finished, but doesn’t define its start. Other options include start-to-start and start-to-finish. 

Estimate Task Duration

The WBS allows for the time estimates found in project schedules. The duration of each task is estimated—both best and worst cases—which, when added together, give the total project length. This is the ideal project schedule, in which the duration of each task is estimated without considering outside factors.

Two dates for completion are usually given, using the best and worst-case time estimates. The difference between those two dates is the ‘float’ or ‘slack’ in the project timeline. A common way of displaying this information is the Gantt chart.

Define Resources

In a draft schedule, the resources needed may not be taken into account. It’s reckoned purely by the amount of time each task is estimated to take, assuming perfect resource availability. At that point, it’s possible to gauge resources required at each point in your task list, compared to their availability. 

Resources can be things like materials or software. One of the most important resources is the project teams’ time.

Analyze the Schedule

Some of the most important tools available to a project manager are project scheduling techniques, methods of analyzing the schedule to better understand it. This step can also be thought of as optimizing the schedule.

By using project management techniques, two of which are described below, it’s possible to identify crucial tasks, accurately predict the project’s completion, and judge resource requirements.

Techniques

In the same way, the right tools help a carpenter take apart and put together wood, project scheduling tools help project managers better understand the relationships between tasks. For example, if two tasks can be worked on simultaneously, time and money are saved. Effective project scheduling also reveals key tasks, ones that can be used to aid in schedule management.

The right project scheduling software can make creating the project schedule much easier. There are many options, though you can check out our MS Project vs ClickUp review for examples.

Scheduling software will have tools to use the two project scheduling techniques described below. 

Critical Path Method (CPM)

CPM is a tool that considers all the tasks in the entire project, mapping out relationships in order to create a project schedule. It is a fundamental and common tool in project management that is usually used in combination with a network line diagram. Using it to calculate the longest path counterintuitively provides the shortest completion time of the project.

To clarify how it works, imagine that a project is broken into steps. In each step, one task will have the longest duration, which becomes the duration for the entire step. That task is the critical task and their completion usually defines major milestones. By plotting the schedule around critical tasks, we prevent redundancy and unnecessary delays. 

The estimate for each tasks’ duration is usually given for the best case, the worst case, and the most likely case. The difference between the best and worst-case scenarios is the float or slack. In the strictest sense, critical tasks should have 0 floats. However, ‘near’ critical paths may be used with more flexibility.

One common way of visualizing these charts is the network line diagram, though Gantt charts can also be used.

CPM doesn’t take resource availability into account. As a result, resource management comes into play in other steps. Sometimes, another technique called resource leveling may be applied.

Program Evaluation and Review Technique (PERT)

PERT was developed for military projects during the Cold War, in the early days of modern project management. It provides a way to accurately estimate project schedules by involving team members with expertise in each area. Each of the project activities’ or tasks’ duration is estimated. By adding them together, an overall project time can be calculated. 

Unlike CPM, the question of how to manage resources does come into play with PERT analysis. For example, it can reveal when more resources will be needed to keep the project on task.

While team collaboration is part of the PERT process, the entire team usually won’t be involved. Additionally, to keep things manageable, this technique may only be used for specific tasks.

Tools To Create Project Schedules in ClickUp

ClickUp has some of the best project management tools that are available. Modern project scheduling software offers a wider range of options and project scheduling tools than ever before, while also remaining relatively easy to use. As a result, ClickUp has many options to assist a project manager with their project scheduling. Some of the tools are:

Tools to create project schedules in ClickUp
  1. Tasks.
  2. Relationships.
  3. Views.

Tasks

The basis of the system is the task, which has the same general meaning we’ve been using: a discrete bit of work. An example might be an article for a website or a particular software function. Using tasks, it’s possible to monitor project progress and even be notified about overdue tasks.

Relationships

Multiple tasks can be strung together with task dependencies, which ClickUp calls its Relationships tool. It’s a ClickApp that has to be activated, so it’s not available to the free tier. However, with Relationships, tasks can be linked to each other without creating a dependency. Tasks can also be set as blocking or waiting on another task. 

Views

The project status can be reviewed using several reporting tools, which in ClickUp are accessed through different Views. For example, the Gantt view creates a Gantt chart for the project, based on the tasks and dependencies you’ve defined. Using Gantt charts, it’s possible to identify tasks that are causing bottlenecks or other causes of delays.

The major resource ClickUp is concerned with is people time, the workload of your team members. This can be reviewed in the Workload and Timeline views, allowing you to see how everyone is spending their time, as well as their availability.

Another ClickUp, called Milestones, allows you to create a milestone schedule of significant events. Milestones can be used to compare projected and actual progress, among other things.

See how similar apps stack up against our favorite in our ClickUp vs Hive and ClickUp vs GanttPro reviews.

Managing Project Schedules

The project schedule has been created and assigned tasks begun, but there are still many ways to use a project schedule as part of your project management strategy. The schedule is a tool that may evolve but will continue to be useful until the project’s close. Among other techniques, it can be used in:

  1. What-if scenarios.
  2. Comparisons to baseline.
  3. Performance assessments.

In addition to tracking project progress, project management software can be helpful with all of the techniques described in this section. PM scheduling software allows you to alter variables or change tasks without entering information more than once.

What-If Scenarios

The basic concept is familiar to just about everyone. Try to imagine likely scenarios that might affect the schedule, then follow those scenarios to see what could happen. What-if analysis should try to take into account all the deliverables, including documentation or marketing materials. 

This strategy is particularly useful for resource planning. Experimenting with different, hypothetical task management and resource management problems can prevent obstacles from arising.

Comparison to Baseline

The master project schedule provides an ideal schedule which the actual progress can be measured against. This is a key aspect of schedule management, comparing your average weekly planner notes, workload, task progress, and other factors against the original estimations. Doing so can often reveal problem areas and tasks that are lacking resources.

Performance Assessments

The flipside of a baseline comparison is the performance assessment. Team members’ performance should be gauged regularly, both to help them improve and to track performance. Similar assessments can be made for vendors, suppliers, or other aspects of the project. It’s not just people that are assessed.

Once a problem is identified, these assessments can be used to pinpoint the causes. They might also highlight potential solutions.

Key Project Schedule Related Terms

There is a lot of specialized languages when discussing the project scheduling process. To help keep things clear, here is a brief list of key terms and their definitions:

  • Task (also activity): A discrete piece of work, like an article or block of code.
  • Critical path: The sequence of tasks that determines the duration of the project.
  • Critical task: A task on the critical path, which determines a project’s duration. Not necessarily an important or difficult task, it’s the duration that’s significant.
  • Dependencies: A logical relationship between two tasks, either as a requirement or product. 
  • Float (also slack): The difference between the best case and worst case duration estimates for the project.
  • Gantt chart: Gantt charts are a form of bar chart that indicates projected task duration, task dependencies, progress, and other information. Often combined with the project calendar.
  • Network line diagram or network diagram: A graphical method of representing the dependencies between tasks.
  • Resource: Skilled team members, services, supplies, and other requirements to complete tasks. 
  • Resource leveling: Using resource requirements and availability to determine start and end dates.
  • Schedule: The planned dates for completing tasks or meeting milestones.
  • Successor: A task that cannot start until its predecessor is complete.
  • Predecessor: A task that is required to be completed before another task, its successor, can be begun.
  • Work breakdown structure: A breakdown of the project plan into specific steps and work packages.

Frequently Asked Questions (FAQs) for Project Scheduling

Final Thoughts on Project Scheduling

There have been books filled with different ideas about and on methods for producing a project schedule. As a result, we can’t do more than scrape the surface of the topic.

However, it’s a study that just about everyone could benefit from. By better understanding the process of producing project schedules, it’s possible to learn practical methods for managing our own projects and lives.

Essential Project Management Methodologies and When To Use Them

stacking blocks with project management (and methodologies) tools drawn on one side

There is no single agreed-upon definition of project management methodologies. However, in broad strokes, it can be thought of as a set of guidelines, principles, and processes for meeting or exceeding a project’s requirements.

Any project management methodology may help you complete a project. That’s not quite the same thing as saying any methodology will help you successfully complete a project within budget and on schedule.

Key Takeaways: Project Management Methodologies

  • Project management methodologies are a set of guidelines for running and completing a project efficiently.
  • There is a wide range of methods, some very broad and others tailored to specific contexts.
  • Agile methodologies feature customer input, decision-making by the entire project team, responsiveness, and an iterative process.
  • Traditional project management methodologies feature a clear plan from the start and a hierarchy with the project manager on top.
  • A project management methodology can be broad enough to use in several kinds of projects, or narrow enough to apply to a single person.
  • The role of the project manager can vary.

How To Choose the Best PM Methodology

Many factors go into choosing the right project management methodology. However, some basic factors you’ll need to address include:

How to choose the best PM methodology
  • Assessment of the project.
  • Deciding what will bring the most value.
  • Evaluation of your organization.
  • Assessment of your team.
  • Assessment of resources.

In the business world, a project is considered successful when it satisfies three criteria:

  • Time: Meets required deadlines.
  • Cost: Stays within an allocated budget.
  • Scope: Meets requirements.

In the history of project management, these three factors were considered vital to managing successful projects and are generally referred to as the triple constraint. While they might not be the invariable guides they might once have been considered, they are still important to a successful project.

A project management methodology organized along traditional lines seeks to define each of those factors before the project begins. Newer methods, particularly Agile project management methodologies, may try to redefine them in the course of the project and the project scope may be changed several times.

Project management methodologies may include defining those goals, or they may be predefined. Either way, understanding the following basic factors can make the project management process go much more smoothly.

Assess the Project

The factor that is going to have the biggest impact on the project methodologies you choose is the nature of the project itself. Consider how the project is going to be planned. For example, construction requires very specific project management phases due to legal and financial constraints.

Project managers may also wish to consider a hybrid methodology, which combines the strengths of both traditional and newer approaches.

Decide What Will Bring the Most Value

In any project, it’s important to ask if each task actually creates a benefit, to the project or otherwise.

Deciding which value to emphasize is wrapped up in the project’s scope and goals, defining exactly what you’re trying to accomplish. It can also impact how you accomplish those goals. For example, green project management methodologies may have the same set of critical tasks but require green methods. 

Evaluation of Your Organization

Factors like skillsets and organizational goals also have to be considered. You may wish to focus on projects integrating sustainable methods, for example, if your organization prioritizes the environment. 

However, if your organization doesn’t have the proper skillsets or resources, more time may be spent obtaining those than actually working toward the project’s goal. Likewise, prior experience with a specific methodology may make it more attractive.

Assess Your Team

Just as the nature of your organization can define which methodology is going to be most successful, so can the nature of your team. 

You may wish to divide a larger group into several project teams so that multiple goals can be pursued at once. That has consequences when it comes to resource and time management that some methodologies are better suited to handling. Additionally, the role of project managers can vary depending on the project management methodology.

Assess Resources

Access to resources is important, as are other aspects of supplying what your project needs. There are some management methodologies, like PMBOK, that focus more on resource management than others.

Often, a project management tool can be a good way of tracking resources. The best project management tools offer some flexibility to meet many needs.

Types of Project Management Methodologies

Examining a number of project management methods can clarify which best fits your needs. Keep in mind that this project management methodologies list isn’t exhaustive.

Types of project management methodologies

Agile: Collaborate To Produce a Working Product, Which Is Improved Iteratively

Agile project management has come to refer to a whole class of different methodologies that have certain characteristics. However, it is also its own methodology, which has become one of the most popular project management methods out there.

Agile methodology focuses on responsiveness to changing conditions. We’ll cover some Agile methods, but examples include extreme project management and rational unified process.

Agile projects will involve all team members in initial planning sessions. The team then works on tasks for a set period, after which progress is reviewed and additional goals are set in continuous integration of feedback. It is an iterative process that works collaboratively with a client to produce working software in short order.

When To Use the Methodology

Agile was originally developed for small teams doing software development, which often doesn’t have or require precisely defined goals. 

Pros and Cons

Some benefits of Agile include:

  • Continually improving.
  • Feature-driven development.
  • Response to changes.
  • Cooperation with the customer.

Some cons include:

  • Vulnerable to scope creep.
  • Lacks a clear plan from beginning to end.

Waterfall: Plan Straight From Beginning To End

Waterfall project management is a common project management methodology. In broad strokes, it’s the basic approach to project management methodology most people would evolve on their own. Phases of the waterfall method include:

Phases of the waterfall method
  • Requirements: Analyzing needs.
  • Design: Complete planning of the project.
  • Coding: Following that plan.
  • Testing: Features are extensively tested.
  • Operations: Finished product is put into use.

When To Use the Methodology

Waterfall methodology might work best with small groups for projects in which deadlines, budget, and scope are all clearly defined from the outset. 

Pros and Cons

Some advantages of the waterfall method include:

  • Clearly defined requirements.
  • A well-defined plan for project completion.
  • Cohesive end product.

Disadvantages include:

  • Little flexibility.
  • One missed deadline delays the entire project.

Scrum: An Agile Method Organized Around Short ‘Sprints’

Scrum is an Agile methodology, meaning it focuses on responsiveness to changing conditions and an iterative approach to tasks. It revolves around a couple of roles and a few events. Roles include:

  • Scrum master: A facilitator that helps the team understand and apply the method.
  • Development team: The project team members.
  • Product owner: Client or customer who selects features.

Tasks are set and then worked on in a ‘sprint’ of a fixed length. The team meets daily, as well as having a larger meeting after the sprint to assess progress.

When To Use the Methodology

Like most Agile methods, Scrum was developed and is used most often by software development firms. It probably works best with a smaller team that can meet all at once and which is able to work closely with a client.

Pros and Cons

Advantages include:

  • Focus on creating working products.
  • Works closely with the customer.
  • Responsive to changing needs.

Disadvantages include:

  • Lack of complete documentation.
  • Difficult to manage with larger teams.

Kanban: An Agile Method Using a Board to Track Project Progress

This project management methodology method was originally developed for assembly lines in Toyota factories. It is another Agile method, focusing on an iterative process to continually improve. 

The defining feature of this approach is the Kanban board, which helps organize the project into repeated stages. The underlying goal is to remove bottlenecks that can slow the project process and add to the cost.

The board is divided into four or more sections, usually including:

  • Ideas: Tasks that are still under discussion.
  • To do: Tasks that are ready to be worked on.
  • In progress: Tasks that are currently being worked on.
  • Done: Completed tasks.

When To Use the Methodology

Kanban allows a decent mix of pre-planning and flexibility. Goals may change and tasks adjust. However, it does require a clear idea of what a ‘finished’ task looks like. 

Pros and Cons

Advantages include:

  • Flexibility.
  • Clear goals.

Disadvantages include:

  • Lacks a clear process.

Extreme Programming (XP): An Agile Method Using Paired Programming

Another Agile software development method, extreme programming methodology is intended to offer small, updated releases periodically that each offers new functionality. It uses a strict testing method to identify problems and resolve them at each stage.

It focuses on several values, such as simple programming and collective ownership. XP is known for pair programming, in which two programmers work together, one programming while the other reviews for errors.

When To Use the Methodology

As the name implies, XP is focused exclusively on programming projects, specifically updating or replacing large, outdated systems. It combines pre-planning and an iterative approach.

Pros and Cons

Advantages include:

  • Close relationship with the customer.
  • Frequent testing.
  • Focused on simple coding.

Disadvantages include:

  • Limited application.
  • Piecemeal release.

Scrumban: Track Sprints on a Kanban Board

As you might guess from the name, Scrumban combines the project management approaches of Scrum and Kanban. The Kanban board is great for organizing a project and tracking the status of tasks. However, Kanban lacks a connection to higher levels of management, as well as a way to put releases into operation.

Scrumban allows for the easy tracking of tasks through the board, while dividing a project into discrete, iterative phases. This allows the team to work toward concrete goals while advancing the overall project.

When To Use the Methodology

As with most Agile methods, Scrumban is primarily used in software development and is one of the most popular project management methodologies in that field. It is ideal for projects where there is a clear idea of what a finished task looks like, without having well-defined goals overall.

Pros and Cons

Pros and cons of scrumban

Advantages include:

  • Flexibility.
  • Visibility.
  • Continuous improvement.
  • Focus on releasing products.

Disadvantages include:

  • Difficult for larger teams.
  • No clearly defined endpoint.

Adaptive Project Framework (APF): Plan Agile, Work Traditional

Hybrid project management practices seek to combine the flexibility of Agile with the clearly defined goals and processes of traditional project management methodology. Adaptive project framework is an example of such a hybrid.

The methodology recognizes that parts of a project may be open to an Agile approach, such as initial planning, but other parts require clear goals and deadlines. A project is divided into parts, with a plan created with Agile methods that are followed traditionally—lessons learned are applied to the following parts.

When To Use the Methodology

While APF was devised for software development projects, it has become popular in other contexts. Environmental planning, urban planning, and construction projects also use APF.

Pros and Cons

Advantages include:

  • Combines flexibility with clear planning.
  • Useful for large or long-term projects.
  • Responsiveness to changes, while maintaining clear goals.

Disadvantages include:

  • Complex.
  • Can be difficult to implement.

Lean: Smooth the Path From Supplier, to Production, to Customer

Lean methodologies use Agile concepts to focus on creating a simple, uninterrupted flow from suppliers, to production, and then to the customer. A Lean project may include suppliers in the planning process as a result. 

Additionally, Lean methodology attempts to identify a value for each product or service, in an effort to eliminate wasted effort and resources.

When To Use the Methodology

Lean is used in some IT companies. It may be a good choice whenever a project depends on an uninterrupted flow of resources.

Pros and Cons

Advantages include:

  • Customer collaboration.
  • Working closely with suppliers.
  • Eliminating waste.

Its primary disadvantage is that it might be better thought of as a management philosophy, rather than a true methodology.

Critical Path Method (CPM): Identify Tasks That Can’t Be Delayed

CPM is a traditional methodology focused on pre-planning and a clear path. The goal is to complete the project in the minimum time, at a minimum cost, drawing on as few resources as possible.

The critical path method involves creating a flowchart that can be used to identify critical ‘paths’ or task dependencies, as well as estimate completion times. In other words, it focuses on important tasks that can’t be started until other tasks are finished. This allows managers to focus resources on important points to prevent delays.

When To Use the Methodology

This approach is best suited for complex projects that have limited resources or have to share resources with other projects.

Pros and Cons

Advantages include:

  • Clearly defined goals and processes.
  • Shared resource utilization.
  • Reducing cost and time.

The primary disadvantage to CPM is that it may not be suited for smaller projects or projects in which resource management isn’t a concern.

Critical Chain Project Management (CCPM): Identify Critical Tasks, With a Flexible Schedule

Critical chain project management is similar in broad strokes to the critical path method. Both try to anticipate the path to project completion and identify important tasks along that path.

CCPM differs in assuming each task will be completed as efficiently as possible and so doesn’t need a fixed deadline. Instead, it uses task ‘buffers’, essentially scheduling extra time between one task and the next to allow for delays.

When To Use the Methodology

The context for CCPM is similar to that for CPM, with the difference that time is managed somewhat differently. CCPM might be a better option when it’s difficult to estimate task completion times.

Pros and Cons

Advantages and disadvantages are similar to CPM, with the difference that CCPM allows for more uncertainty in planning.

New Product Introduction (NPI): Cross-Department Cooperation To Bring New Products to Market

An NPI team is made up of representatives from different departments in a company and other interested parties. The team’s role is managing conflict between departments and outlining the overall process.

NPI focuses primarily on the production process, including design, feasibility, and pre-production testing. It’s a traditional methodology in which steps are outlined before work is begun.

When To Use the Methodology

NPI assumes the team is working within a larger organization that has production and testing facilities available. It also is most likely to focus on a physical product.

Pros and Cons

Advantages include:

  • Clear goals.
  • Well-defined process and schedule.
  • Well-established methodology.

Disadvantages include:

  • Not responsive to changes.

Outcome Mapping: Tracking Behavior To Plan Community Outreach and Development

Outcome mapping’s key attribute is that it is more concerned with behavior than a product or service. It was developed by an international development agency to organize development programs, such as assisting farmers in producing a wider range of crops. 

It has some characteristics of Agile methods, such as involving the beneficiaries in planning stages and reevaluating after a set period. However, the ‘product’ is a change in behavior in the community being developed.

When To Use the Methodology

Any project that focuses on community reform and development could probably benefit from using outcome mapping. 

Pros and Cons

Advantages include:

  • Evaluating changes in community behavior.
  • Community involvement.
  • Iterative structure to assess and evolve programs.

Its biggest advantage is also its greatest disadvantage, as the method’s narrow focus makes it unsuitable for use in other types of projects.

Six Sigma: Analyze Existing Processes To Eliminate Errors

Six Sigma is a methodology aimed at eliminating defects from products, processes, and transactions. It uses a five-step process that begins by identifying sources of error using statistical tools. In the following steps, users create solutions and ensure that the solution remains effective.

There is also a well-known project management certification program associated with Six Sigma.

When To Use the Methodology

Six Sigma will be most useful when searching for inefficiencies in a process. Using this method, those inefficiencies can be corrected.

Pros and Cons

Pros and cons of six sigma

Advantages include:

  • Process focused.
  • Clear progression from planning to execution.
  • Statistical approach.

Disadvantages include:

  •  Narrow use.
  • Assumes there is always a problem to solve.

Project Management Institute’s Project Management Book of Knowledge (PMI’s PMBOK): Comprehensive Standards for Project Management

PMBOK was written by a professional association called the Project Management Institute. It has often been identified as a set of standards for different project management methodologies, rather than being a methodology itself. It outlines broad areas of concern, from contract negotiation to cost management. However, it does not give specific tools for addressing those areas. 

When To Use the Methodology

PMBOK is organized along traditional lines and is intended to be applicable in many situations. It is more like an outline for a method, which may be helpful in situations in which an established method isn’t available.

Pros and Cons

Advantages include:

  • Traditional approach.
  • Wide applicability.
  • Created by a project management body.

Disadvantages include:

  • Lacking specifics.
  • Complexity.

PRINCE2 (PRojects IN Controlled Environments): Traditional Methodology Incorporating Customer Input

Originally developed as a method for managing IT projects by the UK government, PRINCE2 has been expanded for use in other areas. While not an Agile method, it still puts a priority on customer input. PRINCE2 is a complex method that uses nine elements:

  • Organization.
  • Planning.
  • Control.
  • Phases.
  • Risk management.
  • Quality in project management.
  • Configuration management.
  • Change control.

When To Use the Methodology

PRINCE2 is probably most useful in large software development projects. Its complexity may require some expertise, however.

Pros and Cons

Advantages include:

  • Detailed approach.
  • Involves the customer in the planning stages.
  • Addresses starting and ending a project.

Disadvantages include:

  • Complexity.
  • Not as useful in smaller projects.

Rapid Application Development (RAD): Methodology With Time Management as a Top Priority

RAD is a project management methodology that breaks each project down into components. Each component has a deadline or ‘time-box’ by which it must be completed, even removing features if necessary to stay within constraints. 

When To Use the Methodology

RAD is perhaps most suited to small projects in which there is a degree of flexibility in the final product, or where there is a tight deadline.

Pros and Cons

Advantages include:

  • Staying within time constraints.
  • Individual components can be adjusted.
  • User input early in the process.

Disadvantages include:

  • Possible to miss requirements due to time constraints.
  • Infrastructure (backups, documentation, human factors) is neglected in favor of time management.

Frequently Asked Questions (FAQs) for Project Management Methodologies

Final Thoughts on Project Management Methodologies

This brief guide merely touched on some of the most well-known and useful project management methodologies. However, while it is a field that was developed only in the 60s, it has become a broad and highly developed field. 

The complexity and breadth of options may be overwhelming. However, taking some time to investigate and choose the right methodology for your project can pay dividends in time and money saved.

Agile project management

A corporate woman giving a presentation on agile methodology to a group of persons

Right now there is no single more popular topic in (especially in software) projects than Agile. Before I describe what it is, here are the most common misinterpretation of what it is not:

  • it is not a methodology – it is a set of values and principles;
  • it is not a project management ‘method’ – it is a product development method that can be combined with other practices to cover the entire scope of planning and delivering projects.

You can take an agile approach to the management of anything (as far as possible) and what that should mean is that you are following as many of the principles of Agile as possible. Does that mean that 87 storey buildings are going to be delivered and accepted in an incremental manner? I think not.

Agile addresses a number of challenges which many would argue are ignored too often by projects in the past. However, it is a mistake to say that traditional methods fail to do what Agile does, the truth more lies more in the interpretation and implementation of traditional methods by project teams in the past. For example, there is nothing in Waterfall that says you can’t plan and deliver the project in a highly collaborative way; it’s just that people chose not to.

So what does Agile try and achieve?

Agile accepts a number of things, for example:

1. Priorities change
2. People find it very hard to envisage and sometimes communicate physical requirements, especially towards the font-end of projects and even more especially all in one phase.

It tries to have a development process that recognises, accommodates, allows for these and provides a more productive environment for requirements to emerge and be confirmed before actual code is developed, on a just-in-time basis.

It also encourages very short development cycles, so that the review (by users) of product is continual throughout the development process. When it works well, this can be an excellent way of producing product and reviewing it (almost) in real-time as it is developed. It’s the very opposite of a big bang approach and should reduce the size of issues to make them far more manageable. By the time you get to the end of the final iteration, there should be no major surprises. The development should be driven by the priorities of the business and therefore functionality of greatest importance should be at the core of the deliverable.

One other aspect is also attempted and that is to delay decisions until they have to be made. This can have advantages but takes a very skilled team. All development activity carries uncertainty so if uncertainty manifests itself around late decisions this could cause real issues and delays. This principle needs to be applied with great skill and care.

Agile can enable some really good things but there are some ‘Agilists’ who spread some very dangerous messages. For example: Agile does not do deadlines; projects begin with a product backlog; there is no accountability in Agile teams; Agile does not do (need) project management (on larger projects there are usually many things outside the software development – clearly these will all need to be managed too).

Agile is fairly simple to understand in principle – much harder to do (well) in practice.

Project or Operation?

Team leader presenting marketing plan on a white board to team members

A few weeks ago we held a course on Project Management Fundamentals. Every student introduced themselves; they were all seasoned professionals with 7 years of experience or more in their field. Justine worked for a manufacturing company. Kumar was a software developer. Ann deployed projects for a Cable TV provider. Carlos was a construction manager.

An interesting situation developed when we started discussing what constitutes a project. I asked the students for examples of the types of projects they deployed as part of their work, so I could tailor my stories. The examples were varied of course, as many initiatives can be considered a project. Kumar indicated that sometimes he needed to develop fixes for software bugs; Justine said that sometimes she had stations to install or replace in her manufacturing line. Ann mentioned she needed to plan Cable TV installations for her technicians.

I tried to understand Ann’s project constraints a bit better. Were the installations for new construction? For a group of existing customers? She seemed confused by the attention. The difficulty finally dawned on me when I asked what constituted the beginning and the end for her projects. She answered: “The first and the last day of the month”.

With a bit more discussion we realized that it was a misnomer to call her role a ‘project manager’, as her responsibility was an operation, not a project. Although she planned and assigned technicians and equipment for a whole month the effort never ended, it never ended. Similar to ‘payroll’ for example. She was astonished that neither she nor her management had realized this before. Her job planning, yes, but it never ended, which projects must.

Why is the differentiation important? Because one would optimize efforts that have a distinct beginning and end (projects) in a totally different way from efforts which are continuous and sustain the organization (operations). Everything from staffing to funding would be done considering different priorities and goals. Although Ann stayed in the class, I saw her on the last day signing on to a ‘logistics’ course.

A Project With China

Wrinkled Chinese flag on a dark background

The 21st century has brought a great increase in projects with companies in the growing economies of Brasil, Russia, India and China (for which Goldman Sachs coined the acronym of “BRIC” countries). There is no denying that, with the emphasis of multinationals in fulfilling the demands of those growing middle classes, many project managers can expect to perform projects with team members from those countries sooner or later.

A good friend recently was asked to go to Shenzhen to manage a project for his company’s Chinese business partner. As any good international traveler would do, my friend Fareed did as much research as possible before going to China. He read plenty of books on Chinese culture and customs; he got a Chinese cookbook; he even rented Chinese movies in Mandarin (with subtitles in English of course).

All this research yielded the following picture: the Chinese are a hard-working, collectivistic society. They are quite accepting of people in power and are highly contextual (which means that they take their cues from the situation more readily than from what is written).

I saw Fareed after his trip and asked him how the trip, and the project, had gone. “Great” he said “but instead of highly collectivistic I found everyone in China to be highly individualistic”. Based on his research, he had gone expecting people to act based on what was best for their group. Yet, everyone from the local builder, developer, driver, even the secretary took initiative and performed tasks depending on what was best for them, not necessarily their company. That came as a surprise.

We chatted about it at some length and finally arrived at the following conclusions, which we will apply to our future projects: (1) although a highly collectivistic culture in the past, given recent economic and other liberalization, Chinese culture may be changing from highly to moderately collectivistic. Maybe some day they will become an individualistic culture, much like the American or the Australian. And (2) whatever ideas you may have about another culture, even when based on research or experience, be ready to toss them out the window, as cultures are alive and constantly changing.

To RAID or not to RAID

Management spreadsheet on a laptop

A few weeks ago I was assisting a project manager with a troubled project. We reviewed the documentation from the beginning, starting with the usual suspects: project charter, WBS, schedule. They all seemed fairly straightforward and understandable. Once we got to his status reporting though, confusion started. This project’s status reports were spreadsheets about 10 pages long. Every week the team was only able to discuss only about 3 pages’ worth of information, and they were mostly risks.

“Why is this so long, what’s in it?” I asked him. He answered that it was his RAID Log, which he used to run Status Meetings. He wanted to be certain not to miss anything, so he was careful to include every item related to the project and classify it as R (risk); A (action); I (issue) or D (dependency) in this giant spreadsheet. As the first section was ‘Risks’ they were certainly addressed. So most of the discussion in his weekly status meeting was about events that had not even happened.

To be sure, used appropriately, a ‘RAID’ log is a great tool to help Project Managers keep projects on track. It lists, in one easily accessible place, almost any present or future turn of events that could impact their project. A few difficulties can arise though, which diminish the usefulness of a RAID log.

Frequency
In an average project, risks may not need review each week, but in a high-risk project the risk log may need to be reviewed more often even than action items. Each project has a different makeup, which should dictate the frequency with which each category in a RAID log needs to be considered.

Importance
Four categories (R,A,I,D) can generate many items. That is why in each category there should be a way to prioritize which the team, in fact, follows. This means that high priority issues or actions can be discussed in the status review meeting, whereas low priority items can be pursued by the project manager after the meeting, and as time permits.

Management Approach
Finally, the items in each of these categories require a different follow-up approach. For example: ‘Issues’ are problems. Small or large, they are discrepancies or disagreements which have taken place within the project and must be resolved. They may require conflict handling, negotiations or management involvement. On the other hand, ‘Risks’ are events which may or may not occur. Arriving at risk mitigation requires brainstorming alternative approaches, yes, but may never even have to be deployed.

For these reasons, think carefully about keeping one RAID log, or keeping separate Risk, Issue, Action and Dependency logs to be monitored at different times.

Project management certification just got easier

Person holding a certificate with a red ribbon

If you’re a North American reader of this blog them you’re probably familiar with the Project Management Institute (PMI®) and its professional qualifications:

Certified Associate in Project Management (CAPM®) and Project Management Professional (PMP®).

If you’re a European reader, then you are more likely to be familiar with PRINCE2® and its 2 qualifications: Foundation and Practitioner.

Until June 2014, if you were a qualified PMP, then you would still need to pass the PRINCE2 Foundation exam before sitting the Practitioner exam. That requirement has now been relaxed according to the PRINCE2 certification body – AXELOS. Providing you are a current PMP (i.e. your status has not lapsed) then you will be able to sit the PRINCE2 Practitioner exam without having passed the PRINCE2 Foundation exam.

This is good news for PMPs who wish to expand their professional qualifications. Many people often see PRINCE2 and PMP (or more specifically the PMBOK® Guide, on which the PMP exam is based) as 2 alternative approaches to managing projects. I think this is a simplistic view as I will now explain.

The PMBOK Guide is a detailed description of a number of knowledge areas, processes and techniques which a project manager should really be familiar with when managing projects. It’s based upon project management best practices. The PMBOK explains what the project manager is responsible for on a project, and only to a minor degree talks about the responsibilities of the project sponsor.

If I were to sum up the PMBOK I would say it’s good at describing core project management knowledge and how to do things – e.g. how to perform critical path analysis or how to manage stakeholders – but is not so good at explaining simply what needs to be done, when and by whom.

PRINCE2 on the other hand is very good at clearly explaining the steps required at each point in a project, what needs to be done and who is responsible. PRINCE2 also goes much further than the PMBOK in detailing the responsibilities of all roles within the project management team (of which PRINCE2 defines 9 distinct roles). PRINCE2 however is weak when describing how to do things – for example it only describes 2 techniques.

Whilst often, aspiring and practising project managers often ask “which qualification should I take – PMP or PRINCE2?” I personally think this is a false dichotomy.

As I have tried to explain here, the PMBOK describes “the knowledge and the how”, whilst PRINCE2 describes “the what, the when and the who”. Any tradesperson cannot do their job properly without a full range of tools in his/her toolbox. The same is true of project management. Use both the PMBOK and PRINCE2. They complement each perfectly and they will help to make you a better project manager in the end.

For those PMPs reading this, perhaps now is a good time for you to consider expanding your project management knowledge by gaining your PRINCE2 Practitioner certification as well. Oh and don’t forget, to keep your PMP status up to date you need to show you have obtained the relevant PDU’s. What better way of achieving this than to attend a PRINCE2 course which can help you to fill in those missing gaps which the PMBOK left out?

PRINCE2® is a registered mark of AXELOS Limited. PMI®, CAPM® and PMBOK® Guide are registered trademarks of the Project Management Institute, Inc.

The PMO Blues

Corporate person holding a couple of documents

A good friend who shall remain anonymous deploys projects for a large IT organization. Recently, as often happens, our conversation strayed into “work” topics. This time the subject became her Program Management Office, or PMO, with which she was greatly annoyed.

The volumes and volumes of reporting and paper my PMO demands have become completely unwieldy ”… “What’s worse is that, after all the hours the different measurements, trackers, logs and reports take nobody looks at them, much less management!” It appears Line of Business managers were now asking for reports additional to PMO reporting so they would be relevant, thereby increasing time demands on project managers.

It was not always like this. When the PMO first came into being in that company, about a decade ago, it was well received and immediately successful. Projects back then were just “stuff that needed doing”. No standards, no templates, no regular reports. Some project managers were more skillful than others, and they got better promotions. But with the PMO, all projects began to be more successful. Common reporting began. Tracking progress began. Unsuccessful projects were reshaped or cancelled. A few years later unfortunately, PMO demands had snowballed , and many new rules for projects had questionable value.

Last year, for example, their PMO had issued the mandate that the time units for all projects had to be “days”. Any project artifacts not in “days”, had to be edited and re-published using “days”. Every estimate, every schedule, going back a year. The reason was that the PMO felt it was pivotal to link all project schedules such that they could be rolled-up into one grand, “master schedule” for the whole company. My friend was aghast. “Hundreds of [obviously unpaid] hours required of project managers to retrofit project documentation, and for what?” … “Show me a single management decision that was made or changed from rolling up these collective schedules. Does any manager even look at these rolled-up figures…? She had a point.

So it is critical that management in our PMOs remain vigilant. It is important that they stay relevant and engaged, so they don’t take the PMO in questionable directions. PMOs are a natural source of change in the organization. If they cannot effectively introduce important changes, who will? Here are a few recommendations for PMO management:

Identify And Rank Problem Areas

The PMO and its management should be able to articulate at any given point which are the company’s pain points they are solving. What areas in their projects need improvement? What is their ranking? Is it profitability? Is it resource utilization? Then introduce new changes slowly, careful of correlating them with expected business benefits everyone (or at least senior management) considers strategic .

Seek Feedback From Experienced PMs

More managers could take advantage of the knowledge their more experienced resources have. Who better to evaluate what works or does not work in projects than the people who have been deploying them for customers, for years? All too often a good solution has been crafted by those in the front lines, but the problem remains unresolved because no one has asked those with first-hand knowledge what a good approach might be.

Retire Tools That Do Not Work

Finally, PMO management needs to be courageous enough to alter, or retire altogether, tools that are not producing expected business benefits. Maybe the tools take too long to deploy. Maybe they place additional hours of burden on project managers. Implementing a project is tricky enough, so let us try to not give project managers, additionally, the PMO Blues.

Agile Reporting From Waterfalls

A diagram on agile methodology concept

Quite a few customers are jumping on the ‘Agile’ bandwagon these days, choosing an Agile methodology for specific projects, or for repetitive releases of their product. A challenge they are facing is how to manage and report Agile projects when the processes and templates provided by their PMO have been developed for Waterfall projects. And of course, that content is what their stakeholders are used to receiving and discussing.

In Waterfall projects there often are Status Reports which list the tasks in the current work packages and their status. The tasks come from an agreed, project-wide Work Breakdown Structure.

In an Agile Scrum, there is no previously broken down, far-reaching Work Breakdown Structure. The team works from a ‘Product Backlog’, or prioritized list of functionality, which they have agreed with the product owner. They then commit to deliver a certain portion of functionality during a 30-day Sprint. Since the team organizes itself on how to deliver this functionality, and checkpoints daily on their progress and problems, the content of the work is very fluid. They cannot commit in advance to finishing this or that task in this or that timeframe. All they can commit is to deliver finished, working functions by the end of the 30 days. At the end of the Sprint, a “Sprint Review” takes place. So how could one issue weekly status reports, when Scrum offers no Work Breakdown Structure? Just the daily checkpoints and the review of the Scrum at the end of the 30 days?

I am sure there are a variety of creative workarounds Project Managers (ie, Scrum Masters) are using. One of the more successful approaches I have seen entails using the ‘Product Backlog’ as the basis for a status report. The Scrum Master can list the requirements or functionality in the Product Backlog as if they were work packages. Then, they discuss how close to completion these various functionality items are. Sometimes there will be a requirement in the Product Backlog which is not easy to visualize as a work item, such as “User Friendly Interface”. In this case, verbs can be added to give the stakeholders an idea of what the project team is doing, such as “Test Interface with 4 different types of users”. This ‘hybrid reporting’ will then allow the Scrum Master to perform another very important responsibility: protect their project team from distractions and interruptions during the Sprint.