The World of Project Management Methodologies
Before you go and start outlining your guiding project management principles, it’s smart to educate yourself on the many documented project management methodologies. Next, you will find a list of those PM methodologies with basic descriptions. You won’t believe just how many there are and how they might not even apply to you. There are plenty of resources for you to dig in, to understand these on a more complex level, but having a high-level understanding of them will help you to understand how you can form your own principles (which we’ll spell out later in this chapter).
Traditional Methodologies
If you’re a PM purist who needs a checklist and a place for every single project task, you’ll love these methodologies. Get excited! Load up that spreadsheet! If that’s not quite your thing and you’re looking to do something a little “out of the box,” you may want to skip this section. Go on, be brave. Either way, check out these basic methodologies that can be used to inform any process—from moving your office or home to building a car, ship, or even a spacecraft!
• Waterfall: It’s the most widely known PM methodology, which requires one task to be completed before the next one starts (see Figure 2.1). 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 (ahem, digital).
FIGURE 2.1
Everything goes downstream in the waterfall method.
• Critical Path Method (CPM): This is a complex method that is actually quite simple! You map out all of the tasks of your project, figure out what needs to be completed before each task starts, and 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 you figure out 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. It’s kind of like prioritizing tasks to ensure that you get the most important work done first.
• Critical Chain Project Management (CCPM): This methodology focuses most on the constraints put in place by resources (people, equipment, physical space) needed to get the project done. As the PM, you build the plan and identify the tasks that are the highest priority so that you can dedicate your resources to them. Then you place time buffers in your plan to ensure that your resources are available to get the work done. Seems sneaky, huh?
• Process-Based PM: This methodology is a little more flexible than the others listed in this section, but a formal process is still required. In general, the difference is that it aligns a project with the company’s goals and values. Each project follows these steps:
• Define the process.
• Establish metrics.
• Measure the process.
• Adjust objectives as needed.
• Plan improvements and implement them.
NOTE PMI AND PMBOK
While it’s more of a set of standards than a formal methodology for managing traditional projects, you should know what it’s all about. The Project Management Institute (PMI) created the Guide to the Project Management Body of Knowledge (PMBOK), which outlines the following steps for all projects: initiating, planning, executing, controlling, and closing. Check out more at http://www.pmi.org/.
Agile Methodologies
Probably the single most buzzworthy project management term, Agile is based on the mindset that self-organizing software development teams can deliver value through iteration and collaboration. It was formally developed in 2001 based on the Agile Manifesto of Software Development and is based on a core set of values:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan
There’s a lot of confusion out there about what “Agile” means, and that might be due to the fact that there are several ways to execute the methodology. Many teams claim they are agile, but they don’t use the methodology by the book. That’s OK, but that’s not Agile with a capital “A.” That’s just working faster. So what is Agile then? It can be boiled down to these main points:
• The product owner sets the project objectives, but the final deliverable can change. (For example, a goal can manifest itself in many ways, and you’ll explore them together.)
• The product team works in two-week sprints, which are iterative in nature. At the end of each sprint, the collective team reviews the work done and decides what is complete and what needs iteration.
• Depending on sprint reviews, the final product might be altered to meet the product owner’s goals or business needs, and that’s OK! (No scope creep here.)
• Everyone collaborates! That’s right—open conversations about what works best for the product make for a better final deliverable, and those comments don’t just come from developers—they come from the whole team (see Figure 2.2).
NOTE THE AGILE MANIFESTO
Written in 2001 by 17 software developers, the Agile Manifesto puts forth core values and 12 principles for “uncovering better ways of developing software by doing it and helping others do it.” Read the full Manifesto online: http://agilemanifesto.org/.
FIGURE 2.2
Plan, iterate, review, iterate, iterate, iterate . . . review, iterate, deliver, and iterate again. That’s the cycle of Agile!
Now that you understand the core of what “Agile” means, you can understand the “flavors” of it:
• Scrum: The simplest of Agile methods, because it allows teams to get work done without added complexity that some methodologies introduce. Essentially, the team self-organizes around central roles that suit them: Scrum Master, Product Owner, and Engineering/Development Team. The Scrum Master’s role (kind of like the project manager) is to remove any blockers from the team’s way in order to get the work in two-week cycles, or “sprints,” to get work
