PM-Foundations – Sizing Your Project Management Processes

On more than one occasion I have mentioned that project management processes should be sized appropriately for your project. I truly believe that “one size fits all” is not an effective approach to implementing project management processes. It is important to strike the right balance between establishing “heavy” processes that constraint progress, and running your project with little or no focus on how the work will be managed. As I recently discussed in my post on project churn, process 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). With the right balance, project management processes enable project work to be completed in a repeatable and efficient manner.

I am not a fan of having two sets of process – one for big projects, and one for small projects. The preferred approach is for the project office to establish project management processes that are appropriate for the organization and the project environment. As a project is launched, these processes are tailored to meet the needs of the specific project scope and complexity. In this blog I discuss the key characteristics of project management processes (what makes them too “heavy” or too “light”), the “critical” few processes to focus on, and how to adapt these processes to the specific needs of your project.

Key Characteristics of Project Management Processes

The characteristics associated with the project management processes really define how appropriately they are sized to deliver your project in an effective and efficient manner. Below are the characteristics that I generally focus on when tailoring the project management process during the launch of a new project.

  • Time – This one is kind of obvious. How long does it take to complete the process (in terms of both duration and effort)? Is the time invested in the process appropriate based upon size of the project and the potential impact of the process on the project? Many teams inadvertently build time into the process. Examples of time built into the process include forms that take hours to complete, or approvals that only happen once a week.
  • People –Who is responsible for initiating the process? How many times does the process move from one person to another? How many people are involved in the review and approval process? Involving more people in a process mitigates the risk associated with errors or bad decisions, but also adds time and overhead to the process.
  • Documentation – Is the process documented? Is process documentation leveraged to perform the process in a repeatable and efficient manner? Process documentation maintained by the project office is helpful as a starting point, and adjustments to size the process for your project (tailoring) should be the focus in the project management plan.
  • Artifacts – What artifacts are created through execution of the project management process (e.g., spreadsheets/lists, forms)? Are the artifacts a by-product of executing the process, or do they represent additional steps/work? Artifacts are not free, therefore it is important to assess whether or not they add value to your process.
  • Tools / automation – When you talk about tools and automation, by default you think “faster” and “less effort”. In reality, introduction of tools and automation is where project teams have a tendency to add the most overhead to their processes. I have seen many examples of tools that are “over-engineered” for the problem they are trying to solve, and add overhead to the process (vs. streamline it).

The “Critical Few” Project Management Processes

Establishing, implementing, and re-enforcing best practices around the “critical few” project management competency areas will represent the difference between a successful and challenged project. The “critical few” competency areas is also where you should focus to appropriately size your project management processes.

  • Change management – How are change requests initiated? Who assesses the impact of the changes? Who reviews and approves the changes? How are changes implemented? How is project change measured and reported?
  • Issue & Risk Management – How is project risk assessed at the beginning of the project? How are risks updated throughout the project? How are issues identified and tracked? Who is accountable for mitigating risks and closing issues? How often are risks and issues reviewed as a team? How are issues and risks measured and reported?
  • Schedule Management – How and when is the schedule regularly updated to reflect progress? How is the progress communicated to the team? How are corrective actions identified and communicated?
  • Cost Management – How are actual costs captured? How are project purchases initiated? Who approves project purchases and payments? How are budget variances and corrective actions identified?
  • Project Communications – What is the format and content of project status reports? What is the process for preparing, reviewing and distributing project status reports? Is relevant project information available to stakeholders? How does the project team interact on a regular basis? Does the team have regular team meetings? How is the project sponsor updated throughout the project life cycle?

The table below provides some indications that project management process may be “too heavy” or “too light” for each of the “critical few” competency areas.

Process Area

Too Heavy

Too Light

Change Management

  • The change request takes a significant effort to complete due to all of the information required
  • A lot of people are involved in the assessment and approval of the change request
  • Changes get lost in the approval workflow
  • It seems like it takes forever to implement change, even when everyone thinks it is the right thing to do
  • Change is not documented or communicated
  • The impact of change is not assessed before it is approved or implemented
  • The actual impact of change is not measured or managed

Issue & Risk Management

  • It takes significant effort to document an issues due to all of the information required
  • Issues and risks are reviewed more frequently than the pace of actions to mitigate or close issues and risks
  • The number of issues and risks tracked is overwhelming to the project team
  • Issues get lost in the resolution workflow
  • Risks are not assessed at the beginning of the project, or routinely reviewed throughout project execution
  • There is no clear accountability established to manage an issue or risk
  • Risks and issues are not documented or updated in a central repository accessible to the team

Schedule Management

  • It takes significant effort to complete project progress updates because it tracked in so much detail
  • There are multiple layers of management involved in capturing progress
  • By the time the schedule is fully updated, it is time to start the next reporting cycle
  • So many reports are produced that it is difficult to understand what to focus on to understand where the project is at
  • The project schedule is not updated after project planning is completed
  • Schedule slippage is identified and reported after the fact (or not at all)
  • The team is not tracking or managing to key project milestones

Cost Management

  • Financial tracking and reporting tools are cumbersome and time consuming
  • Creating purchase orders and statements of work frequently delay project work
  • Multiple layers of management are required to approve invoices for work that has been acknowledged as delivered by the project team
  • Actual effort is not captured
  • Vendor invoices are approved and paid without confirmation that the required work was performed
  • Vendor invoices are approved and paid outside the scope of the project management processes
  • Variances are discovered after the cost has been incurred
  • There is no accountability for actual effort or cost compared to the amount budgeted

Project Communications

  • The project status report is more than 2 pages
  • Multiple project status reports are prepared (for different stakeholder groups)
  • Team meetings consume more than 10% of the time spent on a project
  • Team meetings are redundant in nature (same topics discussed with multiple audiences)
  • Stakeholders are not sure how to obtain the latest project status
  • The core team does not regularly communicate as a group
  • The project sponsors are not provided project updates on a routine basis


How to strike the right balance

Striking the right balance to implement effective and efficient processes for your project involves a combination of leveraging the process assets of the project office, and tailoring the processes to meet the specific needs of the project. The specific needs of the project area determined based upon the size (people, costs, duration) and complexity (internal and external dependencies) of the project. The investment in each of the process areas should be appropriate based upon the potential impact on the project. Does the process add value to the project execution, or add unnecessary overhead?

Striking the right balance from project to project becomes more effective within the project organization when critical processes are documented in a usable and accessible format, and consistently leveraged by project managers to create the “right” processes for each project. The tailoring of project management processes represents a key component of the practical application of best practices for successful project delivery. The more ingrained these best practices are in the project management culture, the lower the dependency on the talents and heroic efforts of individual project managers.

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.

%d bloggers like this: