PM-Foundations on Project Churn

I often discuss with my colleagues that I have witnessed so much churn over the years that I could write the “Book of Churn”. Okay, so this is just a blog post, but I feel obligated to share my knowledge on the topic of churn. In the workplace, churn represents the counterproductive discussions, emails, and actions that create a “drag” on generating positive business results. In the context of project delivery, churn represents the “negative energy” within the team and the overall project environment that prevents your project from progressing at the planned rate, or successfully completing project milestones. Churn is manifested in a stakeholder’s negative communication, a team member’s non-productive actions, or project delivery processes that are slow or ineffective. At its worst, project churn can paralyze a project team, and overwhelm a project. You will find project churn at the heart of many challenged or failed projects.

The phrase, “one step forward, and two steps back” is a perfect visual for the impact of churn on your project. To help you put project churn in the right perspective, here are a few “real life” examples:

“The meeting after the meeting” – After a rather uneventful core team meeting, you see a group of team members talking outside the conference room. As you walk by you overhear, “I am not sure why we say we are on-schedule. The current design is going to take us at least 3 weeks longer than the plan reflects”. Shouldn’t that have been something we talked about in the core team meeting? Churn.

“The grenade” – The Steering Committee generated good discussion about the current plans and upcoming milestones. The team agreed that the right corrective actions are in place to successfully roll-out the new web site within two weeks of the original baseline milestone date. At the end of the meeting, when you ask “are there any other comments or concerns?”, the VP of Sales (who rarely attends the Steering Committee) raises his hand and says, “The way this system is being rolled out is going to be highly disruptive to field associates.” Shouldn’t this risk have been raised a little earlier in the project? Churn.

“I am waiting” – When you visit one of your developers to discuss why he is two weeks late starting a particular task. He says, “The integration work packages must be completed before I can start my development effort.” When you point out that the integration work packages are not reflected as a dependency in the schedule for his work, he says, “We are not using the project schedule to determine what we are working on. The project schedule is for the project manager, not the development team.” The project schedule is only for the benefit of the project manager? Churn.

“I think this is still an issue” – There is an open issue that is delaying the start of User Acceptance Testing. Every day it is not resolved has a direct impact on the “go live” date. When it seems that all of the decisions have been made and actions taken to close the issue, one team member speaks up in the core team meeting, “I think this is still an issue. I think we need more analysis and input.” Don’t you share my sense of urgency to resolve this issue? Churn.

Many times project churn shows up in very subtle and somewhat innocent ways on the project, but the cumulative impact of project churn can be devastating to project results. Below I describe 6 types of churn that I have witnessed on projects, and some of the impacts of this churn.

6 Types of Project Churn

1. Ineffective Meetings – Do your project meetings have a regular cadence (timing, content, and attendance)? Do the project meetings have an established purpose and objectives? Do the meetings drive positive project outcomes in terms of information sharing, problem resolution, and tracking and planning of work? Are action items regularly captured, and follow-up actions proactively initiated and tracked? If the answer is “no” to several of these questions, your project meetings may be a source of project churn. Project meetings that create churn ramble on, and provide limited benefit to the project team. In many cases, ineffective project meetings will actually be the source of confusion and misunderstandings on the team. It is a strong indication that your project meetings might be creating churn if you discuss the same issues/problems meeting after meeting, and team members become disengaged in the conversations — or do not show up at all. Another sign of meeting related project churn is if your meetings result in more meetings – “we will need another meeting to resolve this issue.” Communications within the project team, the ability to remove roadblocks, and the tracking and prioritization of project work are all negatively impacted by meeting related project churn.

2. Uncontrolled Change – I have been exposed to plenty of projects where team members state, “This project would be doing okay if it was not for all of the changes.” When you ask the team members what they mean by that statement, they often struggle to provide specifics about the changes that have impacted the project. Whether this is a factual statement, or just the perception of the team member, the fact that people talk about change that has not been managed through a change control process results in project churn. This type of churn can be highly disruptive on a project team because it can create contentious discussions between stakeholders when there is a disagreement between what represents change vs. elaboration or clarification. The key to reducing the impact of change related project churn is to establish the appropriate change control processes, and transform observations and perceptions of change into fact based change control related discussions and decisions.

3. Not Working to the Plan – The example above of the developer who says he is not performing project work based upon the priorities and timing established in the project schedule happens more than we would like to admit. This schedule related churn can start when the work is broken down and organized in the WBS in a manner that is not meaningful or logical to the team members that will be performing the work. The schedule that is generated out of this process may not reflect the right level of detail, durations, work effort, or sequencing, and therefore it creates churn because team members do not believe it reflects the “true” plan. Other projects start execution with a strong schedule that is well understood by the team. As project work is elaborated, or schedule related changes occur, the schedule is not appropriately updated, and the schedule starts to diverge from reality — and chaos ensues. The bottom line is if the schedule is not planned and progressed in a manner that is consistent with the way actual work is completed, you will be constantly battling schedule related churn. The analogy I like best that represents this type of churn is “pushing a rope uphill”.

4. Issues That Do Not Close – One of the easiest ways to monitor churn is to track how effectively the project team identifies and closes issues. Significant issue related churn is generally due to the project team not having the appropriate focus or urgency required to close issues. In some situations the team is not empowered to take actions or make decisions required to close issues. In either case, issues that do not close create “baggage” for the team, and eventually create roadblocks or challenges for the project. Issue related project churn also includes issues that are re-opened. This means the appropriate actions or decisions were not completed to correctly close the issue. I have seen many examples of issues that caused huge impacts (delays, rework, or defects) because they were left to linger and create issue related churn throughout the project life cycle.

5. Inappropriately Sized Processes – Project delivery processes are intended to improve the efficiency and effectiveness of the project team. However, often times project delivery processes are not appropriately established based upon the size and complexity of the project. If the processes are too “heavy”, teams get bogged down with the constraints associated with the processes. These “heavy” processes are often confusing to team members, and cause churn to figure out how to complete routine project delivery tasks. If the processes are too “light”, there can be too much deviation in the way project delivery activities are executed (some processes are invented on the fly). In these cases, the processes drive churn because the team is busy cleaning up the fallout from team members performing project delivery processes in an ad hoc manner. Process related churn is a perfect example of “one step forward, and two steps back” – either it is way harder to get things done than it needs to be (too heavy), or there are wildly different outcomes depending on the person performing the process (too light).

6. Disconnected Stakeholders – One of the most disturbing types of project churn is stakeholder related churn. This churn occurs when individuals or groups of individuals become disconnected from the project goals and activities, either due to lack of engagement or difference of opinions. Sources of stakeholder related churn can include core team members, the project sponsors & steering committee, and other stakeholders that directly impact or influence project outcomes. Sources of churn outside of these groups generally can be rationalized as irrelevant to the project. There is expected to be some churn when project teams are forming and storming, but at some point the “noise” should dissipate and the teams begin working well together to accomplish common goals. In some circumstances, negative energy from stakeholder related churn will work itself out, but in most cases it requires focused “intervention” to understand the core issues and establish the next steps required to smooth out the team dynamics.

What Should I Do?

Some project managers take on the persona of a “victim” and accept or escalate project churn. The reality is that as a member of the project team, the project manager is in some way part of the project churn. The project manager is in the best position to directly impact, or significantly influence, the level of project churn. Project churn can be directly impacted by adjusting project delivery process (e.g., change control, issues management), updating the project schedule in a manner that is more meaningful to team members, or enhancing project meetings and other team communications. Project managers can influence project churn by utilizing their soft skills to lead cohesive and productive project teams. The project manager’s soft skills are also leveraged to build and manage strong relationships with key stakeholders.

I obviously have a lot of opinions and perspective on the topic of project churn. I view managing project churn as a rewarding challenge, and not a burden or problem. I sincerely believe that turning negative energy (churn) into positive project outcomes is one of the most satisfying elements of being a project manager.


About Steve Hart
Practice Manager responsible for project leadership & delivery services for the Cardinal Solutions Group in the RTP area. I am a PMP with 25 years of project management and technical leadership roles, have developed an extensive practical knowledge that spans a wide variety of industries, and project delivery approaches. As a practicing PMP, I am a member of the North Carolina PMI chapter. I am an avid sports fan, particularly the Miami RedHawks, Cleveland Indians, Cleveland Browns, and most recently the NC State Wolfpack.

3 Responses to PM-Foundations on Project Churn

  1. Pingback: PM-Foundations on Project Churn « PMChat

  2. Paul Slater says:


    I really like your post, it brings together so well what many of us see in different types of project, not just the software development world. The quote you use

    “We are not using the project schedule to determine what we are working on. The project schedule is for the project manager, not the development team.” and The project schedule is only for the benefit of the project manager?

    is such a key one to teams who necessarily work in a project environment but often see Project Management as something of an add-on or a burden that others do on their behalf.

    Kindest regards


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s