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).
Advertisements

PM Foundations – Updating Schedule Progress

It always amazes me that after project managers put so much time and effort into creating a baseline project schedule, they do not always put the same level of energy and discipline into maintaining it during the execution phase of the project. It is extremely important during this phase of the project that the schedule reflects where you are at currently, as well as how the remaining work is planned to be completed.

During the transition from planning to execution the project manager establishes the progress update processes. These processes are both formal (e.g., submitting updates through a tool) and informal (e.g., soliciting input in one-on-one meetings). A productive project manager will ensure that these update processes are linked to other project related activities, such as time reporting, team meetings, and status reporting.

Progress Update Processes

The progress update processes and tools should fit into the way the team works. Try to avoid implementing processes that are disruptive or redundant. You do not want these processes to end up getting in the way of actual work being completed. In addition, these processes should be timely and consistent. The updates should be completed the same time/date during the reporting period (day/week). Team members should KNOW when information is due and when the schedule updates have been completed.

Based upon the organization and work environment, the project manager either establishes formal or informal processes and tools to collect progress updates. These processes and tools can range from weekly conversations with team members, to utilization of a tool for each team member to submit updates.

The key to this process is that it is linked to other project update activities (timeliness of information is dependent update establishing efficient processes):

  • Time reporting – Usually time reporting is at a higher level than required to update schedule activities, but at a minimum this process can be leveraged to trigger schedule update discussions.
  • Team meetings – Information shared at team meetings should be direct inputs for schedule updates (particularly on smaller projects).
  • Status reporting – It is up to the project manager to ensure that the status report is completed after schedule updates have been completed.

Performing Schedule Analysis

After completing progress updates to the schedule, it is a best practice to review the schedule data in a manner that proactively identifies potential issues. This review is utilized to identify areas where additional information and/or adjustments are required.

I will generally utilize the MS Project feature AUTO-FILTER feature to highlight potential project related issues. The approach helps focus in on specific problem areas:

  • Tasks that are NOT completed
  • Tasks that should have been started or finished already (past due), OR tasks that are scheduled to start or finish in the upcoming 1-2 weeks
  • Task assignments for specific resources (identification of resources that may be over or under allocated in the current time period

As the project manager you should be asking yourself the following questions when reviewing schedule related information:

Why are tasks past due? Most likely you will have run across the answer to this question when gathering progress updates from team members. If not, this is a good opportunity to follow-up with team members on the status of specific tasks. The answer generally falls into one of the following categories:

  • The task is taking longer than expected
  • Other tasks took higher priority
  • I could not start the task because I need another task to be completed first

Are actions required? Based upon review of past due tasks, as well as other tasks scheduled for the upcoming 1-2 weeks, you may identify problem areas that require immediate action. This is particularly true if delays (or anticipated delays) in the tasks will impact an upcoming milestone (or the project end date). Based upon discussions with the team, you may decide that one of the following actions must be taken:

  • Change resource assignments
  • Add a risk and initiate mitigation action planning
  • Change task dependencies to reflect new task sequencing
  • Add a task to reflect new work

Are schedule adjustments required? Some follow-up actions drive additional updates to the schedule. The bottom-line is that if the schedule no longer reflects how work will be performed, you should likely make additional updates to the schedule.

Making the Right Adjustments

Based upon completion of on-going schedule analysis, including follow-up research and discussion with team members, you will often identify adjustments that need to be made to one of the planning artifacts (schedule, issue / risk log, project management plan). The following represent considerations when making common adjustments to the schedule:

Resource assignments: Resource assignments may be proactive resource changes to avoid future problems, or reactive changes to respond to slippage in the project schedule. If material in nature, the resource changes should be made in the schedule. After the changes are completed, the project manager should review the resource usage to ensure that the changes solved the resource utilization issues as anticipated.

Duration / work estimates: When material differences in work effort or duration are identified (plan vs. actual progress), you should consider reflecting the difference in the schedule (particularly when there is significant work or time remaining to complete the task).

Tasks & dependencies: As work gets underway, additional tasks or task dependencies are identified that are required to complete the deliverable. These generally represent clarification of the work to be performed (vs. change in the deliverable to be completed). Again, if these changes are material in nature, and have not already been completed, you should consider reflecting these changes in the schedule.

Risks & issues: Review of the schedule based upon completing progress updates will often result in identification of additional risks or issues. This is the appropriate time to capture these risks/issues, and plan the appropriate actions to close or mitigate the risk/issue.

Project impacts: There is often a question around initiating project impacts based upon schedule changes identified. This topic is discussed further in my blog post on Managing Change, but the following represent the guidelines as to whether or not a project impact should be initiated:

  • Does this change have a material impact on the scope, schedule (end date), or cost of the project?
  • Is this a permanent change (or just a timing issue that will be resolved at some future point in the project)?

Updating Schedule Progress Best Practices

In summary, the following represent the primary best practices relating to updating schedule progress:

  • Establish a timely process (and supporting tools) to update schedule progress. The team should be well aware of how and when schedule updates will be captured, and when the schedule updates will be accurately reflected in the project schedule (to ensure team members are looking at the most current information).
  • Ensure that the processes for updating schedule progress are efficient for the project manager, as well as the rest of the team. Where appropriate, leverage existing communication vehicles or tools to capture this information (e.g., team meetings, timesheets, and personal status reports).
  • The process of updating schedule progress should regularly trigger the project manager to review the schedule to identify current or potential problems, and initiate the appropriate corrective actions.

Using SharePoint to Improve Project Delivery

As I work with different clients, I usually run across the same project management related theme. Project Management is a very mature competency with very well-defined concepts, processes, and tools. There are a lot of resources available to help organizations improve the PM competency, including one of the best professional organizations I have worked with, the Project Management Institute (PMI). However, clients still have projects that fail, or are significantly challenged (e.g. bad quality, scope creep, late delivery, over budget). Clients are frustrated with inconsistent delivery results from project to project. The root cause of project related problems are often linked to shortfalls from a project management competency perspective.

Project Management Best Practices

To address this shortfall, I generally start the conversation with clients about establishing Project Management best practices. Best practices represent the practical application of the knowledge contained in the PMBOK and other sources of knowledge (concepts, processes, tools). The critical few processes that are integral to the success of the project are listed under each of the phases of the project life cycle in the graphic below. Practical application of these best practices drives a consistent project management approach, and tangible business results:

  • Quicker ramp-up of project managers
  • Easier integration of projects in a multi-project environment
  • More productive project managers (not inventing processes & tools on the fly)
  • Better overall team performance (including measurement of performance)

clip_image001

The Project Environment

The other element associated with driving improved project results is the project environment in which we work. Enterprise Environmental Factors and Organization Process Assets are the most commonly referenced process inputs within the PMBOK. They are the things that your team inherits as it launches a project:

  • Existing systems (finance, timekeeping, project management)
  • Knowledge bases (repository of information about processes, previous projects, organization)
  • Standards / Guidelines (particularly important in a regulated environment)
  • Process, Policies, and Procedures (commonly describe Project Management and SDLC related information)
  • Historical information (artifacts from previous projects)
  • Culture (organization channels, communication vehicles, teamwork)

clip_image002

As I work with clients it is important to understand whether their project environment enables improved project performance, or represents a project constraint. Does the environment enable you to launch and execute the project effectively, or constrain you (weighing you down with baggage and roadblocks)? Some of the questions I ask to determine the answer to this question are:

  • Are the systems tied to the PM best practices, or create “incremental steps”?
  • Are policies, processes, and procedures fully integrated into the project work to be performed?
  • Is information about other projects accessible?
  • How do people work together? How is information shared?

Using a Collaboration Platform to Drive Improved Project Performance

SharePoint 2010 is an enabling tool utilized to dramatically change the project environment (within both single and multi-project environments). Creating a more productive project environment helps you launch the continuous improvement phase of your Project Management “Best Practices” program from a more efficient and effective starting point.

clip_image003

Key elements of a more productive environment include:

Collaboration – Enhancing your project environment to create more effective interaction between team members.

  • Providing a single source for the truth
  • Upgrading version control for key project artifacts
  • Establishing closed loop communications

Streamlining Processes – Utilizing a tool to establish or enhance project management related processes.

  • Establish structure via lists and libraries
  • Use workflow and alerts to reduce cycle time associated with reviews/approvals

Measuring Performance – Capturing the data required to measure project performance, and make the appropriate “course corrections”.

  • Measurements are a by-product of the work performed
  • SharePoint provides a platform to communicate “real-time” project performance metrics

Best Practices Associated with the Collaboration Platform:

The following are the key best practice associated with implementing and maintaining collaboration tools / processes to improve your project environment:

  1. Ownership – If team sees the value in the collaboration tools and processes, they will take ownership for updating and maintaining the project site. The value of collaboration is significantly diminished if the project manager is the only person providing updates to the project site.
  2. Central source – The collaboration tool must represent the single source for current project information. As the project manager, you need to make sure team members use the tool in this manner (e.g., discourage people from maintaining work in progress offline on their own laptop).
  3. Version control – This best practice ties to the central source of information. If utilized correctly, the collaboration tool helps solve the version control related issues across the project team.
  4. On-boarding team members – The project team site represents an excellent source of information to on-board new team members. The team needs to make sure the project site is set-up and maintained in a straightforward manner. You do not want new team members to get lost in the information that is available within the team site.
  5. Project closeout – With a little luck, your projects have a beginning and an end. Decisions need to be made at the end of the project in terms of what happens to the project site.

There may be a next version of the product in which case the site would be “rolled forward” to a new project site.

The production information may need to be available on a support site.

At a minimum, key project information is captured on a historical project file site.

There needs to be purposeful action related to the disposition of project site at the end of the project or you will end up losing valuable project and/or product related information at the end of the project.

Recommended Next Steps

Depending upon the current maturity of the people, processes, and tools around SharePoint in the project environment, your next steps may vary.

clip_image004

The standard approach related to implementing a collaboration platform to upgrade your project environment includes the following:

  • Identify (or confirm) the “critical few” best practices that should be emphasized and integrated into the collaboration platform.
  • Establish some standards / guidelines that would be used by each of the teams (and a place where these standards are accessible). Some examples include:

When to create project site

What are the standard elements of the project site

What meta-data is important for standard reporting or site organization

Create templates for key lists and libraries (risks/issues, change requests, status reports document libraries)

  • Depending on the experience of your project team, you may need to provide training for the team on SharePoint. At a minimum you need to get your up to speed on the specifics associated with the implementation of SharePoint within your project environment.
  • Get started => Don’t wait until everything is perfect before you launch your new project environment. You will never get complete consensus on the standards/guidelines, and there is an opportunity cost associated with “do nothing”.
  • Establish processes to identify and capture best practices in the context of your new project environment. As these ideas are incorporated into the standard best practices they will be reflected as tangible continuous improvements.

Note: Future blog posts will continue to elaborate on the discussion around upgrading your project environment using the SharePoint 2010 collaboration platform.

PM Foundations – Estimating and Loading Resources

One of the common pitfalls I often run across when reviewing project schedules is inadequate attention or diligence around the area of resource planning. Improper planning in this best practice area often leads to project schedules and budgets that may not be reasonable or manageable. The following summarizes the high level best practice areas associated with resource planning:

  • How to estimate the resource requirements for schedule activities.
  • How to load the resource assignments and work effort estimates into the project schedule.
  • How to perform resource usage analysis, and resource leveling techniques.
  • How to create the resource plan utilized to finalize resource assignments, and provide a key input to create the project budget

    For purposes of this post, I will focus on the first two — estimating resources and loading the resource assignments into the project schedule.

Resource Estimating:

There are two techniques for resource estimating – bottom up & resource allocation. Both techniques are valid, and each are more effective than the other in specific situations.

Bottom up Estimating:

The following steps describe the mechanics of this technique:

  1. Work with the team to estimate the work effort (hours) for each resource assigned to the activity.
  2. Enter the hours for each resource assigned to the activity within the Project Management tool.
  3. The Project Management tool computes the allocation % for the activities (based upon the hours and duration assigned to the activity).

When is this technique most effective:

  • The activity is complex, and the team needs to spend time to understand the details associated with the activity.
  • Experience with other projects is based more on actual hours of work effort.
  • Precision of the work effort is very important, and is worth the time to create a more accurate schedule.

Here is an example of how this technique works:

clip_image002

Resource Allocation:

The following steps describe the mechanics of this technique:

  1. Group activities based upon allocation of resources (may be one to one, but more likely will have activities with the same allocation over some period of time).
  2. Assign allocation % for each resource assigned to the activity in the Project Management tool.
  3. The Project Management tool computes the number of hours of work effort for the activities (based upon the allocation % and duration estimated for the activity).

When this technique is most effective:

  • Details of the activity are not known, and therefore it is the duration estimate that is driving the resource estimates
  • Experience with other projects is based more on “how long it takes” vs. “how many hours of work”
  • Precision of the work effort estimates is not as important as developing a reasonable schedule

Here is an example of how this technique works:

clip_image004

As depicted in this example, both techniques arrived at approximately the same resource needs (this certainly will not always be the case). However, the approach to arrive at the resource needs was very different and highly dependent on the situation and information available. For each set of activities within the schedule, it is important to decide on the appropriate approach to estimate and assign resources, and then gather the information required to determine resource requirements. In many cases the project manager will use a combination of the two approaches (#1 for more complex work effort driven activities, and #2 for more duration based activities).

Resource Loading:

Once the resource estimating process is complete, the mechanics of loading resources into the schedule is very straight forward. From the resource tab on the individual task, or from the resource column in the Gantt view (assuming you are using MS Project as your PM tool), the resources are added in the following manner (depending upon the approach selected):

1) Approach #1: Select the resource, enter the hours in the work column, and the % allocation will be computed.

2) Approach #2: Select the resource(s), enter the % in the units column, and the work hours will be computed.

Another key element associated with the resource loading process is the task type set-up for the activity. Use of different task types impacts the way the units (%), work and duration are re-calculated when any of these elements are changed. I always recommend use of fixed duration with an effort driven option as the default set-up. It allows work and units to fluctuate as you modify the timeline (duration). The table below describes the different behaviors within the project schedule, based upon the task type:

clip_image006

When loading resources, a good check that you have the activities broken down to the appropriate level is whether or not you have direct accountability of resource assignments. If you have a lot of tasks with 2-3 people with a 10% allocation, you may not have the activities broken down to the appropriate level.

You want to avoid falling into the trap of loading activities into the schedule that are “indirect” in nature that are merely loaded to reflect usage of individual’s time on the project. Try to keep the schedule focused on “direct” project activities. There are other ways to reflect commitment to the project without putting “noise” in your schedule.

Resource Estimating & Loading Best Practices

In summary, the following are the best practices associated with the resource estimating & loading processes:

  • Use the resource estimating and loading approach that best fits the type of activities that are being planned
  • clip_image008

  • Do not add “noise” into the schedule by attempting to account for all hours expended on the project (activities in the project schedule should be limited to “direct” activities).
  • Set-up the schedule activities in a manner that drives the appropriate behavior when loading resources into the project schedule. I recommend fixed duration as the task type.

Note: I will be posting a blog in the near future on performing resource usage analysis and creating your resource plan.

PM Foundations–The Core Team

At the heart of most successful projects you will find an effective core team that is fully responsible for the day-to-day leadership of the project. This is not to be confused with the strategic level guidance that represents the key function of the project steering committee. The project manager is responsible for ensuring that the core team is effectively selected, on-boarded, and fully engaged throughout the project life cycle.

What is the purpose of the core team?

The practical answer is that the core team is responsible for monitoring the progress of each of the key deliverables and making decisions about course corrections should the project begin tracking behind schedule, over budget or if major scope changes occur.

What are the important elements of a good core team?

A good core team is comprised of the key stakeholders who are empowered to represent a segment of the overall project domain (the segment is generally defined based upon an organization or competency/function they represent). Representing this segment means that the core team member is responsible for providing knowledge from their area of expertise, and making/influencing decisions that impact this area of expertise. Several key factors influence the process of identifying the core team:

  • Diversity: Diversity is a key element of the core team, because it is critical that different perspectives about the project and the project deliverables are fairly represented on the core project leadership team. These perspectives should be represented from day one of the core team — many project managers are tempted to exclude groups from the core team until they are needed to perform specific project activities.
  • Inclusiveness vs. effectiveness: The core team is not the entire project team working on different project activities. Sizing the core team appropriately is critical to the successful management of the project. As the project manager you need to strike a balance between including the right people in the day-to-day management of the project, and creating a team that is too big to effectively make decisions. Based upon my experience the appropriate core team size is somewhere between 6-10 people.
  • Assessing the Organization: The type of organization you are working in significantly influences the manner in which the core team is formed (depicted in the chart below). In a functional organizational, it is generally the functional leads that represent their area/department on the core team. In a matrix and project organization, the core team is generally formed based upon the role of the people assigned to the project. The type of organization also impacts the project manager’s role and authority on the project (from limited in a functional organization, to full control in a project organization).

clip_image001

Procuring the Core Team Members

The factors described above represent key considerations when performing the following steps to select the core team:

  1. Determine which roles should be included on the core team. I find the most effective method is to look for the roles on the RACI chart with the most significant R’s (Responsible).
  2. Decide what project team members can fulfill these roles, If the team has not been formed, the question becomes what people in the organization can fulfill these roles.
  3. Determine if the composition of the core team needs to be adjusted based upon disconnects between the roles on the core team and the names assigned to the team.

The following chart provides an example of assembling a core team, based upon ownership of the key project deliverables. Ownership does not necessarily represent the person that will complete or manage the deliverable, but rather the person that will be responsible for the deliverable. Responsible means that this is the role that will ensure that the quality, scope, timing and cost of the deliverable are satisfied based upon the expectations established in the baseline project plan. Key deliverables which do not have an explicit owner established on the core team generally represents a RED flag (project risk), because the project manager will likely be required to manage these deliverables outside of the project leadership team as a “one off” process.

clip_image002

You will find that multiple people may be required to fulfill specific roles, if one person cannot adequately represent the full scope of the deliverable on the core team. In addition, specific roles may be filled by consultants or third party partners.

Getting stakeholders, functional managers and other resource managers to agree to loan you the right resources for your core team can be a challenge. Having a solid project management plan with high level milestones and roles/responsibilities, Project Sponsor support for the initiative, and clear definition of the deliverables (in the form of a WBS) to reference during the discussion with the resource managers makes this process much easier. When assembling the core team it is important to interact with the potential core team members to understand how well they understand the project – and how they feel about the business case (benefits, scope, target dates). It is a bonus to obtain resources that are passionate about some aspect of the initiative (benefits to their organization, learning opportunities for them, team dynamics).

On-boarding the core team

Prior to the overall project kick-off, the core team is assembled for a planning meeting (or series of planning meetings, depending on the complexity of the project). The planning meeting helps level set the core team on project planning efforts that have been completed to date (prior to them joining the team), and launching the efforts to complete the remaining planning activities/deliverables. The Project Manager facilitates the discussion on project planning deliverables completed to-date (project charter, milestones/target dates, scope statement, RACI, and the Project Management Plan). Making sure everyone is clear about what their role on the project is one of the essential topics at this point in forming the core team.

The Core Team planning meeting is best structured in the following manner:

Goals and objectives

  • Communicate information about the project using project artifacts created to-date
  • Establish a common understanding of roles and responsibilities
  • Begin the process of completing the remaining planning deliverables

Activities / Discussion Topics

  • Icebreakers and introductions (particularly important for new projects, with a diverse cross-functional team)
  • Review of project deliverables (best to provide access to these deliverables in advance of the meeting, so this time is spent productively covering questions and open issues)
  • Establish core team priorities and begin working on the remaining planning deliverables

Core Team Best Practices

The following summarizes the best practices associated with selecting, procuring, and on-boarding your core project team:

Purposefully select the core team

  • The team’s diversity in terms of backgrounds, perspectives and talents significantly improves project outcomes.
  • Right-size the team to accomplish the task at hand – manage the day-to-day project operations. Make sure the team can adequately “own” the project deliverables, but is not too large to effectively manage team dynamics.
  • The core team should be formed in a manner that is consistent with the organization that is driving the project.

Work with the right people to procure the right team members

  • Clearly communicate with resource managers (about the project and resource needs).
  • Use the project sponsor appropriately to gain support of the initiative.
  • Obtain buy-in of the potential core team members (to understand their commitment to the initiative, and comfort with their role).

Make the effort to adequately on-board and ramp-up the core team

  • Spend time “forming” the team.
  • Clearly communicate the plans completed to-date. You want the core team to “own” the plans, even if they were not involved in making all of the decisions or creating all of the planning deliverables.
  • Focus on getting immediate traction on the work ahead. Quickly align the core team with the project priorities, and ownership of next steps.

PM Foundations – Project Closure

Here a few thoughts about a best practice area that is often minimized or entirely overlooked – project closure. At the end of a project, many project managers are hurriedly preparing for their next project or client, and miss a prime opportunity to leave a lasting impact on the client organization.

Project closure starts with effectively shutting down project activities, validating all product deliverables are complete & key product issues closed, and smoothly transitioning resources to new roles (onto new projects, or within operational functions). The PMBOK refers to this process as contract closure.

The second best practice area is gathering customer input about the project, and facilitating lessons learned. There are a lot of good resources available for gathering customer feedback for project work, and the easiest way to evaluate the quality of this data is to ask two questions of yourself and the project team:

  • Is this information actionable?
  • How likely will the organization do something with this information?

Although I place a high value on customer input and recommended next steps, the true sign of a well run project is demonstrated in the final project performance report (also referred to as the Post Project Assessment):

  • How well can you reconcile actual delivery dates to original baseline dates?
  • How well are budget variances explained through approved corrective actions?
  • Are project quality metrics well articulated?

The critical success factors of a solid project performance close-out are creating a strong and well understood project baseline, and diligently managing to the baseline throughout the project life cycle. Assuming these processes are performed properly, the final project performance report represents a summarization vs. data compilation & analysis effort.

PM Foundations–Establishing Project Rhythm

As a project manager, you often rely as heavily on your “soft skills” as a project leader, as you do on your core knowledge as a project manager. This is particularly true during the transition from project planning to execution. It is the time period when you are on-boarding the entire project team, and moving from “planning the work” to “doing the work”. As you make this transition, you must establish a good rhythm on the project team. This rhythm involves three important elements of effective project execution:

  • Teamwork – People on the project are working together to accomplish a common goal.
  • Cadence – Work is getting done on-time, and in the sequence that it should.
  • Communication – People are informed and engaged at the right time about relevant topics.

If the foundation for these three elements of project execution is created during this transition period, when the unexpected occurs on a project, the project team will be equipped to respond appropriately and continue moving the project in the right direction.

Why is project rhythm so important?

The project team works more efficiently and effectively with a common understanding of the goals and the plan to “get there”.

  • Team members are more likely to be well-informed, and actively participate in decision making when strong communication and collaboration processes and tools are established.
  • Team dynamics & satisfaction are improved on a team that understands what progress looks like.
  • Bottom line: Good project rhythm improves project delivery outcomes.

How is project rhythm established?

1. Ensure the team understands the baseline plan

  • Communicate the plan in a manner that everyone hears the key messages (scope, schedule, constraints, assumptions, risks /issues).
  • Find ways to reinforce the messages (team meetings, one on one interactions, collaboration tools).
  • Ensure that the plan “lives”, and is an on-going point of reference for the team.

image

2. Establish the appropriate communication vehicles

  • Establish regular project team meetings (communication & engagement “across” the project team).
  • Conduct timely project sponsor updates (communication & engagement “up” to the project sponsors).
  • Distribute meaningful project status reports (see my last blog for a more detailed discussion of this best practice area).
  • Implement tools and processes for project team collaboration (a central location for the team to reference and collaborate for project work).

image

    3. Capture & report project progress in a timely manner

          • Establish progress update processes that meet the needs of the team (dependent on the size and complexity of the project team).
        • Ensure that the progress update process is linked to (or integrated with) other project related processes (time reporting, team meetings, status reporting).
        • Upon completion of each project progress update, review/analyze the project data with the team to determine:

                  – Why are tasks behind plan?

                  – Are corrective actions required?

                  – Are adjustments to the plan appropriate?

    Summary

    Performed well, the project manager facilitates creating the project rhythm during the project planning to execution transition without the team even noticing. As the transition is complete, and project work is underway, the project rhythm enables the team to quickly gain momentum, reduce overall project risk, and move down the path to successfully deliver on the goals of the project.

    PM Foundations–Project Status Reporting

    For those familiar with the movie classic that pokes fun at the workplace, Office Space, you probably remember the scene where that boss repeatedly nags his subordinate about the importance of a cover page on the TPS reports. This exchange between the boss and subordinate highlights that status reporting is a management mandated activity that does very little in terms of getting actual work done.

    Unfortunately, many project teams maintain this same attitude when it comes to project status reporting. This project management purist views project status reporting as an integral component of effective project communications and reporting (no surprise there). In fact, I would go so far as to say it represents one of a handful of best practice areas that ensures success throughout the execution phase of the project life cycle.

    Nobody reads it, why do it?

    1. Facilitates communications – This is the obvious reason – The project status report establishes a consistent and timely vehicle for fact based reporting about the project that can be consumed in a meaningful manner by all stakeholders (core team members, project sponsors, and other interested parties).

    2. Establishes a rhythm for project performance analysis – It ensures that on a regular basis the project manager performs analysis on what has been accomplished, how is the team performing, and what corrective actions need to be implemented (to resolve problems, or mitigate risk).

    3. Maintains focus on the project team – It highlights where the team needs to focus to correct problems or maintain the progress required to meet or exceed customer expectations.

    Best Practices

    From my experience, the best practices associated with effective project status reporting are in the following areas:

    • Format: How is the information presented to communicate the desired message(s) to the different groups of stakeholders
    • Project Metrics: What are the metrics regularly generated and reported to accurately communicate the current and forecasted status of the project
    • Timing: What is the appropriate frequency of reporting status information (timely enough to be proactive, without becoming burdensome to the project manager and/or team)
    • Re-enforce the message: What additional vehicles must be in place to make certain that the important message(s) are understood, and the required corrective actions are initiated

    Format: As a consultant, I usually walk into a situation where a project status report format already exists. Rather than irritating the customer by suggesting that the current status report is not adequate, I normally look for subtle ways to enhance the information presented. The goal is to ensure that the status report draws attention to the key information that is required to inform or initiate action. Some of the important elements of the status report include:

    • Project header information – Re-enforcement of the overall project scope/goals, and key stakeholders
    • Overall status – Often expressed as a color (Green/Yellow/Red) with some comments about why the overall status is what it is
    • Accomplishments – Highlights progress in the current reporting period (make sure that the key messages are not lost in too much detail)
    • Risks & Issues – Escalates the “top 3” risks & issues, including the corrective or mitigation actions
    • Upcoming milestones – Focuses on the important milestones, including planned vs. forecasted completion

      image
      My general guideline is that a status report should not exceed two pages – if it does, stakeholders are likely to miss some, if not all, of the key messages.

    Metrics: Project metrics are the primary ingredient of the status report that creates fact based information on a regular basis. These metrics must be generated directly from the project management artifacts that are utilized to manage the project on a day-to-day basis (project schedule, project budget, risk register, change control logs). Because these metrics are created from existing project management tools, there should not be significant effort associated with updating them.

    Based upon my experience, the key project metrics presented on the status report fall into one of the following categories:

    • Time – Comparison of the planned vs. actual or forecasted completion dates
    • Effort & Cost – Comparison of the planned vs. actual or forecasted effort / cost to progress to this point in the project (this is where earned value is a useful tool)
    • Scope – Comparison of planned vs. actual scope of deliverables completed to-date (summary of scope changes)
    • Risk – Assessment of the level of risks identified or realized (compared to the initial risk assessment)

    Timing: The most important element related to the timing of the project status report is establishing and maintaining strict adherence to a consistent reporting interval (e.g., every other week) and delivery schedule (e.g., by end of day on Monday). This ensures that the stakeholders know when to expect (or look for) the status report. From my experience, implementation of either weekly or bi-weekly status reporting most effectively meets the needs of both the project manager, and key stakeholders, without creating too much project overhead. Specific sections of the status report may be provided on a less frequent basis (e.g., budget information may be updated on a monthly vs. bi-weekly basis).

    Re-enforcement of the message: Project managers often fall into the trap of assuming that distribution of the status report is enough to ensure that the key messages are well understood, and the appropriate next steps are completed. The distribution of the project status report needs to be directly connected to other regular team communication events (core team meetings, project sponsor / steering committee meetings) to confirm understanding of the current and forecasted status, escalate issues / risks, and initiate corrective actions.

    Delivering the Right Information to the Right People

    image

    In summary, the project status report should not be created with the view that it satisfies a requirement mandated by management, but rather a best practice that creates significant value for you, as the project manager, the core project team, and other stakeholders. Effective use of the project status report is one of the clear indicators that the project is “under control” during the execution phase of the project. On top of that, there will be no need for this conversation: “Hi, Peter. What’s happening? We need to talk about your TPS reports.”

    PM Foundations – The Project Management Plan

    As you read through the integration section of the PMBOK, the key deliverable that connects the project management activities throughout the project life cycle is the project management plan. Once you get beyond the conversation that deals with, “What you are referring to is the project schedule, not the project plan”, many colleagues and clients seem to have a wide range of perspectives that relate to the value (or lack of value) associated with this deliverable. Some of these comments include:

    “I complete the project management plan so I can check it off on the SDLC Checklist. No one really reads it.”

    “If you have seen one project management plan, you have seen them all. They read like a cookbook.”

    “In reality, the project management plan is out of date before the ink is dry on it.”

    “It is really only required for big projects. It is overkill for a small to medium size project”.

    I am often accused of drinking the PMI/PMBOK Kool-Aid, but my sincere belief on this topic is that the comments above relate to a gap in execution of effective best practices, not a case of theory vs. reality.

    Below are some examples of key elements of the project management plan that ensure that this deliverable provides tangible value to the project team as it seeks to meet or exceed customer expectations:

    Project Definition – The project definition provides the “big picture” about the project. This section demonstrates to the stakeholders that the team clearly understands the problem they have been tasked with solving. It is important that the assumptions and constraints identified up-front are reviewed and managed throughout the project life cycle.

    Scope Management – The scope management plan provides a high level description of the project, and the process utilized to define and manage this scope. Make sure the deliverables are described at the level that will remove ambiguity across different stakeholder perspectives.

    Schedule Management – The schedule management plan highlights the major project milestones, and describes important components of the schedule. Which portions of the schedule are built based upon time (duration) vs. effort (work)? Where have planning components been included in the schedule? What criteria were utilized to test the level of granularity in the schedule?

    Cost Management – Cost estimation and control are vital to a project’s success. This section describes the costs associated with the project, how they were estimated, and how they will be tracked and reported. This section also describes any gaps between the cost baseline and the project funding sources.

    Change Management – The change management plan provides a definition of change in the context of the project, and when the change management processes will be utilized. Defining and managing change can be a contentious area, and the best practice is to ensure stakeholders clearly understand and agree how it will be defined and managed well before it occurs.

    Roles & Responsibilities – Defining roles at the beginning of the project is crucial for a smooth project launch. One of the chief causes of project “churn” is related to people not being clear about their role on the project.

    Leveraging best practices, the project manager ensures that a project management plan is efficiently created and is proactively utilized to successfully deliver on the project objectives:

    • Make sure the content of the plan is focused on the information that is relevant to the project. Describe the processes and tools that represent the critical success factors for the project team. Standard processes and tools should be referenced, not included in the plan. This also ensures that the content of the plan is “sized” appropriately to the scope of the project.
    • Present the plan to stakeholders in a manner that clearly articulates the key messages. Do not be afraid to use charts, tables, and graphics to illustrate key points. In addition, consider preparing summary documents that are utilized to brief key stakeholders on the project.
    • Personally reference the plan on a regular basis, to ensure that the team is effectively executing the plan in a manner that will meet or exceed customer expectations.
    • Take deliberate actions to ensure that the plan remains current throughout the project life cycle. It is worth the time investment to ensure that there is a “single version of the truth” about the project, in the form of the project management plan.