Everything You Need to Know About Project Life Cycles

Project Management life cycles explained, based on PMBOK© Guide Sixth Edition

When dancing, if you start off on the wrong foot, you may never recover. Sadly, the same can happen if you pick the wrong lifecycle approach for your project. With the wrong approach, you run the risk of cost overruns, long delivery delays, and potentially a failed project. Luckily, there are several project life cycle approaches available to help you control and deliver your projects successfully. This post will explain the current life cycle approaches based on the recently updated A Guide to the Project Management Body of Knowledge (PMBOK ®  Guide – Sixth Edition) and how they affect project constraints.

What is the project life cycle?

The project life cycle contains every phase that your project goes through from beginning to end (cradle to grave). Some projects may have only one phase, others may have many. The PMBOK ®  Guide – Sixth Edition defines the project life cycle as “the series of phases that a project passes through from its initiation to its closure.” (page 19). That seems simple enough.

What is a phase?

Per the definition, every project is made up of one or more phases, which are “a collection of logically related project activities that culminate in the completion of one or more deliverables” (page 20). Phases can be sequential (back-to-back), iterative (cyclic) or overlap (simultaneous at points). The more phases and the more overlap, the greater the risk to the constraints of time, scope, and cost.

What is the life cycle approaches?

The PMBOK ®  Guide directly calls out two life cycle approaches: predictive and adaptive. Then it subdivides the adaptive life cycle approach into multiple phases that they call development life cycles:

  • Predictive
  • Iterative
  • Incremental
  • Adaptive
  • Hybrid

To help me decide what approach to use for a particular project, I focus on how the life cycle approach handles the project requirements, constraints, stakeholder feedback, and resources.

What is the generic life cycle?

Rarely is anything generic, but the PMBOK ®  Guide defines four generic phases in a lifecycle as

  1. Starting the project
  2. Organizing and preparing
  3. Carrying out the work
  4. Ending the project

(Figure 1-5 from page 18). The important things to know about this generic life cycle are:

  • Cost and staffing levels will continue to increase until they peak while carrying out the work
  • Risk and uncertainty will decrease over time
  • Cost of changes significantly increases over time

“All projects can be mapped to the generic life cycle” (page 19), so make sure to know them if you are going to take the PMP® exam.

Why do I care about the different types of life cycle approaches?

When there was only one approach, Waterfall, we needed to develop workarounds and try to contain and control everything within that fixed model (what a challenge). Today, with multiple approaches available, you can find the most flexible, cost-effective, time-sensitive way to deliver (what a relief). Below I detail the approaches mentioned in the PMBOK ®  Guide – Sixth Edition, but there are dozens more you can investigate and choose from, each having their own benefits and drawbacks.

Predictive Life Cycle (Fully Plan-Driven aka Waterfall) – During the previous 30 years of the last millennium (the ’70s, ‘80s, ‘90s), the Waterfall approach was the gold standard for all projects. It is a fully plan-driven approach where the 3 main project constraints (time, scope, cost) are all determined at a detailed level at the start of the project. You need to know your requirements going in and the scope is fixed at the onset. Each phase is then laid out sequentially and managed carefully.

Over time, to allow for more precise planning, the approach has allowed for “progressive elaboration” or “rolling wave planning” (page 185). Remember that scope and planning are two different things. Progressive elaboration doesn’t change the scope. It allows you to roll out the schedule into shorter passes. I measure all other approaches against the benefits and failings of this traditional approach (maybe because it is the first one I learned). Waterfall was great when I managed the very controlled and predictive development of a new hard drive at IBM. The project spanned years and didn’t require much stakeholder involvement (mostly at beginning and end or when we had scope changes that needed approval). The downside is that Waterfall is pretty inflexible when it comes to changes late in the project and therefore leads to significant cost increases when rework is needed. This is why I believe people started coming up with more adaptive approaches.  But Waterfall is still a good lifecycle approach if you have the development time and you know what you want to deliver. Don’t disregard its benefits.

Iterative Life Cycle – As timeframes for delivery got shorter and requirements got less clear, we needed additional lifecycle approaches that could handle the changes faster and less expensively. We found that when you broke large and complex projects down into smaller phases (aka cycles) it gave us more control (decreased risk and cost of rework). As the name implies, you execute the project in small iterations, giving you the ability to better define requirements at the start of each cycle. The PMBOK ®  Guide (page 19) recommends that you still define scope early in the project, but that you modify time and costs after each iteration since you will understand them better.

The iterative approach is like a bunch of small waterfall cycles with the customer verifying the work at the exit of each cycle. This gives you more flexibility and a better opportunity to address changes and reduce risk. You detail the scope for the next phase when you are done with the previous. I’ve used the iterative lifecycle approach when developing software updates. My iterations spanned 3 or 4 months at a time as part of a longer project.

Incremental Life Cycle – Many times you will see the incremental approach grouped with the iterative. They are similar but also different. The incremental lifecycle approach develops a product through the implementation of incremental steps which have predetermined timeframes. Each increment delivers additional functionality for the product and is repeated until the final deliverable is produced. Like with the iterative approach, customers signoff at each exit point. This approach is great when you want to do prototyping and reduce change risk along the way.

Adaptive Life Cycle (change-driven aka Agile) – Everyone wants rapid development these days, so when you need to execute a project fast, Agile is the way to go. This approach was built to handle changes and reduce inherent risk. The new PMBOK ®  Guide provides a whole appendix (Annex A3: Overview of Agile & Lean Frameworks, page 99) on the Agile/Lean approach. I highly recommend you read this Annex to better understand the concepts. Teams deliver software updates in weeks instead of months.

Adaptive projects are quick and time bound with two critical success factors:

  1. The customer must be intimately involved in the process and
  2. You must be able to define incremental requirements at the start of each iteration.

If requirements are not well known, like when you are developing a first of its kind application, the adaptive approach works nicely.

In addition to iterations being sequential, interactive, or overlapping, they could also run in parallel.  But don’t forget, especially when you are going at the speed of light, that each iteration should still be a complete cycle of Plan, Develop, Evaluate, and Learn. (Good project management process is all the more critical when you are going fast.) Iterations usually last 2 to 4 weeks at maximum.

To get a deeper understanding of all the concepts involved in Agile delivery, read the Agile Manifesto.

Hybrid Life Cycle – As it implies, the Hybrid takes the best of all approaches. You can use a predictive approach for the elements of the project that are known and an adaptive approach for the elements that will become apparent over time. “Hybrid methodologies accept the fluidity of projects and allow for a more nimble and nuanced approach to work,” says Jason Westland

Hybrid approaches are not new to project management, but they are definitely gaining acceptance as a way to solve life cycle problems in the 21st century. There is software coming on the market that allows you to blend approaches so you can manage different life cycle approaches all in one application. How neat is that?

Look for future posts on tips for choosing the best project life cycle approach. Feel free to comment below and I’ll do my best to answer your questions. Until next time, keep up the good attitude.

————————————————————————–
PMBOK® and PMP® are registered marks of the Project Management Institute, Inc.

Published November 10, 2017, on the IIL Blog

 

 

Virtual Communications: 5 Meetings for Better Teaming

Strong team communications are critical to project success. Whether building software, launching a program, or planning an event, there can be no team collaboration without communication.

According to PMI’s Pulse of the Profession, “Ineffective communications is the primary contributor to project failure one third of the time, and had a negative impact on project success more than half the time.”

When I was a new Project Manager, I had a project with development teams in Bangalore, Prague, and Rio. Miscommunication across the team was rampant and caused major delays and rework. It wasn’t pretty. Thankfully, I’ve learned a lot since then. By leveraging lessons from Agile, Kanban, and Waterfall, plus utilizing cloud-based collaborative and project management tools, I now can show my teams how to work better together and have fewer communications issues.

There are many ways to empower your teams for better communications and today I am going to share with you the 5 types of meetings I employ to build relationships, share ideas and best practices, and make sure that every team member is engaged and committed to project success.

The Short and Sweet Daily Meeting 

Daily meetings are not just for critical situations or Agile projects, they are my everyday wake up routine (after coffee, of course). Known as “Stand Up Meetings” or “Daily Scrums,” mastering the art of the 15-minute roll-call will keep your team connected. The way to keep the daily meeting short and sweet is by asking each person only 3 questions with 1-minute answers:

  1. What did you accomplish since our last meeting?
  2. What will you accomplish today?
  3.  What would keep you from getting your job done today?

As the leader, you need to be crisp and keep everyone moving along. Don’t waste anyone’s time. Stay focused. This is not the place for people to bring up new ideas or ramble on.  Set follow-on meetings with individuals or small groups if they need to discuss something or troubleshoot an issue. I pride myself on short meetings. Get everyone back to productive work as soon as you can.

The Required Weekly Team Meeting

To keep my team on the same page, and to ensure mutual support and collaboration, I insist on a weekly team meeting: its sacred to me. Though I set it for 1-hour, most of the time, we finish sooner. The meeting is always at the same time on the same day of the week. This is where I update everyone on company stuff (like corporate changes), people do updates on their projects, we share ideas, give recognition, get feedback, strategize for next week, and, this is where people can ask each other for assistance.

I run the meeting using a centralized project status report, which is kept on our cloud-based team collaboration site which everyone can access for weekly updates and status reporting. Having collaboration tools with direct messaging, file sharing, and screen sharing, like Microsoft Teams, or Slack, goes a long way toward better team communications too, but that topic will have to wait for another post.

Also during the weekly meetings, I have people do what I call, ‘show and tell.’  You learn a lot by demonstrating to others, so I try to get one person each week to show us something they are working on. This serves multiple purposes for the team: it gives individuals a chance to present their work in a comprehensive manner (which is a teaching/ learning moment), it gives the team member acknowledgement for their work effort (recognition is always good for self-esteem), and it highlights the individuals expertise (which is really valuable to other members of the team when they are trying to figure out who to call with a particular problem).

The Regular Touch Point Meeting

When I was at IBM, there were many different jokes about what the IBM acronym stood for. Those of us in the field used to say it stood for “I’m By Myself.”  Remote workers can feel very alone and out of the loop, even with lots of telephone meetings. To ensure my staff feels engaged, I have regularly scheduled one-on-one meetings with each of them. Since most of my staff is remote I use video chat, Skype or Cisco WebEx, when possible, which enriches the conversation with facial expressions and gestures.

The one-on-one touch point is a good time for me to catch up on personal things with the team member, which helps build trust in your interpersonal team relationship, but mostly, I use the call to listen to any new ideas or concerns and to provide mentorship on projects or professional development goals. I have found that by making time to listen to people and to ensure that they understand what is expected of them, they stay on the team longer (retention is important) and are more productive.

The Quarterly Team Meeting

Time flies, especially when your teams are turning sprints on projects in 1 to 3 weeks. Therefore, at least every 90 days (or 3 iterations of a project), it is important to look at what the team has done well and what they can do better. Every quarter, I turn one of the weekly meetings into two 1/2 day sessions (about 3 or 4 hours each).

Kind of like an Agile Retrospective Meeting, this gives the team a chance to focus on things that may have inhibited their success in the last quarter and gives us time to come up with solutions and ideas. To pull the team together, foster cohesion, and to help people focus on joint measurable goals, I instituted a process called Objectives and Key Results (OKRs) (spearheaded by companies like Google). The Quarterly meeting is where we review everyone’s contribution to the team. I am big on making sure that everyone feels part of the whole. Individualism, especially on collaborative teams, can kill sharing and cohesiveness if not managed properly.

The Annual Face-To-Face Team Meeting

With tight project budgets and extreme financial constraints in most companies, face-to-face team meetings are hard to come by. The benefits, however, of even one opportunity to get your team together goes a long way to building better team communications. I try to at least get those people within 500 miles in the same room. There are known limitations on the amount of emotional connection that can be shared virtually, so to create a tightly bonded team, even one physical meeting can speed up the process.

——————————-

Whether members are remote or local, effective team communications are central to project success. How do you ensure your teams are engaged and productive? Share your tips in the comments below.

 

Controlling Chaos: 6 Agile Steps To Finding Sanity

Have you lost control of your day? Is the pace of everything getting faster and faster, so that you just can’t get done what you need to? Do you feel like your projects are spiraling into chaos? Finding ways to maintain one’s sanity while managing large, fast-moving projects is a creative dance. Recently, while teaching a course on “Managing Projects in e-Business,” one of my students asked me how I controlled chaos on my projects. My answer: “I plan for it!”

chaosMy job as the Project Leader is to keep the project moving forward; to meet deadlines, budget constraints, ensure performance, and most of all to manage the client’s expectations. I know better than to think that I can ever ‘really’ control things, so I put processes and procedures in place to make sure that maybe the roof won’t blow off when the tornado comes through (if you get what I mean), and to know what I might do if, and when, it does. I have been managing chaos for years (long before there was Agile PM), with solid planning,  a deep understanding of my team and client, and with a nimble attitude.

What is Chaos Anyway?

On a project, especially in today’s complex and dynamic environments, chaos can be defined as “a state of the (project) system where the future development of the system is not predictable, or only poorly predictable.” (Avoiding and Managing Chaos in (Construction) Projects, Sven Bertelsen and Lauri Koskela, 11th Annual Conference on Lean Construction – Denmark, 2009  ) Basically,  a small unpredictable event, like the delayed arrival of key resource materials, may seem like nothing more than a nuisance when it happens, but the cumulative effect of many deliveries not taking place over many months can delay you to the point of no return. When you are dealing with complex projects, you are sitting on the edge of chaos most of the time. If you plan accordingly, it is less likely that you will be overtaken by events. (How to Save a Failing Project: Chaos to Control, Ralph R. Young, Steven M. Brady, & Dennis C. Nagle, Jr.. Management Concepts, Inc., VA, 2009)

Sanity = Practicing Good Project Management

  1. PLAN:  Make a plan, work the plan, and update the plan continuously. Do you have a Project Management Plan (PMP)? If you don’t have a roadmap, how do you know where you are going? You don’t have to document a tome of stuff, but as Agile Modeling tells us, “keep your plan simple enough, but not too simple.”
  2. TRACK: Know where you want to end up and keep your focus there. Stay on track. Do you have a Project Charter? Knowing what you are sponsored to deliver is critical to getting there.
  3. MONITOR: Have a metric by which you know how to check the health of your project. Do you have an analytics dashboard? How do you know you’re on track if you can’t show it in a graph somehow?
  4. PREDICT:  You need to know what your mitigation strategy is because something will go wrong. What is your Plan B? Do you have a Risk Management Plan? Chaos management is really just risk management. You may not know what is going to happen but you can plan how you will fix it when it does.
  5. FIX: Prevent everything you can from going sideways. You do this by a continuous (iterative) review. Do you have a Change Management process? Remember to change the easiest things first and get them going in the right direction. Repeat after me:  CHANGE IS GOOD when it gets you closer to your goal. Little changes along the way are a lot easier than a big change near the end. (It’s that cumulative thing again.)
  6. DANCE: Be agile in approach and attitude. You need to be open to alternatives when you need them. Stay close to your client and your sponsor so that you can make decisions when they are needed in the moment.

keep-calm-and-plan-ahead-36

I know it may sound oversimplified, but most of the battle of controlling chaos is staying calm and practicing good project management.  What dance steps have worked for you?