PM-Foundations – Planning & Conducting Effective Project Meetings

Project meetings can easily become the nemesis of your project success. Some of the things that I overhear when team members talk about project meetings:

“My day is fully consumed by meetings. I have no time to do my real work.”

“That meeting was a waste of time. Not sure what we were trying to accomplish.”

“We talk about the same things in every meeting.”

“The only decision we made today was that we need another meeting.”

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

Comments from my blog on Project 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.

How Meetings Impact Your Project

On the surface, project meetings seem pretty harmless. How can getting people together to discuss topics and collaborate have a negative impact on my project? Below are several tangible ways that ineffective project meetings can have a negative impact on project outcomes:

  • Consume Time – Project meetings represent an investment in people’s time. If team members were not attending project meetings, they could be completing project work assigned to them. If project meetings do not contribute positively to project outcomes (e.g., sharing of information, making decisions, resolving issues), then they represent non-productive project overhead. Churn.
  • Do Not Result in Action – Project meetings without a defined purpose and agenda do not drive decisions and actions required to achieve project milestones. In many cases, action items are identified or decisions are made in meetings, however there is no follow-through or accountability established to ensure that the actions are completed or decisions are implemented (and the desired results achieved). Churn.
  • Create Confusion – Ineffective project meetings often generate confusion or misunderstandings within the team. When a project meeting is not facilitated and summarized in an organized manner, team members tend to take away very different perspectives from the meeting. The confusion resulting from the meeting can cause team members to communicate inappropriately, and/or work ineffectively. Churn.

In other words, meetings can consume a significant amount of your team’s time, do not drive productive decisions and/or actions, and in many cases are the source of confusion and chaos on the team.

Start With Why You Have Team Meetings

In my experience, the place to start when creating a foundation for effective project meetings is establishing an understanding of why you need meetings on your team. If the meetings do not contribute to one or more of the reasons for having a meeting, they should be transformed or eliminated. Below are the reasons I generally utilize when establishing project meetings:

  • Project Status Updates – Meetings represent an effective means to establish a common understanding amongst the team of where the project is at, and where the focus of the team needs to be. This includes knowing where the team is against plans, and what corrective actions must be taken to get the team back on track. It also includes establishing or clarifying where dependencies exist within the team, and how these dependencies impact achieving upcoming milestones.
  • Forum for Making Decisions – Decisions are required throughout the project life cycle to keep projects moving in the right direction and at the planned pace. In many situations, the decision requires collaboration of key stakeholders, and either a regularly scheduled meeting or an impromptu meeting is utilized to drive the decision.
  • Review Project Content – As milestones are achieved, it is important to ensure that the product(s) delivered meet the expectations of key stakeholders. Meetings are utilized to review project deliverables, resolve issues associated with deliverables, and gain consensus on the approval of a deliverable.

5 Ways to Improve Your Project Meetings

1. Create a Regular Cadence – It is important to establish a well-defined meeting schedule throughout the project life cycle. The meeting schedule includes core team meetings, steering committee meetings, and deliverable/milestone reviews. The meeting schedule establishes both expectations and constraints in terms of team member involvement and investment in team meetings (including both frequency and length of meetings).

2. Target the Audience – Team member involvement in meetings should be established during the definition of team roles and responsibilities. Identifying the target audiences for scheduled meetings includes forming the core team and steering committee, as well as defining stakeholders involved in reviewing and approving deliverables and/or milestones.

3. Establish the Appropriate Approach & Content – The team should decide on the appropriate approach for conducting each type of project meeting, as well as the scope of the content to be covered in the meeting. Does the meeting represent a facilitated discussion, or a sharing of specific information? Do materials need to be prepared or reviewed in advance of the meeting? Most regularly scheduled project meetings have a “standing” agenda that is tailored for each meeting occurrence based upon the current phase/status of the project.

4. Proactively Manage Meeting Follow-up – The wrap-up of each meeting should include a summary of key decisions and actions. These decisions and actions must be documented (as efficiently as possible), and reviewed in a systematics manner (to ensure that they are completed/implemented). I will generally start each regular team meeting with a review of key actions and decisions from previous meetings.

5. Keep Track of your Meetings – Tracking of project meetings helps teams ensure that they are getting the appropriate payback on the investment. For each type of project meeting, I will track the following information:

  • Attendance (including total hours and cost)
  • Decisions made and actions resolved (including deliverables reviewed/approved)
  • Value derived from the meeting (primarily based upon periodic input from meeting participants)

 

Your comments on this blog are appreciated. What experiences have you had with project meetings? How have you improved the effectiveness of your project meetings?

Advertisements

Using MS Project to Manage the Critical Path

The critical path represents the longest (in duration) network of tasks between defined start and end points. The critical path is what determines the total duration of the project. Therefore project managers often draw the logical conclusion that if they diligently manage the series of activities on the critical path, they will ensure that the project is delivered on-time. In my experience, the critical path is a great place to start in terms of analyzing and understanding the project schedule, however there are several pitfalls associated with becoming too focused on managing the critical path:

1. Secondary Paths – Within most project schedules there are alternative networks of activities that are almost as long as the critical path. All it takes is a few adjustments to the plans (i.e., new tasks, or changes in activity sequencing), or variances within the actual execution of the plans (i.e., delayed start of a task, or extended duration of a task), to cause one of the alternative activity networks to become the critical path.

2. Where is the Work? – The critical path represents the longest series of networked activities, but it does not necessarily represent the one requiring the most effort (work) to complete. Generally the network of activities that requires more resources and effort to complete has more risk associated with it. It is not prudent for the project manager to ignore project components that require significant resources and effort.

3. Critical Path Changes – As discussed in pitfall #1, the critical path will change throughout the planning and execution of the project. Changes to any one of the three key elements of the project schedule (tasks, durations, and sequencing) will have a potential impact on the critical path. As a result, it is important that the project manager has the ability to identify and track the critical path on an on-going basis throughout the project life cycle.

These pitfalls highlight the fact that the critical path represents an important data point to monitor and manage throughout the project life cycle, but not the single data point to manage when performing schedule management related functions.

Using MS Project to Identify the Critical Path

As the project schedule is created and updated, MS Project will calculate the critical path, and flag the tasks on the critical path (using the “Critical” field to flag the tasks on the critical path). MS Project provides multiple ways to view / track the activities that it has calculated to be on the critical path. Below I describe the ways that I find the most valuable to manage the critical path throughout the project life cycle.

Filters – One of the filters available within MS Project views is “Critical” tasks. Selecting this filter limits the tasks displayed within the view to the tasks on the critical path.


Select “Critical” Tasks filter


Display only the tasks on the critical path. The “Yes” / “No” flag identifying critical path tasks is maintained in the field named “Critical”.

Group – The Group feature on the view menu provides the ability to group the critical and non-critical tasks.


Select Group by “Critical” Tasks


Tasks are grouped based on those identified as critical vs. non-critical.

Network View – The network view provides a Pert Chart depicting the activity sequencing, and has the ability to highlight the critical path activities within the overall network diagram. I find this view a bit cumbersome to use for projects that are of significant size and complexity. Note: The engineers I work with seem to prefer this view.


Critical tasks are highlighted in Yellow within the Network View.

Gantt View – There are a couple ways to modify the Gantt View to highlight tasks on the critical path. Because this is the view that I use the most when creating and updating the project schedule, I find this technique to be very useful. Critical tasks can be highlighted within the Gantt view by adjusting either the text styles or the Gantt Chart format.


Select Critical Tasks, and change the text color, style, size or background to highlight the tasks on the critical path.


Critical tasks are highlighted based upon the text options selected.


The Gantt Chart tool provides the ability to highlight critical tasks on the Gantt Chart (timeline).


Critical tasks are highlighted in Red on the Gantt Chart (timeline).

Using Slack to Identify “Hidden” Paths

The slack field is utilized to identify tasks that are “close” to the critical path. Slack represents the float associated with each individual task – the number of days the task can slip without impacting the end of the project. Slack is captured within MS Project for both the Start Date and the Finish Date, but I find it is only necessary to track Finish Slack for purposes of managing “alternative” network paths within the project schedule.

In this example task #46 is 5 days from the critical path, but this task requires significant duration and effort to complete (and is likely rated as a high risk task). In reality, my coaching for this project manager would be to break task #46 into multiple tasks with more manageable work efforts and durations.

4 Tips to Effectively Manage the Critical Path

Based upon my experience, managing the critical path is not an exact science. The project manager must continuously take a “holistic” view when creating and updating the schedule, and not become too focused on managing the tasks on the critical path. However, the critical path does provide valuable insights into the tasks that are driving the current project end date. MS Project provides tools that make it easier to identify and understand the tasks on the critical path. Below are 4 tips that I leverage to more effectively manage the critical path and improve project delivery outcomes.

1. Tracking throughout the Project Life Cycle – As previously mentioned, the critical path can potentially change every time you update future plans or actual results within the project schedule. Therefore processes and tools should be put into place to track and manage the critical path every time the schedule is updated. I will generally create a Gantt view that highlights the critical path tasks (either within the task list, or the Gantt Chart). This approach provides the ability to at a quick glance understand the impact of schedule updates on the critical path.

2. Assessing the Critical Path – After each schedule update, the project manager should analyze and rationalize whether or not the tasks listed as “critical” in the project schedule are indeed the tasks that will likely drive the end date of key milestones and/or the project end date. Key questions during this process include:

  • Are tasks on the critical path tracking on-schedule? Are corrective actions required for critical tasks?
  • Are tasks close to the critical path tracking on-schedule? Are corrective actions required for any non-critical tasks?
  • Are there other there other tasks that are of concern (due to effort or risk)? Are the appropriate risk mitigation plans in place?

3. Actively Mitigate Risk – As risks are identified during the schedule analysis process, ensure that risks are effectively mitigated within the project schedule. This mitigation process may include adding/updating schedule contingencies, updating estimated durations or work efforts, modifying resources, or changing activity sequencing. The risk mitigation process may impact the critical path. I will often implement risk mitigation actions to purposefully place a high risk task on the critical path and provide a higher level of visibility and scrutiny to the task.

4. Managing to Milestones – The focus of critical path analysis should not necessarily be limited network associated with the beginning to the end of the project. In fact in most of my project schedules, the end of the project (e.g., Project Closeout Complete) is not the most important project milestone (e.g., “Go Live” Complete). Therefore it is important to understand and manage the critical path to specific milestones (instead of, or in addition to the project end date). This can be accomplished by creating and linking multiple project schedules, or by performing manual analysis to identify/update the critical path for interim milestones. In my humble opinion, this is an area that could be supported more effectively within MS Project.

 

 

What has been your experience with managing the critical path? What techniques / tools have you utilized to understand and manage key tasks and improve project delivery outcomes?

 

PM-Foundations – Is my project funded?

When I worked as a project manager on the client side of the fence, on a regular basis I would have a discussion with my project sponsor that went something like this:

Sponsor: We are going to need to slow down our spending on the project until the end of the quarter.

Project Manager: How can this be? Our budget is already approved by the Steering Committee.

Sponsor: I understand, but the company is struggling to hit it quarterly financial goals, and I have been asked to contribute to the cost saving required to achieve these goals by delaying spending on our project.

Project Manager: You realize that continuing to stop and start activities on our project has an adverse effect on the overall timeline and effort / budget? In addition, it makes it difficult to maintain continuity from a resource perspective when we continue to implement actions of this nature.

Project Sponsor: I understand, but this decision is out of my hands. Help me understand the impact on the project, and I will communicate it when I present the proposed spending delays to my manager.

This is a disheartening experience for project managers because the project team is working hard to meet deadlines, and then due to situations outside of their control, the project is delayed (or in a worst case, put on hold). Project managers that are unaware of the difference between the project budget and project funding are often shocked when this situation occurs. Many project managers believe that once their project budget is approved they are “free and clear” to spend the approved amount. The reality is that as the project progresses, events can occur at the project, portfolio or organization level that cause the project budget and funding to be reevaluated and adjusted. Examples of these events include:

  • The project is taking longer and/or costing more than originally expected
  • The project benefits are less than originally anticipated
  • Other projects are now more important than this project (shifts in emphasis at the portfolio level)
  • The organization needs to cut costs (the discussion described above)

This post describes certain aspects of the project budgeting process that help the project manager work through project funding related events.

The Project Budgeting Process

The development of a project budget represents a “build up” costs from the lowest level activities planned in the project schedule to the point that a project is fully funded within the organization’s cost budgeting processes. The diagram below provides a depiction of the cost build up process.

The following explains each of the components of the process of building up to the overall cost budget:

  • Activity Costs: Represents the cost associated with specific activities in the project schedule. For labor related activities the activity cost is derived from the activity hours times the labor rate for resources assigned to the activity. For material related activities the activity cost represents the material cost assigned to the activity (e.g., purchase of software, infrastructure).
  • Work Package Costs: Costs associated with a work package represents the roll-up of the activity costs for a specific deliverable. Generally this cost can be viewed in the project schedule in the form of a summary task for the deliverable (work package).
  • Control Account: A control account is another name for cost categories that are reported on in the project budget. Control accounts are generally either types of costs (internal labor, external labor, software, infrastructure), or costs associated with major work efforts (project phases or work streams). Control accounts are also where the breakdown between capital and expense amounts are captured. Control account amounts are reflected in the project budget summary, and are derived from the sources for labor and non-labor costs (see previous slides).
  • Project Estimate: Represents the sum of the Control Account amounts (without the project contingency, unless the contingency is included in a control account).
  • Contingency Reserve: Represents the project budget reserve required to mitigate known project risks. Generally the contingency is derived as a percent (%) of specific control accounts or work packages with the associated risk. The best practice is to report contingency as an explicit number either separated on the budget summary, or as a separate control account.
  • Cost Baseline: Represents the total project budget, including the project contingency reserve. This is the amount that the project manager reports against throughout the project life cycle.
  • Management Reserve: Represents the amount that is included in the project funding to account for unknown risks. The management reserve is reflected in capital plans and/or departmental budgets.
  • Cost Budget (Project Funding): Represents the total amount funded for the project, including management reserves. This is the amount that the departmental budget managers are reporting against throughout the financial reporting lifecycle (with input from the project manager). This is also the amount that is reduced when the organization needs to impact the amount spent on a project during a specific time period.

Capital vs. Expense Project Costs

The concept of capital vs. expense related costs is another important area that has a direct impact on project budgets and funding. Under American Institute of Certified Public Accountants (AICPA) Statement of Position (SOP) 98-1 companies are able to capitalize the costs associated with developing or purchasing software designated for internal use. Capitalization allows organizations to defer certain costs related to the software development effort to be amortized over future periods. Expense related costs must be reported in the period in which the costs are incurred. Only certain cost types may be capitalized, and only during particular stages of the internal software project. Expense related project costs are scrutinized much more frequently and closely than capital costs because they impact the current financial reporting period (vs. future periods).

As a project manager, it is important to understand the organization’s specific policies and procedures associated with SOP 98-1. These policies define how costs are categorized as capital vs. expense within the project budget. These policies also outline how the project manager must capture and report capital vs. expense project costs throughout the project life cycle.

The chart below depicts the breakdown of capital vs. expense costs within the project budget.

Project Funding

Although as the project manager, you will likely have limited responsibility for project funding, it is important to reconcile the funding model (cost budget) to the cost baseline for the project. This process starts by understanding when your project is approved by the sponsor team whether or not it is fully funded. Fully funded refers to the fact that the project is accounted for in Departmental Budgets (Expense budget) and/or Capital Plans (Capital budget).

Another important aspect of the funding model is not only comparing the total project budget to the total amount funded, but also understanding the timing of the project funding vs. the cost baseline. Differences between the cost baseline and the cost budget represent the Management Reserve or Deficit. Underfunding situations (deficit) at any point in time requires some action prior to executing on the project as planned:

  • Does the underfunding situation require specific activities to be delayed?
  • Can funds be pulled forward (spent in an earlier time period) to resolve the underfunding?

The chart above provides a depiction of the comparison of project funding (cost budget) to the cost baseline.

 

 

PM-Foundations – That Will Leave a Mark

When working at clients the immediate goal is to meet or exceed the expectations of the engagement. As a project manager this is accomplished by effectively leading projects to successful project outcomes. While being recognized as a team for doing a good job is satisfying unto itself, the ultimate goal is to deliver and perform in a manner that leaves a lasting impression on the project management organization. This lasting impression is reflected in the consistency and effectiveness of the practices routinely used across projects, the ability to measure and report on project performance, and the quality and relevancy of project management processes and supporting project artifacts. In the context of managing projects, there are things you can do that to leave the project organization in a better place than when you arrived – leaving a mark that lives well beyond your time spent at the client.

5 Ways to Leave a Mark on the Project Office

Below are the 5 ways that I focus my energy and efforts during a project management engagement in an attempt to leave a lasting impression on the client’s Project Office/PM competency. Obviously, the level of impact/influence in some of these areas is highly dependent on the scope, length and visibility of your engagement.

1. Become Productive – Clients are often amazed at how quickly a project manager can ramp-up and productively contribute to a project. Quickly becoming productive on a project can be accomplished with limited or no domain knowledge associated with an industry, client, business process or technology. The time to ramp up on a project is largely dependent on the project manager’s experience / expertise, as well as their command of the core capabilities of a project manager. Effective project managers instinctively know how to approach a new project, and where to begin in terms of ramping up and starting to lead the team. Project offices that develop project managers that can ramp up and become productive quickly realize gains in time to market, as well as increase flexibility in terms of moving project managers from project to project. My first job at the assignment is to demonstrate this capability, and then work with the client to make it a core competency.

2. Model Best Practices – My company’s project management services are built around the idea that project management is a very mature competency with many available sources of knowledge, and yet companies still struggle with challenged or failed projects. We firmly believe that the implementation and consistent application of project management best practices is what differentiates successful projects from challenged projects. The more ingrained these best practices are in the project management culture, the lower the dependency on the talents and heroic efforts of individual team members. There are a “critical few” best practices areas that if performed well will significantly improve the team’s performance, as well as the project outcomes (identifying key stakeholders, facilitating the development of the WBS, creating a strong schedule and budget, managing change, and measuring performance to name a few). Throughout the project life cycle, I diligently perform / model these best practices as part of “doing my job” leading the project team. Just when you think nobody is watching, someone will surprise you and comment on how you handled a certain situation. It is in these moments that you know you are leaving a lasting impression on the client based upon the way you are modeling the effective application of the “critical few” best practices.

3. Proactively Mentor / Coach – Part of improving the overall project management competency within an organization is building a project management team that has the capability and desire to effectively apply the best practices in the context of completing “real” project work. I find that having a core of experienced and skilled project managers is a requirement to a strong best practice centric project management culture. Less experienced project managers can “lean on” the core of experienced project managers for professional development counseling, and advice on specific project situations. One of the most enjoyable aspects of consulting engagements is providing “free advice” to other project managers on how I have handled specific situations on other projects (again relying on the effective use of the “critical few” best practice areas). These mentoring opportunities help improve project results associated with the specific situation, and also influence the way that the project manager will handle situations in the future. Effective coaching and mentoring is often represented as “intangible”, but it is surprising the overall impact it can have on the project management competency within an organization.

4. Properly Close Projects – I spend a lot of time on my blog talking about effectively closing a project. The reason I am so passionate about this topic is that project closure is the point in time for project managers to identify / highlight the things done well or poorly during the project, and initiate the appropriate actions to ensure that these lessons learned are reflected in future project efforts. At the end of a project, many project managers are busy preparing for their next project or client, and miss this 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 and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project closure report (also referred to as the post-project assessment). Creating the project closure report includes gathering input from key stakeholders, and identifying improvement actions to be implemented either as part of the closeout process or for future projects. These improvement actions can have a significant impact on the effectiveness of the processes and tools regularly practiced within the project office.

5. Implement Continuous Improvement – As processes and tools are improved in the context of leading a project, the impact of the improvement is limited to a single project if it is not captured as a “standard” within the project office. Improvements may represent “filling a gap” in the project management processes, or an enhancement to an existing tool. In either case, it is important to ensure that the project office regularly captures and roll-outs these improvements across all projects. As a consultant it is usually pretty easy to introduce this practice, however it takes on-going demonstration and re-enforcement of the practice to “make it stick” – creating a culture of continuous improvement does not happen overnight.

Your comments are appreciated. How have you “left a mark” on the project management organization?

PM-Foundations – Where do Project Managers Come From?

In my professional life the project management career path has represented a rewarding and challenging destination. In my case, I did not wake up one day and say, “I am going to be a project manager when I grow up.” Project management is a skillset and career that I have developed over many years in the IT industry.

Why is the career path to become a project manager ambiguous? I think the answer to this question is linked to the fact that to become an effective project manager you must do two very different things consistently well:

1. Apply tactical project management related skills. These skills include managing schedules, budgets, and risks (to name a few). These skills must be learned and then applied appropriately in the context of managing projects. Education is helpful to learn these skills, and certifications such as the PMP validate that the project manager has developed the core knowledge base to manage projects. Organization and attention to detail are critical attributes of the project manager to effectively apply the tactical project management skills.

2. Demonstrate the ability to lead people. The project manager must establish a leadership style that is used to form, build, and lead teams to deliver successful project outcomes. This leadership must include specific skills such as facilitation, communication, managing conflict, and building client relationships.

It is often hard to find people that have mastered both elements of becoming a good project manager. Depending on the person’s education and career path, they commonly favor one element over the other. What is the best career path to become a project manager? My opinion is that there is a single correct answer to this question. Below I provide my thoughts on 4 different paths to become a project manager. Many people, including myself, pursue more than one of these paths before becoming a project manager.

Path #1: School to Project Manager

Colleges offer bachelor’s degrees in Project Management. The bachelor’s and master’s degrees are great opportunities to help people with project based experience make the transition to a project management role. However, I struggle with the idea of hiring a person right out of college as a project manager. These candidates may have the “book knowledge” associated with project management, but do not have the experience of applying these skills in “real world” situations, and likely have an underdeveloped leadership style. To me this approach is the same as hiring a person with a sports management degree, and no coaching experience, to be the head coach of a team. My recommendation to people seeking project management roles right out of school is to pursue a contributor role on a project team, or obtain an “apprentice” type project management role (i.e., project analyst or project coordinator) to gain experience and develop into the project management role over a 3-5 year time period. The PMP certification is a great way to validate that they have obtained sufficient experience and practical knowledge to make the transition. It is also helpful for this person to find a senior level project manager to help them develop and manage the appropriate profession development plan.

Path #2: Business Analyst to Project Manager

The business analyst (BA) role plays a significant leadership role on project teams. The BA is responsible for the “what” associated with the project (product content), while the project manager is responsible for the “how” associated with the project (project content). There tends to be more contributor type roles for a BA, and therefore lends itself to a good starting point for project resources. Many business analysts gain project experience and desire to move to the project leadership role. Based upon the ability to exhibit leadership on projects, and gain experience observing the project manager in action, project management can be a natural career transition for business analysts. I recommend business analysts making the transition to project manager obtain the PMP certification to validate they have obtained the knowledge required to perform the new role.

There is often a perception that the project manager role represents a promotion for a BA. I don’t agree with this perspective. Business analysts have the ability to take on as much responsibility, and add as much value, as a project manager. In addition, the BA to PM transition is only for those interested in the opportunities afforded by the project manager role – it is not for those that are passionate about leading the definition and delivery of product content.

Path #3: Technical Lead to Project Manager

Experienced technical resources often take on a leadership role on the project. The project’s technical lead performs some key activities that support the project manager (e.g., task estimating, resource assignments, issue resolution). In absence of a project manager, the technical lead may even be called a project manager. Given the technical lead’s experience working on project teams, and technical leadership capabilities, the technical lead is a logical project management candidate.

In my experience, this is not as common a career path to project manager, primarily because technical resources do not want to give up the technical aspects of their role as a technical lead to become a project manager. Generally the biggest challenge for the technical lead’s transition to project manager is learning and applying the tactical project management related skills (technical leads do not always like this element of the project manager role).

Path #4: Management to Project Manager

On the surface it seems like it would be a “demotion” to move from a management position to a project manager role. However, the scope of a project manager role can be every bit as challenging and fulfilling as that of a resource manager. In my case, I found the role of leading a group of people to accomplish specific and tangible project goals to be more rewarding than leading a larger group of people to accomplish very difficult to measure organizational goals.

This is a great career path based upon the leadership component of the project management equation. The skills and experience of a manager (assuming they were effective managers) translate well into the leadership requirements of a project manager. In many cases a manager will have performed project management responsibilities in the context of fulfilling their management responsibilities. However, in these cases the manager is usually performing the project management function using very informal techniques, many of which need to be “unlearned” when they transition into the project management role. I always recommend that managers making this transition pursue education and certification (PMP) to ensure they have the core tactical project management skills to perform the job. I also recommend the manager find a mentor that has made a similar transition to help them “fill the gaps” from a skills perspective, as well as to make the necessary adjustments to their leadership style.

 

What has been your career path? What have you found helpful or a challenge with that career path?

PM-Foundations – What Does a Project Manager Do?

One of my favorite questions to ask potential project management candidates is, “When you were managing the project what did you actually do throughout the project delivery process?” It is amazing how vague and ambiguous the responses can be.

“I managed the project deliverables.”

“I led the team.”

“I guided the project.”

“I managed customer relationships.”

“I facilitated project planning.” (this one is a little better)

None of these examples very effectively describe what the project manager actually “does” to ensure the project is planned, executed, and closed in a manner that delivers on customer expectations. The other response that I frequently get to this question is a “deep dive” into the content of what was delivered. For some reason candidates think describing what was delivered articulates their contributions to the project outcomes.

The reason I think it is so important for candidates to be able to clearly describe what they do as a project manager is that it helps identify whether or not they consistently do the right things at the right time during the project delivery process. Focusing on the key elements of what a project manager does is also helpful to identify improvement areas and professional development opportunities when coaching and mentoring project managers. Below are 9 of the project management activities that I focus on when working with project managers. I thought about ranking these in order of importance, but honestly I believe these represent the handful of things that are all important for a project manager effectively and efficiently perform to consistently drive positive project outcomes (therefore these are in no particular order).

Top 9 Things a PM Does throughout the Project Life Cycle

1. Create and Manage the Project Schedule – Without a good schedule that directly supports the project objectives (scope, time, and cost), the project manager will struggle to effectively deliver on customer expectations. The project manager has direct responsibility for creating the project schedule, including defining the work breakdown structure (WBS), performing activity definition and sequencing, loading and leveling resources, and performing schedule analysis. During project execution the project manager updates the project schedule in a consistent and timely manner. These updates ensure that the project schedule always provides an accurate picture of work completed, and work remaining to be completed.

2. Create and Manage the Project Budget – The project manager creates the project budget by efficiently leveraging the planning assets created to that point in the process. The project manager performs analysis to develop a project budget that will be understood and approved by the client/stakeholders, and just as importantly can be managed throughout the project life cycle. Creating the project budget includes developing a project staffing plan that details planned resource utilization (in hours), identifying other project costs (e.g., software licenses, infrastructure investments, and travel & expenses), and complying with the organization’s financial processes (e.g., capitalization, investment approval, project budgeting vs. funding). During project execution the project manager updates the project budget with actual hours reported by project resources and other actual costs incurred (e.g., from vendor invoices). The project manager forecasts cost variances based upon costs incurred and estimated cost to complete the project, and identifies / implements corrective actions required to deliver the project within budget.

3. Create the Project Plan – The project management plan represents the key deliverable created during the planning phase of the project that connects the project management activities throughout the project life cycle. The project management plan describes the elements of the baseline project plan (scope, timeline, costs and resources), as well as the approach, processes and tools that will be utilized to manage each component of the project (e.g., cost management, schedule management, change management risk management, roles & responsibilities, project communications). The project manager ensures that a strong project management plan is efficiently created (the project manager generally authors a large portion of the project management plan), and is proactively utilized throughout the project life cycle to successfully deliver on the project objectives.

4. Identify and Manage Risks / Issues – Throughout the project life cycle the project manager facilitated the investigation of project related uncertainties to identify potential risks of things that may occur that would impact the project (scope, cost, or timing). The project manager is responsible for capturing and tracking risks and issues in a manner that minimizes their impact on the project. The project manager ensures that key risks and issues are reviewed on a regular basis, and the appropriate actions are completed to close issues or reduce the impact / probability of risks.

5. Manage Team Meetings – The two most important team meetings that the project manager has responsibility for are the core team and steering committee meetings. Effective planning, facilitation and follow-up for these meeting by the project manager is a key to ensuring that the core team members and project sponsors are well-informed, focused on the right things, and resolving issues in a timely manner. The project manager creates the agenda, organizes information to be presented, facilitates the meeting, communicates meeting outcomes, and initiates / tracks the follow-up actions from the meeting.

6. Manage Change – Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The project manager establishes the change control process for the project, ensures that potential changes are captured and assessed in a timely manner, implements approved changes by making the appropriate adjustments to the baseline plans, and tracks / communicates the impact of change on the project.

7. Measure and Manage Project Performance – The project manager updates progress against plans (budget and schedule), performs analysis required to accurately interpret the key project performance metrics, and recommends / implements corrective actions. This process is performed in a consistent and timely manner to ensure that problems are identified early on, and the appropriate actions are taken to keep the project on-track.

8. Facilitate Stakeholder Communications – The project manager communicates with key stakeholders in a regular and consistent manner, targeting the messages to specific stakeholder groups using the appropriate communications channels / vehicles (e.g., project update meetings, status reporting).

9. Close the Project – Project closure represents an activity that is often minimized or entirely overlooked by the project manager. 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 second component of closing the project is gathering customer input about the project, and summarizing the project results in the form of the final project report (also known as the project closeout report). This component of closing the project includes facilitating the lessons learned process to identify improvement opportunities (things done well, or areas for improvement), and to initiate actionable next steps to improve future projects and upgrade the capabilities of the project office.

How do you know if you are doing the right things?

This represents a long list of things to do on a regular basis – how do you make sure you are focused on the right things? Part of the answer to this question depends on where you are in the project life cycle. During the planning phase your focus is on creating the planning deliverables – the schedule, budget, and project management plan. During the execution phase of the project your focus shifts to updating the schedule and budget, tracking risks and issues, managing change, communicating with key stakeholders, and measuring / managing project performance.

The other element of answering this question relates to establishing a personal organization system that the consistently helps you understand and focus on activities that will have the greatest impact on driving positive project outcomes. Neal Whitten, in one of my favorite project management books, “No-Nonsense Advice for Successful Projects”, talks about ensuring that the project manager is managing the top 3 problems. Neal states, “The No. 1 reason projects run into trouble is that the project manager and other project members lose sight of the problems that need the most attention – the top three problems. The top three problems become the top priorities.” I think this concept relates directly to the everyday life of a project manager. What are the top 3 things that need to be performed / resolved to keep the project moving in the right direction? There are many personal organization techniques that you can use as a project manager to ensure you are focused on the right things. I utilize a project planning pad (see below) to record and prioritize my activities at the beginning of the week. This tool personally helps me maintain focus on the “right things” throughout the week, and summarize accomplishments and open issues at the end of the week. The same organization system does not work for everyone, but my personal opinion is that effective project managers consistently utilize personal organization processes / tools of some shape or form.

 

On a Personal Note: I got the idea to write this blog when I was talking to a good friend of mine the other day, Mark Ducharme, about what people do (at work). He said I know that you are a project manager, but I have no idea what that means in terms of what you actually do when you go to work each day. Thanks for asking Mark!

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

PM-Foundations – Managing the Creep

I have discussed on several occasions that “scope creep” is not a term that I am particularly fond of. The PMBOK® refers to project scope creep as uncontrolled changes. I have heard project managers say on more than one occasion, “My project is suffering from scope creep”. In my mind that statement translates into, “I have been unable to control change on my project”. One of the key responsibilities of the project manager is to identify and control change – in other words “managing the creep” on your project.

Team members often talk about the amount of change on the project. Change is an inevitable component of managing a project – nothing works out exactly as planned. The project manager effectively manages change by maintaining the appropriate balance between control and discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. The other aspect of good change management is that the project manager effectively communicates the source and impact of project changes. The worst form of change on a project is the type that is not controlled and cannot be explained – it is the CREEP.

5 Tips to Managing Creep

1. Creep relates to all aspects of the project baseline – When most people talk about creep it is in the context of scope. In the context of scope, creep is the small features added throughout the project life cycle that in sum total can have a significant impact on cost, time and quality. Creep also relates to other the aspects of the project baseline – time and cost. In the context of time, creep is the deadlines missed by a day or two, or the activities that take a few hours longer than expected. In the context of cost, creep is the consulting rate that is a few dollars / hour higher than budgeted, the consultant that is required a few weeks longer than planned, or the software license costs that are a bit higher than anticipated. Any one of these examples could have an impact on overall project performance (what is delivered, when it is delivered, and how much it costs), and if it is not controlled and managed, it represents creep. If you are only focused on scope creep, you are only managing part of the overall CREEP in your project.

2. Establish rigor around creep in the planning process – The stronger the baseline plans, the easier it is to identify and manage creep throughout the remainder of the project life cycle. Is the scope well defined and organized in the form of work packages in the WBS? Are the work packages at the level that can be tracked throughout the project life cycle? Is the schedule constructed in a manner that reflects how the work will actually be completed? Are cost assumptions well documented within the project budget? In addition, the project management approach detailed within the Project Management Plan establishes processes and tools that will be utilized to directly or indirectly manage creep. Examples include:

  • Project metrics – How will project performance be measured?
  • Materiality – What represents significant variances that will trigger corrective actions? These variance targets can be expressed as days, hours, dollars, or a percent.
  • Change Control – What process will be utilized to manage change as it is identified?
  • Roles and Responsibility – Who has responsibility and accountability for deliverables or groups of deliverables?

3. Use project metrics to monitor and identify creep – It is important to monitor and understand key project metrics in a manner that helps identify potential (or real) changes as early as possible. These metrics help identify early warning signs for changes that may be “flying under the radar” – uncontrolled change = CREEP.

Some early warning signs include the following:

Schedule slippage

  • Tasks not started on-time
  • Tasks not completed on-time
  • Tasks with less progress than planned (particularly on larger effort or longer duration tasks)

Variance Trends (Cost / Schedule / Risk / Scope / Quality)

  • Consistent cost variance trends (overall or on specific cost types / categories)
  • Consistent schedule variance trends (overall or on specific project phases / milestones)
  • Actual work effort (or duration to complete) to complete tasks is consistently higher (or takes longer) than planned
  • New tasks or deliverables are identified throughout the project life cycle (pointing to gaps in the planning process)
  • Overall project risk (overall assessment of number, severity, and probability of risks)
  • Defects are identified at a higher than planned rate, or the closure rate is slower than planned

Open Risks and Issues

  • An increase in the number of risks and issues, particularly if they are focused in a specific project area, is a good indication of a potential change / adjustment required.
  • Issues that are not closed sometimes point to a project change that is required to close the issue.

4. Turn creep into change – A change represents a permanent deviation from this baseline plan. The term ‘permanent’ is important. It is possible that there is a deviation from the baseline plan that will be self-correcting and is really only a deviation due to timing (when something has occurred vs. when it was planned to occur). When a deviation is deemed to be permanent, it is identified as a potential change and is managed through change control process. Managing a potential change through the change control process moves it from an “uncontrolled change” to a “controlled change” – reducing the level of creep in your project. If several permanent deviations are below the materiality threshold, but in aggregate above the threshold, consider grouping them into a single change to move through the change control process. Again, it is important to strike a good balance between the discipline to control change and the flexibility to respond to changes in customer needs and expectations. The level of rigor and control around formalizing and approving changes should be “sized” appropriately to both the organization and the project. Some considerations include:

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • Projects that have significant schedule and/or cost constraints tend to require increased focus on change control processes.
  • Projects with higher visibility and strategic importance to the organization tend to have more structured change control processes.

5. Understand and communicate the cumulative impact of change – The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing actual project performance to the original expectations established in the baseline plan). Project managers often will fall back on the excuse that the project is over budget or late because there were project changes, but they cannot quickly explain the changes that account for the primary deviations from the original plan. Reconciling the actual project performance (schedule & cost) to the original baseline plan helps understand the “unexplained” variances. An unexplained variance is the difference between the total schedule or cost variance and the approved project changes / impacts. A project with too high a percentage of unexplained variances is usually an indication of a project with inadequate attention to change control processes. These projects have too many changes that are “flying under the radar” – too much CREEP. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

Using MS Project to Improve Project Performance

People often ask me what I find to be the most useful tool to perform my job as a project manager. I pause when responding to this question, because I prepare my share of presentations in MS PowerPoint, create many project deliverables in MS Word, manage my budget using Excel, and I have expressed in many blogs how to improve your project environment using SharePoint. However, because I view the project schedule to be at the core of good project management (my bias as a Time Management instructor shines through), I generally respond that MS Project is the tool that I rely on the most to do my job as a project manager.

In the enterprise project management space, MS Project Server has a lot of competition, but in the project management tool space it is my opinion that MS Project is by far best in terms of features, flexibility, and ease of use. The focus of this blog is how project management tools, specifically MS Project, can be used to improve your ability to manage project performance, from the perspective of becoming both more efficient and effective as a project manager.

Common Myths about using MS Project and Other Project Management Tools

  • I am too busy managing the project to deal with maintaining a project schedule – My response to this myth is that you are too busy managing a project to NOT create and maintain a project schedule. I have seen plenty of situations where the team has invested time and effort in a very extensive project schedule, and then they do nothing with it once they start progressing through project execution. This generally happens because the project manager does not know how to use MS Project to effectively progress and update the project schedule. The time required to create and maintain the project schedule pays for itself over and over throughout the project life cycle with the information required to understand and communicate what needs to be done when, and by whom.
  • It is just as effective and much easier to use Excel to manage the project schedule – I will admit that if you are creating a list of activities/tasks and assignments, Excel does the trick just fine. However, once you need to sequence that tasks, estimate durations and work, and load resource requirements, you quickly get beyond the capabilities of Excel. The time to required to set-up these capabilities in Excel would be much better invested in leveraging the robust out-of-the-box scheduling features of MS Project.
  • Non-project managers cannot understand MS Project – I agree that most non-project managers have a hard time relating to the details maintained within MS Project. Predecessors, durations, WBS are foreign terms to most non-project managers. However, MS Project provides the ability to tailor views of the schedule in ways that non-project management stakeholders find easy to understand and use. From my perspective, it is much more productive to create useful views in MS Project (one time), than spend the time to reenter schedule information into other tools for presentation purposes.
  • Does not work with iterative delivery approaches, only waterfall – Having been the project manager on plenty of Agile projects, I understand that there are additional tools utilized heavily to manage scope and measure progress (the product backlog and burn down charts). However, as a project manager you still need a project schedule to establish and manage overall timing related expectations. The schedule will not contain the details of the sprint, but it is utilized to put the sprints in the context of the other project related activities (e.g., product releases, training, and knowledge transfer).
  • MS Project has a mind of its own – I was mentoring a project manager one time who told me, “his tool had been compromised”. Admittedly, a certain level of complexity is a by-product of the features and flexibility of MS Project. Therefore if you are not familiar with how to create a schedule that can be easily progressed and updated throughout project execution, the project schedule becomes an enigma rather than an enabler. If you are not well versed in MS Project and/or the construct of your project schedule, the impact of updates to the schedule become difficult to understand and communicate. The simple answer to this myth is to get the training and mentoring required to be proficient using MS Project.

6 Ways MS Project Helps Manage Project Performance

1. Breaking down the work: MS Project provides the ability to easily capture and organize the WBS (Work Breakdown Structure). The use of indentation makes it easy to decompose the work from the highest level (project phases) to the lowest levels (tasks) of the project. In addition, the ability to collapse specific sections of the schedule allows you to focus on specific areas of the work breakdown. Some project teams prefer a graphical representation of the work breakdown. The tasks can be easily be imported/exported from MS Project to tools like Visio to support the desire to review a graphical depiction of the WBS.

2. Sequencing Activities: Dependency relationships are utilized to link two tasks in the most logical manner possible. The default in MS Project is Finish-to-Start (FS), but this may not be the relationship that most accurately defines the linkage between two tasks. This relationship may represent a “hard” dependency (this must happen in a certain manner), or a “soft” dependency (a relationship set up to establish a logical flow of the project activities). In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. MS Project provides a lot of flexibility to ensure the Project Manager has the ability to sequence the work in a manner that reflects the way the work will be executed.

3. Creating the timeline: After the project activities, durations and dependencies are loaded, the schedule is starting to take on some shape and form. The Gantt view is one of the most effective tools for communicating the timeline associated with key summary tasks and milestones. Use the MS project filters to limit the tasks to those that convey the appropriate message.

4. Managing resource loading / utilization: The mechanics of loading resources into the project schedule is very straightforward. MS Project provides the ability to either load effort based upon estimated hours to complete or percent the resource is allocated to the tasks. In addition, the resource utilization view displays the effort planned for each team member and the ability to make the appropriate adjustments to “level” the resource utilization.

5. Progressing the project: Maintaining the project schedule throughout project execution is referred to in project manager speak as “progressing the schedule”. In MS Project the project manager has the ability to update the % complete, estimated to complete, and the actual effort worked. In addition, the project manager will make updates to duration & work estimates, dependencies, and tasks to ensure the schedule continues to reflect the way planned work will be completed.

6. Understanding project impacts: Upon completion of the planning process, a baseline “snapshot” of the project schedule is saved in MS Project. This baseline provides the ability to measure current schedule performance against the original plan to understand and communicate actual and planned impacts to the project schedule. These impacts are reflected in the schedule as variances that are captured for the start and finish dates of individual activities, summary tasks (i.e., project phases), and project milestones.

PM Foundations – Managing Supplier Performance

How you work with and manage a supplier on your project is directly related to the type of products and services you are purchasing from the supplier. These products and services may be resources performing specific services/roles, purchase of tangible off-the-shelf products (i.e., infrastructure, software licenses), or built to order products (e.g., custom software applications). In general, the larger and more complex the purchase, the more time and effort you will invest in the supplier management plan. In addition, the greater the dependence of the project’s success is on the supplier the more focused you will be on building a good working relationship with the supplier. In these cases, your goal is to transition from a pure customer-supplier relationship to a true partnership, where both parties have something to gain from the successful project outcomes.

Supplier Management Approach

Again, the supplier management approach will vary based upon the types of products and services purchased for the project. The following outlines the type of project related purchases, and the different supplier management approaches.

Resource Purchase – The supplier is providing resources to fulfill specific roles on your team for specified periods of time (or to complete specific deliverables). The following are the key elements of the supplier management approach for a resource purchase:

  • Resource(s) are on-boarded as any other team member, with a defined role on the team and a related set of expectations/deliverables.
  • Supplier performance is directly tied to the performance of the resources assigned to the team.

Product Purchase – The supplier is providing a standard product has been selected to meet specific needs of the project. The following are the key elements of the supplier management approach for a product purchase:

  • The product is purchased for a pre-defined price.
  • The product is delivered/installed based upon an agreed upon delivery schedule.
  • The project team validates that the product works as advertised (based upon commitments during the purchase cycle).

Make to Order – Fixed Price: The supplier is delivering a product/solution that will be customized to meet the needs of the project at a fixed price (based upon a common understanding of the product requirements). The following are the key elements of the supplier management approach for a make to order purchase with a fixed price contract:

  • The supplier commits to the timing of the delivery of a set of deliverables, including the final product, for a predefined price.
  • The project team validates that the final product delivered meets the specifications defined in the contract.
  • Any changes to the original specifications must be managed on a case by case basis.

Make to Order – Time & Material: The suppler is delivering a product/solution that will be customized to meet the needs of the project, and the purchase price will be based upon the actual time and materials required to deliver the custom solution. In most cases, the cost of the solution is estimated at the beginning of the project, but the final price is directly tied to the actual effort and resources required to complete the work. The following are the key elements of the supplier management approach for a make to order purchase with a time and materials agreement:

  • The supplier commits to the timing of the delivery of a set of deliverables, including the final product.
  • The project team validates that the final product delivered meets the specifications defined in the contract.
  • Any changes to the original specifications must be managed on a case by case basis.
  • The project team manages the effort and cost associated with the delivery of the product / solution (against the estimated cost/effort provide by the supplier).

The chart below summarizes the different supplier management approaches for each of the different types of purchases.

Project Management Approach

As the project manager you play a major role in supplier management. In the same manner the supplier management approach is aligned with the type of product and services purchased, the project management approach must be adjusted appropriately. The following outlines the key elements of the project management approach for each purchase type.

Resource Purchase:

  • Supplier resources are managed in the same manner as other resources on the team. It is important to define roles, and establish accountability for deliverables/assignments. On an on-going basis progress and completion of deliverables are managed based upon established expectations of the role.
  • Ensure that billings are accurate based upon the rate established in the statement of work, and the time reported.

Product Purchase:

  • Ensure that product is received on-schedule.
  • Ensure that the appropriate product validation is completed (the timing of this validation is managed based upon dependencies in the schedule for the product delivery/installation).
  • Ensure that the amount billed is consistent with the contract/purchase order.

Make to Order – Fixed Price:

  • Monitor progress of interim deliverables, tied to delivery of the custom product/solution. Key supplier milestones are built into the schedule, and tied to dependent deliverables.
  • Ensure appropriate product validation is completed (against product specifications). Product validation deliverables are built into the project schedule.
  • Changes to the product specifications, or the timing or cost of delivering the product, are managed using the change control process established for the project team.
  • Ensure that the amount and timing of billings is consistent with the contract / purchase order.

Make to Order – Time & Material:

  • Monitor progress of interim deliverables, tied to delivery of the custom product / solution. At a minimum, key supplier milestones are built into the schedule, and tied to dependent deliverables.
  • Ensure appropriate product validation is completed (against product specifications). Product validation deliverables are built into the project schedule.
  • Changes to the product specifications, or the timing or cost of delivering the product, are managed using the change control process established for the project team.
  • The supplier effort and costs must be monitored and controlled on a regular interval. Earned value is a very effective metric for monitoring time & material contracts (effort vs. progress).

The chart below highlights the key elements of the project management approach for each of the different types of purchases.

Supplier Management Best Practices

Best practices associated with managing supplier performance include the following:

  • Make sure that supplier work and deliverables are clearly identified in the project plans (project management plan, schedule, and project budget). This includes:
    • Supplier deliverables are clearly identified as sections of the WBS.
    • An alternative to creating separate sections in the WBS for the supplier is to identify the vendor deliverables/activities with a separate activity code in the project schedule (preferably using a field that can be filtered to provide a view of supplier deliverables/activities).
    • Often supplier deliverables and activities are not reflected in as much detail in the project schedule, because the supplier is managing this work in a separate project schedule (this is particularly true if the work is performed off-site at a supplier location).
    • Generally, a separate cost category is created in the project budget (or a sub-category – line item) for each supplier. On the monthly cost updates, supplier costs are grouped together, and compared to the amount budgeted for the supplier.
  • The approach and process for managing each supplier is clearly defined in the project management plan. This approach is mutually agreed upon with each supplier. In addition, the supplier is provided “the big picture” associated with the project, and how they fit into the project plans. Many of these expectations will be defined in the supplier agreement or statement of work. This includes:
    • Other project deliverables that supplier deliverables are dependent upon
    • Supplier deliverables that other project deliverables are dependent upon
    • Success factors associated with the supplier products and services
    • Acceptance criteria for the supplier products and services
    • Other project related processes that the supplier must comply with (status reporting, time reporting, financial reporting)
  • Establish one change management process that is utilized for the entire project. Unnecessary confusion is introduced by establishing processes that are unique to suppliers.
  • Product validation is reflected in the project schedule, with the appropriate level of detail. It is important that the supplier understands the timing of the product validation activities, in case they need to respond to any issues identified during this process.