Think about it for a minute: project management has been around since there have been projects. That means that some form of PM has existed since ancient times when major projects like the pyramids were built. But it wasn’t until the early 1900s that things started to become more formal. In fact, Henry Gantt created (or adapted) a nifty tool called the Gantt Chart in 1917. One of the first major applications of the tool was in World War I by the United States. From that point forward, new methods and tools have been created to help teams keep projects on track.
As a project manager, it’s important to know your history, and it’s not just for the sake of knowing what happened. It’s good to know how methods were created, and decide for yourself how they can be adapted in the work you’re doing today. So, if you’re looking to learn, you’ve come to the right place. This article will explore many project management methodologies that exist, but more specifically: including:
- Traditional Approaches
- Agile Methodologies
- Change Management Methodologies
- Process Based Methodologies
As a project manager, It’s good to know how project management methods were created, and decide for yourself how they can be adapted in the work you’re doing today.
How to choose the best approach for your projects
What’s to follow is designed to teach you a lot about the basics of many, many project management methodologies. And, while it’s important to have a solid understanding of the many different ways to operate a project, you don’t have to feel as though you’re tethered to just one way of working. In fact, it’s very important to remember that you have to do what works for your team, your clients, and your project itself.
The fact is, a prescribed method may not always work the way you want it to. And, you’ve got to have the right mix of people, budget, and deadline to truly make something work well (or as you intended). What it comes down to is that none of these methods are “better” than the others. Do what you can to understand them and adapt them to your situation. Hey, you might find that parts of Agile work for your team, but not all of them--and that is okay too. Whatever you do, don’t overthink your process. Try something new, adjust when you see the need, and focus on solid communications and delivering quality work.
If you’re having a hard time deciding what steps in a process will work for you, think through these questions and scenarios:
- What is the intended outcome of your project?
- Is it product you’ll create? An experience? A specific deliverable?
- What are the goals of the project?
- Who needs to be involved in the project based on the answers to questions 1 and 2?
- How do the people you’d like to assign to the project like to work?
- Is anyone certified or really, really harcore about sticking to a methodology?
- If you’re working with a client, do they subscribe to a methodology?
- Are you aware of how they work, and how will their way of working impact your team?
- Are there any outside factors you need to take into account when planning? (Think about dependencies, project or client values, etc.)
- What is already working for your team? What is working for your clients? Also, what isn’t working?
Traditional Project Management Methodologies
Some projects--or even industries--require projects to be run sequentially. So, if you’re working in construction or something similar and do a lot of planning to ensure that the completion of a sequence of specific tasks gets you to the delivery of a final, finished product by a certain date and within a budget, you might be interested in mastering these methods.
The Waterfall Method
The Waterfall model was invented by Winston W. Royce in 1970. He wrote a scientific article that contained his personal views on software development, and showed examples of why this process doesn’t work as well as more iterative approaches. But, the waterfall method does work in some industries. Here’s why.
Waterfall is certainly among the most widely-known and practiced PM methodologies. The key ingredient in running a waterfall project is to complete a task and hand it down for it to be used, or built on, in a following task or phase. This requires a fair amount of planning and requirements gathering before work begins. Without that initial step, steps can be missed, incomplete, or even out of line. Further, any alteration to project requirements can cause a change in scope.
It’s easy to plan a project this way, but as soon as change occurs, you’ll be faced with scope changes, confusion, and pushed out deadlines. Waterfall is known for the handoff--allowing resources to work in silos. It works in some places, less in others. It has worked quite well for software development projects, though you’ll find that many teams have moved on to more modern approaches. Since, it has been adopted by other industries who find that pre-planning and requirements help to organize their project needs, and finitely plan out steps, tasks, and associated resources to meet timelines and budgets.
Critical Path Method (CPM)
The Critical Path Method is complex due to the steps and analyzation involved, but it is actually quite simple! When done properly, this method can provide great clarity into a project’s tasks and how long a project will take to complete, This project modeling technique was developed in the late 1950s by Morgan R. Walker of DuPont and James E. Kelley Jr. of Remington Rand, who were working on similar project approaches. It has since been modified, and generally is applied to any approach that breaks a project into several work tasks, displays them in a flow chart, and then calculates the project duration based on estimated durations for each task.
In essence, the goal of this method is to map out all of the tasks of a project, define out what needs to be completed before each task starts, then estimate the time it will take to complete each task. From there, you calculate the longest path of the planned tasks to the end of the project, and the earliest and latest points each task can start without making the project longer. That’s how you determine what’s critical, and what can be delayed (there can be more than one critical task). Essentially, you prioritize tasks to ensure you get the most important work done first.
You’ll find the Critical Path Method used for many types of projects, including construction, software development, research projects, engineering, and even product or software development. The first time CPM was used for major skyscraper development was in 1966 while constructing the former World Trade Center Twin Towers in NYC. Although the original CPM program and approach is no longer used, the term is generally applied to any approach used to analyze a project network logic diagram.
Agile methodologies are based on the mindset that self-organizing software development teams can deliver value through iteration and collaboration. The Agile Manifesto for Software Development was formally developed in 2001 by 17 practitioners and is based on a core set of values of delivering value and collaborating with customers. The principles are:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Over time, several Agile approaches have been developed, tested, and revised--just like the methodology itself. You’ll find information below about various Agile methodologies to research and try with your team. You might even come up with innovative ways to mix the more traditional methodologies with Agile, like using a gantt chart to manage your Agile projects.
Simply put, Scrum is simplest--and likely most popular--of the Agile methods that exist today. There’s some confusion over who “invented” scrum, but we’re excited about the ideas, because it allows teams to get work done without added complexity that some methodologies introduce.
When practicing Scrum, a team self-organizes around central roles that suit them: Scrum Master, Product Owner, and Engineering/Development Team. The Product Owner sets the vision and priority for the project, and the Scrum Master removes any blockers from the Development Team’s way in order to get the work in two week cycles, or “sprints”, to get work done quickly. Scrum calls for “ceremonies” (meetings for the uninitiated) to keep things on track:
- Daily stand ups: A short (15 minutes max) meeting each day to discuss progress, what’s next, and blockers. You stand during this meeting in order to keep it short, because who wants to stand for that long?
- Sprint planning: A creatively named meeting that is a bit longer (an hour max) and comes with the objective plan what will be done within the sprint.
- Sprint review: A meeting to review all work done at the end of a sprint. In this meeting you might collect feedback, decide something is done, or decide on an alternate route.
- Sprint retrospective: An often-skipped meeting held after the sprint review for up to an hour to discuss what might make future sprints more productive.
There is an art to finding the right pace for a team, but Scrum does a really nice job of defining your pace and expectations at the outset of the project--and at each sprint. You’ll have to work through it to make sure that the roles and ceremonies work for you, but again, you can always adapt if you’re working on creating products and can continue to refine and iterate it until your customers are happy.
In 1953, Toyota adapted supermarket inventory control process logic to their machine shop as a process and officially used a “signboard” or “billboard,” which is the literal translation of the Japanese word “Kanban”. This visual approach puts time and resources aside and focuses on tasks. In fact, Kanban helps teams to make decisions on what to produce, when to produce it, and how much of it to produce. If you’ve used a tool that shows cards move through a progression of states to indicate where it is in process, you’ve used a Kanban board.
Many Agile teams use Kanban boards to remain transparent about where their work stands in process. The visual management of the board allows teams to quickly point out and understand project obstacles, discuss them, and collaborate on ways to get past them. You’ll find a lot of teams working on digital projects using Kanban methods to manage their workflow.
Extreme Programming (XP)
Want to take your method to the next level...or the extreme? Well, check out XP, which was created by software engineer Kent Beck in the 1990s during his work on a payroll project at Chrysler. This Agile methodology is intended to improve quality by responding quickly to change. If you’re working on projects that have shifting requirements and continuous feedback, you know that change can happen...and is normal, Extreme Programming might be just for you. XP describes four basic activities that are performed within the software development process that allow for change and rapid revision: coding, testing, listening, and designing. Teams organize in shorter sprints and teams can immediately change the course of their work being done/planned.
Adaptive Project Framework (APF)
This one may resonate for PMs who recognize that you have to adapt your methodology to the project’s goals. With AFP, you document project requirements, functions, sub functions, and features before determining project goals. The team then operates in iterative stages rather than sprints, but stakeholders can change the project scope at the start of each stage. So, truly, you adapt to the project--and its people.
Change Management Methodologies
Risks are inherent in all projects. You just know something will come up, and you want to prepare for them. These methodologies are meant for the PM folk who are hyper-focused on what could pull a project off the rails, and come up with stable ways to get it back under control, or just rolling with it and making sure the project gets done!
Event Chain Methodology (ECM)
If critical path wasn’t enough for you, you want to take a look at ECM. The six principles of ECM make up a technique that is focused on identifying risks and their potential effects on a project’s schedule. Think of it this way: The ECM PM is living in doomsday. Everything is a risk, and they know how to handle it. On one hand, it makes the team comfortable. On the other, it can be sort of gloomy to always think about the worst that can happen. After all, your control ends somewhere, right?
Extreme Project Management (XPM)
Not to be confused with Extreme Programming, XPM is all about embracing change and altering project plans, requirements, resources, budgets, even the final deliverable to meet changing needs. You’ll find that most projects that follow XPM are shorter in nature--this isn’t the type of method to use on a long project that carries the risk of dragging out for months and months; rather it is fast-paced, requires short cycles of work, and openness to feedback and iteration that can evolve the original intent of the work.
PRiSM (Projects Integrating Sustainable Methods)
This method was developed by GPM Global for managing change focused on sustainability, or using existing organizational resources to reduce negative impact on environmental or social impacts. It follows six principles that are derived from the UN Global Compact’s Ten Principles. This is serious process work that can make our lives better in major ways, and they’re typically implemented primarily for large-scale real estate development or construction/infrastructure projects that may result in adverse environmental effects.
New ways of working materialize every once in awhile and catch some traction. Sometimes these are more likely seen as business processes rather than methods, they certainly have the potential to grow in to them. After all, based on history, that is how a lot of the aforementioned methodologies began. So, while not all of these may really be classified as “methodologies,” and they might not apply to you, they are worth mentioning because you might be able to lift an idea from one methodology to apply it to your own work.
Do more with less! This methodology is focused on removing unneeded steps, resources, and budget in order to deliver a product. If you’re in the digital space, you might have seen talk of Lean UX, which is mostly about about applying the Lean methods to User Experience work, which has traditionally weighed heavily on project budgets due to an abundance of deliverables (sitemaps, wireframes, flow diagrams, content inventories, taxonomies, and so many more). Lean UX brings ideas and the actual design of the experience to the forefront of the process, with less emphasis on deliverables.
This is a disciplined, data-driven methodology developed by an engineer at Motorola, and has been adopted by many large organizations focused on manufacturing. It seeks predictable process results to improve the quality of final product by following a set of steps and removing the cause for defects. A six sigma process is one in which 99.99966% of all opportunities to produce some feature are statistically expected to be free of defects. That’s quality assurance..and profitability!
PRINCE2 (PRojects IN Controlled Environments)
This methodology was developed for use by the UK government, and has grown widely since, as it’s now being used all over the world. With this methodology, the project is tightly controlled and planned before it begins, with stages clearly structured. This process-based approach leaves very little room for questions, as it is based on seven principles, seven roles, and seven process phases with direction on very specific documentation.The role of the PM is a bit different with PRINCE2, as he or she is responsible for basic activities like scheduling, while an appointed project board handle activities like resourcing and goal setting and the team
Choose or Devise a Methodology That Will Work for You
Gaining an understanding of the many methodologies presented here should help you to understand how and why project management can be approached in several project types. It’s safe to say that projects are being managed in a variety of ways, and no method is “better” than another. You need to do what works for your team, your stakeholders, and your project itself. No matter what you do, make sure you outline and discuss your methodology with your team and be sure that everyone understand it and is on board. After all, the key to success is communication and nicely set expectations, not a process map or plan.
What to read next:
THE DARK ART OF PROJECT ESTIMATION
In order to create a workable estimate, you need to know your team, deliverables, tasks, and process like the back of your hand.
Complete list of Chapters
- Chapter 1:
The Good Project Manager
- Chapter 2:
What is Project Management?
- Chapter 3:
Project Management Methodologies
- Chapter 4:
The Dark Art Of Project Estimation
- Chapter 5:
Writing and Selling a Masterful Project Plan
- Chapter 6:
Taming The Scope Creep
- Chapter 7:
If They Expect A Unicorn, It’s Your Fault
- Chapter 8:
Managing Project, Helping Clients
- Chapter 9:
How To Put ‘Me’ In Team
- Chapter 10:
Master The Art And Science Of Meetings
- Chapter 11:
Beyond 40 Hours: Continuous PM Learning
Sign up to get notified of our upcoming free guides and content
Including a free video series from TeamGantt featuring Brett Harned!