PM-Foundations – Organizing Your WBS

Creating a well-organized Work Breakdown Structure (WBS) is always on my list of “critical few” project management best practice areas. The WBS is utilized to effectively define the scope of the project, decomposing the work down into components that can be estimated, scheduled, and tracked/controlled throughout the project life cycle. The WBS makes the scope of the project actionable in the form of a deliverable oriented and hierarchical view of the work. The WBS defines the scope of the project down to the lowest level deliverables called work packages.

One of the most common questions I get when discussing the WBS with project teams is, “What is the best way to organize the project deliverables?” A lot of people think the answer must be obvious, because it does not seem to get discussed much by the team when the WBS takes its initial shape / form. It is not at all a stupid question. There are two very different ways that team members think about the project. One way of thinking about the project is focused on the product that is being created, and the other perspective is based upon how the project work will be completed. Selecting one school of thought over the other will drive a totally different end result in terms of the organization of the WBS. As the project manager, you have to live with the organization of your WBS throughout the project life cycle (it drives the organization of the project schedule, as well as the monitoring / controlling processes), therefore you want to be sure you have purposefully selected an organization approach that works for the project team.

Product Based WBS Organization

For those of us with experience in a manufacturing environment, you are familiar with the concept of the bill of material. The bill of material describes how to build a product from the end product down to the lowest level parts or components. The bill of material is utilized to manage building products in a repeatable, efficient, and cost effective manner (automated utilizing an ERP system). When designing or developing a new product, the bill of material is a logical manner to organize the work that needs to be completed. For product development type projects, organizing the WBS in this manner helps the team think about and visualize whether or not they have effectively accounted for and planned all aspects of the product. This approach also provides an understanding of how different aspects of the product are coming together as the product development effort progresses.

Benefits

Downside

  • Provides the ability to trace the components of the product down to the lowest level sub-components
  • Improves the visibility of the current status of product components (particularly important when working with suppliers)
  • Engineers relate well to the WBS organization structure
  • The WBS is not organized from “beginning to end” of the project life cycle
  • Top levels of the WBS remain open until the end of the project
  • Non-product related deliverables do not fit well in the WBS (unless they are define as part of product’s the bill of material structure)

Project Based WBS Organization

As a project manager, I generally think about the project effort in terms of how the work is going to be completed (based upon the timing and dependencies associated with deliverables). With this approach the work is grouped into work streams (sub-projects), and project phases (defined with major milestones). As you get into lower levels of the WBS the organization of deliverables is based upon the different components of the project or product. This approach allows the project manager to update the project “from top to bottom” as the project progresses (assuming the project progresses in pretty much the same manner as it was planned).

Benefits

Downside

  • The “flow” of the WBS relates closely to the way project work will be completed
  • As work is completed, components of the WBS can be “closed”
  • Generally, easier for project managers to update progress
  • Difficult to utilize the WBS to obtain/communicate the “bill of materials” relating to the product
  • Difficult to highlight the status of specific product components
  • Engineers may struggle with understanding the schedule (and often complain about it)

 

What is the Best Fit for My Project?

There are good reasons to organize your WBS from both the product and project perspective. Below are several factors to take into consideration when you are working with your team to determine the best approach for organizing your WBS.

  • Standalone vs. Dependent Work Efforts – Where are the majority of the dependencies and interrelationships within the separate work efforts? Are the dependencies more focused on the product components or the phases of the project? Are the project milestones tied to the product components or gates in the project life cycle? It is much easier to manage dependencies in a vertical manner within a single work stream, rather than in a horizontal manner across multiple work streams.
  • Wide vs. Deep – Based upon my experience, it is much easier to manage a project that has a WBS that is deeper (vertical) than it is wide (horizontal). Part of this preference goes back to the fact that it is easier to manage dependencies within a single work stream (vs. across work streams). However, I also find that it is easier to manage and measure progress of the overall project (solution) if there are fewer separate work streams that link directly to the highest level of the WBS (the over solution / project summary). For example, if there are 15 major product components associated with your project, with significant dependencies across the components, you should have a good case for organizing the WBS around the project life cycle.
  • Who Cares? – Who are going to be the major consumers of the information maintained within the WBS and the project schedule? Is the effort more product or project focused? If it is a very product focused effort, largely comprised of a team of engineers, you may be fighting an uphill battle to suggest that the WBS should be organized based upon the project phases.
  • What Does Progress Look Like? – How will you be receiving updates on project progress? Will progress updates be organized around separate product related work efforts, or based upon the project phases and upcoming project milestones? Again, the answer to these questions will be largely dependent upon the composition and focus of your project team.
  • Iterative Implications – When the team makes the decision to deliver the project in an iterative manner, they are making the decision that the WBS needs to be organized around the iterations. Iterations are time based, and therefore the WBS takes on a project based organization structure (with the project phases being the individual iterations and milestones for deployments).
  • Either approach will work – As you can tell from my analysis above, I am a project manager and obviously favor one approach over the other. The bottom line is, either approach can work for you and the project team. I can honestly say that some of my most successful project were managed with a product based WBS. In some cases additional steps are required in the WBS definition, and schedule set-up to provide views of the schedule / status from both a product and project perspective. This can be accomplished in MS Project by creating custom fields and special views (using sort and filter functions with the custom fields).

Using MS Project to Set-up your Project for Success

Project managers that are not as familiar with using tools like MS Project to create a project schedule often “dive in head first” creating their project schedule. These project managers open a new file, start furiously loading project tasks, and the project schedule evolves as project planning progresses. After the project schedule baseline is established, and project execution begins, these project managers begin the weekly battle to maintain the project schedule in a manner that keeps it close to reflecting reality. Some of the telltale signs that your schedule is difficult to maintain include:

  • You change the dependency on a task and the dates do not change
  • You extend the duration and the work hours do not change
  • You add a new resource and the dates change unexpectedly
  • Your schedule shows people working on Thanksgiving and Christmas
  • Durations are displayed in hours, and work is displayed in minutes

I was working with a project manager whose schedule had become so difficult to maintain that he declared that his “tool had become compromised”. This created much frustration for the project manager, but the even worse result was that he was not sure that the milestone commitments established in the schedule were correct or achievable (and he did not know how to fix it).

Obviously, how well the WBS is organized has a significant impact on the ability to effectively and efficiently maintain the schedule throughout the project life cycle. In addition, there are several set-up activities within MS Project that allow the project manager to tailor the project schedule to meet their needs. Paying attention to these set-up activities when the project is first created allows you to better understand and control the behaviors within the schedule as you update the project schedule to reflect progress. The set-up tips described below include defining the project start date and project calendar, establishing default schedule options, and entering your project resources.

Defining Project Information

The first MS Project set-up feature I look at is Project Information. This feature establishes the start date for the project. This feature is also utilized to link the default project calendar to the project. If you are using MS Project Server, the project office has most likely established predefined project calendars. When using MS Project 2010, I generally start with the standard project calendar (see below for setting up the project calendar).

Setting up the Project Calendar

One of the most embarrassing things during a schedule review is when someone points out that you have scheduled resources to work on a holiday. That is why it is a best practice to early on tailor the calendar to accurately reflect your project environment. The project calendar is accessed from the function “Change Working Time”. This function provides the ability define non-working days (e.g., holidays). Again, if you are using MS Project Server, the non-working days are likely predefined on the project calendar you selected from the server configuration.

Setting up Schedule Defaults

One of the most important MS Project set-up functions (and also one of the most commonly overlooked) is Project Options. The Project Options lets you tailor many features based upon your personal preference, but the Schedule Options contains settings that will impact the day-to-day behavior within your project schedule. There are two primary components of the Schedule Options:

  • Calendar Options: These setting are used to define the work week (start and end of the week, hours / day, hours / week, and start and end of the work day). The calendar options may also be configured for specific project calendars.
  • Scheduling Default Settings: These options are utilized to define default settings associated with new tasks. I always recommend that durations are set-up as “days”, and work is set-up as “hours”. Unless there are special circumstances associated with your schedule, these are the most logic units of measure for managing the timeline and work effort. If you are creating a resource loaded project schedule, you should set up new tasks as effort driven. The option that seems to be confusing to project managers is the “task type”. The “task type” is utilized to define which task elements are updated when another element is updated (duration, hours, and resource unit allocations). The table below helps illustrate the update behavior associated with the different “task type” options. My personal preference is “fixed duration”. This option allows you to effectively control / manage the timeline (duration) when making updates to the schedule.

Note: Units refers to the % that a resource is allocated to the task. Fixed duration locks in the timeline and recalculates either units or work.

Defining Resources

Before getting too far into creating the schedule, it is important to define your resource pool in an organized manner. The following are the key elements associated with the resource pool:

  • Name – Use the standard naming convention for loading names in the schedule. It is important to be consistent.
  • Initials – Allows you to abbreviate the resource names for viewing in the schedule (takes up less space on specific views)
  • Group – Allows you to group the resources in a logical manner, either by organization or resource grouping. I generally use this field to define the different type of resources assigned to the project (e.g., project manager, business analyst, developer, QA).
  • Std. Rate – Defines the cost / hour for the resource. This is a key element for project budgeting purposes.
  • Max Units – Defines to what level the resource is working on the project. This is a key element used for resource leveling purposes.
  • Base Calendar – Establishes the working calendar that is used for this resource (may have specific resources with different work times).

If you are using MS Project Server to load projects into your project schedule, you select project resources associated with your project from the Global Resource Pool (vs. entering resources to create the project resource pool).

Note: This is a bit of a milestone on my blog – my 50th post. Hope you enjoy the content as much as I do creating it.

PM-Foundations – Creating an Effective Statement of Work (SOW)

Having spent many years on both sides of the table (client and consultant), I have a pretty balanced perspective of what makes partnerships work well. Most importantly I have seen my share of success and challenges as a result of bad client – vendor relationships. These bad relationships are often the source of less optimal project outcomes, or at a minimum the reason the team had to “win ugly”.

I have a firm belief that the quality of the partnership, and the resulting project outcomes, start right up-front when the agreement between the client and vendor is created. The goal of this agreement is to define the products / services the vendor will provide that will satisfy the client’s needs, and how the vendor will be fairly compensated for the products / services delivered. Problems with the agreement can result in a client not getting what they need, or a vendor not getting fairly compensated for what they delivered. Here are a couple scenarios that help illustrate this point:

Scenario 1: The Unhappy Client

The client sends out a Request for Proposal (RFP) to create a new web site. The client has definite ideas in mind in terms of what the new web site needs to look like and do to drive the desired benefits to the organization. The vendor expresses that this project should be pretty straightforward and they provide the lowest time and cost estimates. They are awarded the engagement largely based upon these estimates. As the project progresses, the vendor expresses that there are more requirements / complexities associated with the solution than originally defined in the SOW. Many change orders ensue and the project slips. Finally, the project is completed, but the client had to forgo certain desired features, paid more than planned, and went “live” with the solution much after the original management commitments. This is not a happy client.

Scenario 2: The Damaged Vendor

The vendor provides a proposal to develop a collaboration portal for their client. The client says that they really want to do business with the vendor, but they do not have funding for the amount proposed. The client convinces the vendor that they can “cut some corners” in a couple areas to meet the desired cost of the engagement. As work progresses, client stakeholders keep pushing for doing things “the right way”, and in the spirit of maintaining a positive relationship the vendor performs much of the work originally proposed. The project is delivered successfully, but not without much pain and additional effort on the part of the vendor.

The processes utilized to create and approve the Statement of Work (SOW) can help both parties establish a strong partnership and achieve positive project outcomes. My insights on this topic are not all about introducing overhead and bureaucracy to crank out an “iron clad” contract, but rather how the client and vendor can work collaboratively to create an agreement that sets up both parties for success (the overused term for this is creating “win-win” situation).

6 Tips on Creating an Effective SOW

1. Understanding of the Problem – In my opinion the most important element of creating a strong agreement is ensuring that the problem to be solved is well understood by all parties involved. Adequate effort must be invested in the client describing the problem, the vendor performing discovery to understand the problem and associated requirements, and the vendor describing their approach to solve the problem. Many of my experiences with bad client – vendor relationships can be traced back to when this process was not completed well. I believe that vendors can consistently separate themselves from the competition by taking the extra steps required to understand the client problem, and effectively articulate their proposed approach to solve the problem.

2. Creating an Acceptable Delivery Approach – The processes and tools the vendor will use to deliver the solution must be compatible with client processes and tools (e.g. SDLC, project management tool). In addition, the approach must be one that the vendor is comfortable using to successfully deliver the solution. If there are specific processes or tools that are critical to compliance with client methodologies, they should be understood and specified in the SOW.

3. Establishing Realistic Estimates & Targets – Both parties must be comfortable with the effort and timelines defined in the SOW. Agreeing to estimates or dates that are not reasonable or achievable will lead to problems in the project delivery process. One of my favorite statements is “the work is what it is, and just saying it will be so does not make it so”. If there are specific concerns about the estimates or timelines, it is much easier to discuss and resolve the issues before the work has started, rather than after a significant problem is encountered during the project delivery process.

4. Defining Roles & Responsibilities – Many agreements fall short in the area of defining roles and responsibilities. Vendors do a decent job of describing the resources that they will require to deliver the solution, but they do not spend as much energy on describing client resource requirements. I think it is most effective to describe the client roles and responsibilities in the context of a RACI Chart, and highlight deliverables that the client is responsible for or is making significant contributions to. In addition, it is important to highlight specific resources or skill sets that will be required to complete key deliverables.

5. Minimizing Assumptions – Assumptions are often overused in an agreement to try to protect a party against negative situations. My experience is that these assumptions are forgotten the moment the SOW is signed, and they can become a source of contention during the project delivery process. The classic “CYA” assumption found in many SOWs is “the vendor will have timely access to client resources to define requirements and approve deliverables.” First of all this statement is not actionable, and secondly it is not helpful to successful project delivery. If there are areas of concern, work together to address the issues in an actionable manner either within the definition scope of the engagement or the project delivery approach.

6. Accounting for Progressive Elaboration – Almost all agreements involve “unknowns”. The SOW must accommodate how the unknown will be turned into a known, as well as how project plans will be adjusted throughout the project delivery process. The most common way (but not necessarily the best way) that agreements account for unknowns is through the description of the change order process. A change order process is required when an unknown is not described in the SOW, and requires additional work when it is discovered in the project delivery process. However, many unknowns are associated with clarifications required (vs. change) during the project delivery process and these situations are best accommodated by reflecting iterations in the delivery approach to confirm and adjust plans accordingly.

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.

 

 

 

 

5 Tips to Use SharePoint KPIs to Measure Project Performance

Many project teams spend time talking about project metrics up-front, but then have weak follow-through on actual implementation of the metrics. The one metric tracked within most project offices is the overall status (Green, Yellow, Red), but even then it is often times not supported by factual project performance data. There is data captured throughout the project life cycle that can be presented to provide a better picture of overall project performance.

SharePoint 2010 provides features that enable project teams to expose project data in the form of easy to consume project metrics. The Status List in SharePoint is used to implement project metrics on your project site that are updated as project data is maintained throughout the project life cycle. As with any tool, the hard work lies in defining the metrics and business rules, not adding the metrics to the Status List. This blog provides several tactical tips on how to use the SharePoint Status List to implement project metrics that help measure and improve project performance.

5 Tips to Create Meaningful SharePoint Key Performance Indicators (KPIs)

The following represent several “how to” type tips for creating project metrics within a Status List on your SharePoint 2010 project site.

1. Define what to measure – In many cases the project office will have established standards or guidelines around project metrics utilized to measure project performance. As with all project management best practices you want to select the critical few metrics that will make the biggest impact on project performance. In addition, it is best to focus on metrics that can be produced as a by-product of the project information required to effectively manage the project. I focus on the following best practices areas from a measurement perspective:

  • Schedule Performance – This metric can be derived from the project schedule using earned value, or based upon the schedule variance on key milestones (as a percent of the total duration for the milestone).
  • Cost Performance – This metric is best calculated from the project budget information, either using earned value or based upon budget variance (be careful with budget variances that do not take into consideration some flavor of earned value in the estimate to completion (ETC) calculation).
  • Impact of Change – What impact has approved changes had on the schedule and cost performance of the project? This metric should come straight from the project change control tracking tool.
  • Risks and Issues – This metric is utilized to project the potential impact of high risks and issues on the future performance. This metrics should also be a fairly straight forward extract from the risk and issue tracking tool.
  • Overall Project Status – Some project offices calculate the overall project status (Green, Yellow, or Red) as an aggregate of other project metrics. In most cases, I find it most effective for the project manager to assign the status during the weekly status process as a reflection of the cost and schedule performance, and in the overall health of the project (including trending of the project’s risk profile).

2. Establish the data source – Once you have defined the project metrics, you need to establish the source of the data that will be utilized to update the metric within you SharePoint Status List. The two sources that I utilize are Excel Spreadsheets stored in the document library on your project site (e.g., Cost Performance or Schedule Performance), and a SharePoint List utilized to track specific project information on your project site (e.g., Risks/Issue and Change Control).

  • Excel as the Source – There are a couple steps required to expose data from Excel spreadsheets within the KPI. As previously mentioned the first step is to save the spreadsheet within a document library on your project site. The second step is to utilize the name manager function within Excel to identify the specific cell or range of cells that will be accessed from SharePoint.

Excel’s Name Manager utilized to identify the specific cells to be accessed by SharePoint.


Establish the location and named area when setting up the KPI in the Status List.

  • SharePoint List as the Source – If the information for the KPI is maintained within a SharePoint list, you select the specific list and view (I discuss list views under point #4) from the Site Content displayed.

Select the SharePoint List and View when setting up the KPI in the Status List.

3. Define the parameters – After identifying the source of the data for the KPI, you need to define the parameters that establish the assignment of the metric rating (Green, Yellow, Red). First, establish whether “higher” or “lower than the target value is better for the KPI. Then specify how to determine if the metric is Green, Yellow, or Red.

  • Excel as the Source – The definition of the targets of Green and Yellow are maintained within the Excel Spreadsheet, and you specify these fields (as Named Areas) when setting up the parameters for the KPI. In this example the values in the spreadsheet contain earned value targets for Green (1.0) and Yellow (.90).

  • SharePoint List as the Source – You have options on how to define the KPI from a SharePoint list. It can be based upon a count of the items in the List View, or calculated based a specific field in the List. In the example below the schedule impact was defined based upon the sum of the schedule impact field in the approved change request view of the Change Request Tracking List. In this example the KPI is GREEN if equal to or lower than 10 days total impact, and YELLOW if less than or equal to 20 days (and RED if over 20 days).

4. Create the List Views – When using SharePoint Lists as a source of KPIs in the Status List, you must make sure the List Views are established that support the KPI. This point is best explained with the example below.

  • Impact of Change – If the metric is utilized to communicate the impact of approved change requests on the Schedule, the List View must be filtered to only include changes with “Approved” status. In addition, the view must include any fields that will be utilized to compute the KPI (in this case “Sched Impact” field).

5. Use the Metrics – Now that you have gone to all of the effort to create the project metrics on your project site, make sure you use them to effectively and proactively manage your project. You should understand what caused a KPI to change from GREEN to YELLOW or RED (e.g., a new High Risk, or a slippage in the schedule), and initiate the corrective actions required to move the KPI back to GREEN. In addition, I find it a best practice to include these KPIs in your project status report, as well as corrective actions for YELLOW and RED metrics. Use of the SharePoint Status List to measure and communicate project performance also enables the ability to produce an on-demand / on-line project status report.

PM-Foundations – What Makes Projects FUN?

If you have read several of my blogs, hopefully you have picked up on the fact that I am sincerely passionate about project delivery. I am always energized and motivated when a project delivers tangible benefits to an organization. I like project work so much that it spills over into my personal life. It is personally satisfying to evaluate the “before” and “after” on a home project – even if it is something as simple as planting a garden, painting a room, or cutting the grass. So what is it about projects that people enjoy? There must be something there, because people actually volunteer and/or seek out opportunities to be assigned to a project team.

The intent of this post is to prompt some thoughts on the positive aspects of project work, and what you as the project manager can do to enhance team members’ experiences on a project.

What is fun about projects?

These are several of the aspects of project work that is inherently fun and rewarding for project team members.

  • Sense of accomplishment – There is a definite sense of accomplishment when a deliverable is completed, a milestone is achieved, or project is closed. When a project is closed you can observe benefits realized by the organization as a result of the team’s efforts. When a milestone is achieved you move on to a new phase in the project. In contrast, when you complete operational work, there is another “stack” of the same type of work right behind it, with no apparent end in sight.
  • Something Different – Projects provide opportunities for team members to be exposed to new technologies, business processes, and problems to solve. Exposure to new areas represents huge opportunities for team members to learn and develop both personally and professionally. For those of us that thrive on continuous learning, there is nothing better than being assigned to a new client or project.
  • Involves People – Small projects can be delivered by an individual, but the vast majority of projects involve a team of people assigned to accomplish a common goal. The people assigned to the project bring with them a diverse range of talents, experiences and perspectives/ideas. It is this diversity that ensures that the team’s unified efforts are much greater than the sum of its individual contributions. Assembling a diverse group of people as a new project team can be challenging (forming and storming) but it is ultimately very rewarding as the team starts to work well together (norming and performing). I personally find the broad spectrum of people I meet and work with during projects to be the most amazing element of being a project leader.
  • Recognition – All projects have a certain amount of visibility in the organization, otherwise the resources would not be assigned to it. With visibility comes recognition and potentially rewards when milestones are achieved and projects are successfully completed. Visibility can also result in negative consequences when projects are challenged or fail. Based upon my experiences there is far more upside potential associated with positive project outcomes, than risk of negative consequences associated with challenges or failures.
  • Projects End – By definition projects have a beginning and end. Admittedly, some projects are not as enjoyable as others, but at some point they all will come to an end (some more naturally than others). With the knowledge that the project will end, even the worst of projects can have their moments.

6 Ways Project Managers Can Make Projects More Fun

As a project manager, there are a number of things that you can do to establish a positive project environment – one that team members actually enjoy being a part of. These 6 tips are a combination of applying effective leadership skills, and implementing practical techniques to enhance the project environment. My experience has led me to the conclusion that in most cases creating a positive project environment translates into building a more productive and effective project team.

1. Focus on Teamwork – I spend a lot of time making sure the project team understands they are a team working towards a common objective, and not a bunch of individuals assigned to a project. Establishing a group that works as a team starts with making sure the team understands what we are trying to accomplish, and what success looks like. It also includes ensuring that everyone has internalized what their role is on the team, and how their role connects with the success of the overall project. There are things you can do to make sure the group feels like a team. Schedule regular team interactions (team meetings), provide meaningful project updates, and promote collaboration / interaction. Unless this group has worked together before, it takes some real work and focus on your part to make the group feel and interact like a team. Do not be discourage or give up as the team traverses through the forming and storming phases of creating a team. Your leadership can make a significant difference in terms of how the team works together.

2. Be Enthusiastic – Assuming you are like me, and really enjoy project work, make sure the team knows it. You need to consistently model the attitude and enthusiasm you want the team to feel throughout the project. If the project manager does not believe the team can be successful, who does? It is amazing how quickly the team will get discouraged when you display negative vibes about the project either verbally or non-verbally. The easiest way for me to model a positive and enthusiastic attitude during team interactions is to make sure I really do feel that way. When faced with difficult tasks or people, I remind myself what I enjoy about the challenge the project is providing, the team I am working with, and the opportunity to learn something new. This is a critical tip – do not ignore it.

3. Track & Communicate Priorities – This one sounds pretty straightforward, but it is amazing how quickly team members can get “lost in the weeds” or “in a funk” without timely and relevant information about the project. Team members must understand the team’s top priorities, and how these priorities tie to their individual work assignments. Priorities include upcoming milestones, task assignments, action items from team meetings, as well as high impact issues and risks. I try to keep this information simple and easy to consume / internalize – What did we accomplish last week? Where should we focus next week? What roadblocks need to be removed?

4. “Stretch” the Talent – As the team is forming, it is important to get to know the individual team members. Not only do you need to understand their strengths and weaknesses, but also what are the things that motivate and energize them. If you have insights into team member’s professional development path, you can help align work with the areas where they have talents, are excited about, and/or desire to learn. Aligning work and responsibilities in a manner that gives people a chance to “step up” on the team goes on a long ways towards building a highly motivated team that delivers positive results. The opportunities on the team can be both in the form of specific work assignments, as well as roles (e.g., facilitation of team meetings, coordination of team events).

5. Purposeful Recognition – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team. When given the choice of recognizing an individual or a group effort, I generally opt for recognition of the group (sends the right message as a team, and ensures you do not unintentionally leave someone “off the list”).

6. Close the Project – When you have come this far with the team, do not forget to bring appropriate closure to the effort. Effectively facilitating the lessons learned process helps the team reflect on what was accomplished, how it was accomplished, and what would the team do differently on the next project. This is the opportunity for the team to have a real impact on how projects are completed within your organization in the form of implementing continuous improvement actions. The other important element of project closure is celebrating success. Facilitate a project celebration that helps team members feel good about was accomplished before they rush off to their next assignment.

PM-Foundations – Managing Your Project Issues

To me the most annoying, and sometimes the most disruptive type of project churn is issue related churn. Open issues distract team members from the work at hand, and often slow progress to achieve project milestones. At its worse, more time can be spent talking about issues than project work. If the rate of identifying issues outpaces closing them, the project can be overwhelmed with issues. Projects are paralyzed by project issues when team members cannot complete tasks/deliverables because they are awaiting resolution of project 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.

Hopefully this blog gets you thinking about how to identify when issues are negatively impacting your project, and what you can do to get them under control. Issues are not a bad thing, as long as you are able to manage them, and not vice versa.

How Do Issues Overwhelm Projects?

Here are some of the common indications that issues may be overwhelming your project, or at minimum impeding progress.

  • Too many – The obvious indication of issue related churn is the number of open issues — especially if there are a significant number marked “high” priority. When there are so many issues that you do not know where to start to get them under control, you probably have too many. When the number of issues becomes significant, you start to see processes like “triage” introduced to identify the ones that “really matter”.
  • They bounce around – Some project teams do not seem to close issues, they just reassign them to someone who needs to have another meeting to discuss the issue. A good way to identify the inability to effectively close issues is to look at the history associated with the issues. When issues are owned by multiple people, and the source of multiple meetings, the team is probably not focusing on the right actions required to close the issue.
  • They keep coming back – One of the most annoying aspects of issue related churn is when closed issues are reopened. This occurs if the either the right people were not involved, or the correct actions were not taken to close the original issue. When this happens multiple times on a project I am not sure if I am more upset with the person that reopens the issues, or the person that did not close it properly in the first place.
  • They appear out of nowhere – Often times an issues is raised that makes you wonder, “I wonder why that was not raised before now?” The earlier a potential problem is identified in the project life cycle, the easier and less costly it is to resolve. Therefore, as issues are identified late in the project, the more disruptive issue resolution becomes. As the project manager, you need to strike a good balance between aggressively managing issue resolution and encouraging team members to identify them. The last thing you want is to have team members keep issues to themselves because they think it will be viewed as a “bad thing” to raise a new issue.

6 Tips to Managing Your Project Issues

  1. Capture – My first tip is pretty obvious. Make sure that as issues are identified they are captured. This means that processes and tools must be established early on in the project to enable identification and tracking of issues. In addition, it is important as the project manager to create an environment where people feel “safe” to raise an issue. Having said that, I do encourage the team to be thinking about ways to address the issue at the time they raise it. The old adage “if you are not part of the solution, you are part of the problem” definitely describes some team members.
  2. Accountability – In my opinion the most important element of effectively managing issues is establishing a single person that truly feels accountable for resolving the issue. Issues are best assigned to people that have something “at stake” in the outcome of resolving the issue. The issues should either have an impact on the component of the project they are responsible for, or have an impact on the component of the product they are responsible for.
  3. Action – When team members are providing updates on issues, the focus should be on what actions have been identified to close the issue. I do not necessarily consider “we have a meeting set up to discuss this issue” to be a very effective next step. The more appropriate action items are focused on what decisions need to be made, analysis performed, or requirements defined to determine how to move forward and resolve the issue.
  4. Measure – As is the case in most project management processes, it is important to have the appropriate metrics in place to manage issues. To establish a high degree of focus and sense of urgency, I prefer to measure and communicate high priority issues in the form of absolute numbers. Metrics like net change and average age are best managed through trend analysis. In addition, it is important to keep track of the overall impact of issues on the project. This metric can be tracked within the change control process.
  5. Close – Ensure that the issue management process includes a step to validate that the issue is actually closed. This step can be as simple as a quick review of the recently closed issues in your core team meetings. It is important that team members agree that the appropriate actions have been taken to permanently solve the problem.
  6. Timeout – If an issue, a group of issues, or the issues in aggregate are truly overwhelming your project it is sometimes appropriate to bite the bullet and call a timeout. This happens when issues are causing the project to miss significant milestones, and corrective actions are not in place to formalize the impact and get the project “back on track”. During the timeout, focused effort should be placed on resolving the high impact issues, reducing the overall number of issues, formalizing the impact of the issues, and rebaselining the plan. I also recommend a quick lessons learned process to identify the source of the problems, and adjustments required to prevent the project team returning to the same place during a future phase of the project.

4 Tips to Using SharePoint Lists to Improve Project Delivery

A SharePoint list represents a great tool to capture and maintain project information in a very structured manner. In addition, the information maintained in the list is more accessible to the team than information maintained “off-line” in tools such as Excel. The most powerful aspect of creating SharePoint lists to enable project delivery processes is that the data captured and displayed in the list can be tailored to meet the specific needs of your project environment by YOU. Creating and maintaining SharePoint lists requires an understanding of how to manage your project site, but does not require deep technical skills (I am your average technical project manager – not a SharePoint architect).

Since I receive so many comments and questions on my blog about how to create and maintain SharePoint lists, I decided to write a blog post that provides more tactical information about how to use SharePoint lists to meet the specific needs of your project. This post provides four pretty basic tips about creating and using SharePoint lists in a manner that makes your project teams more effective or efficient.

TIP #1: Custom vs. Standard Lists

In many of my SharePoint blogs I talk about “starting from a custom list”. The term “custom list” tends to scare people because they relate the term to customization (e.g., requires a programmer to perform the function). Selecting a “custom list” as your starting point just means that you are starting from a blank list that you can add your own columns and views to. SharePoint provides several different preconfigured list templates to use as the starting point to create a new list. I use the following standard SharePoint lists on my project sites to support specific project delivery functions:

  • Contacts – Great for the project team roster. I usually add columns to identify team members that are on the core team and the steering committee.
  • Tasks – This list is best for tracking action items within your project meeting workspaces.
  • Issue Tracking – I tailor this list to track risks and issues (my post on risks and issues provides a lot of detail on this list type).
  • Status List – This is a very unique list that is used to define and display project metrics (my post on measuring project performance provides more details on this type of list).
  • Links – This list is used to provide links to project resources (external or internal sites that are directly or indirectly applicable to your project work).

There are several project processes that I find it easier to start from a blank list than a predefined list available within SharePoint. The roles and responsibilities (RACI), change request tracking, and milestone tracking are all examples of lists that are unique to project delivery best practices, and best to create from a custom list and add the columns required to support the specific process.

TIP #2: Streamlining Data Capture Process

You want to make it as easy as possible for team members to add and update information in the list. The most important aspect of making a list easy to use is that you capture the data that is relevant to the process (and only the data that is relevant to the process). If there are columns in the standard SharePoint list that are not relevant to your specific process, delete them. In addition, it is helpful to order the columns in a sequence that is logical and meaningful to your project teams.

The other aspect of making it easy for project teams to use the list is minimizing the amount of information they are required to type into the form. There are specific column types available that ensure that data is captured in a consistent manner, and reduces the amount of “free form” data entered into the form.

Choices: Provides the ability to capture information from a predefined list of options (using a drop down, radio buttons, or checkboxes). This is used when you want to control the values that are entered by team members. Below is an example of the use of a “choice” type column to capture project phases.

Look-up: The look-up feature is used to access information maintained in a specific field in another list. In this example below, I created a list for project roles and access the list to select the project role within the roles and responsibilities list.

Below is another example of using the look-up feature. I am accessing the project team roster list to assign the specific person within the roles and responsibilities list. In this example, I selected the option to allow multiple values to be selected, providing the ability for multiple team members to be assigned to the deliverable.

Date: For date related information (e.g., completion date, target date, due date), utilize the date and time column type. I will generally set-up the field to capture only the date.


Calculated: Calculations can be used to derive values within the list from other columns maintained in the list. This function is commonly used with dates maintained in the list (e.g., number of days past due). In this example, I use the feature to calculate the overall risk ranking by multiplying the probability times the magnitude (impact) for the risk.


TIP #3: Using Views to Target Stakeholders

Views represent the “window” into the information maintained in your list. It is important to create views that provide the information required for specific stakeholder groups. What your core team member needs to review and update risks on an on-going basis, is different than what your sponsor needs to understand the project’s overall risk profile. The first consideration for creating views for target audiences is related to the columns that are displayed within the view. When creating a view you can select the columns to be displayed, as well as the order in which they are displayed.

SharePoint provides several other features to tailor the list view to meet the needs of your target audience. Below are the features that I utilize the most frequently.

Filtering: This feature provides the ability to limit the items displayed based upon specific columns values. I will frequently utilize filtering to limit the items displayed to “active” or “high priority” items.


Sorting: This feature provides the ability to define the sequence that list items are displayed within the view (providing a primary and secondary sort).


Totals: This feature provides the ability to show a count of list items within the view, or display the sum of specific columns within the view.

TIP #4: Use of Templates

It is a best practice to tailor lists to meet the needs of your project environment “one time”, and then save your new list as a template. As a new project is initiated, you access your organization’s project templates to create the new project site. The definition and creation of templates makes it very easy to create project sites that are preconfigured to meet the needs of your project environment, and also ensures that your project management best practices are enabled in a consistent manner from project to project. Some organizations allow project teams to modify the lists based upon the needs of their specific project, but most organizations “lock down” the templates to limit the project specific tailoring to modifying values captured within columns (and not adding or deleting columns within the list). In addition, a standard set of list views is saved with the template, but most organizations allow project teams to create and modify views to meet their team’s needs.

Within the list settings for the specific list, you will find the ability to save the list as a template.

Below is an example of the information captured when you save a list as a template. Note that you have the ability to save the list with or without the list content. This feature provides the ability to create a template from a project site that is already using the list.

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.