You Can’t Afford a Project Manager on Your Project?

Particularly in the world of consulting, you are always getting pressure to make your proposals more competitive. One of the areas that seems to come up frequently in this process is project management. This project is not too large or complex, do you think we REALLY need a project manager on this? I recently ran into a client situation where the CIO stated, “We cannot afford to have project managers in our organization.” I had to bite my tongue real hard to keep from replying, “Can you afford NOT to have a project manager?” I have been involved in more than one project that has become significantly challenged directly or indirectly because of a lack of project management focus on the project.

This post is an attempt at a non-biased look at whether or not it is reasonable to squeeze the project manager hours out of your project budget (or at least significantly reduce them).

What Questions Should You Ask?

There are several questions that you should ask when you are considering reducing or eliminating the project management hours from your project budget. The answers to these questions will give you a good picture of the risk you are introducing by taking this action.

1. Who is going to create and maintain the schedule? If the project has a target date that is anything over two weeks, you need some semblance of a timeline to ensure that the project is completed on-time. Without a project manager, the team may opt for a task list in SharePoint or Excel or a high level diagram in Word or PowerPoint. However, as the duration, number of tasks, or number of resources increases for the project, the more likely the right tool to create and manage the project is MS Project. Do you have the person with the right skill set to create and manage the project schedule, given the appropriate tool selected? This person also needs to be able to identify and implement the appropriate corrective measures if the project begins to get off track from a schedule perspective.

2. Who is going to manage the budget? In most cases, some financial constraints or estimates have been established during the project initiation process (possibly in the form of a proposal and/or Statement of Work). Obviously the larger the project (driven primarily by duration and resources), the greater the risk of a material budget overrun, and the need to pay close attention to the actual spend vs. the original budget. At a minimum the actual hours expended vs. planned should be tracked on a regular basis. In addition, as in the case of the project schedule, the person tracking the budget must be able to identify and implement the appropriate corrective measures if the project begins to deviate from the planned budget. Many teams do not have resources with the discipline or attention to detail to properly track/manage the project budget.

3. Who is going to identify and manage change? The answer to this question could represent the tipping point relating to your decision. How clear cut is the solution you are delivering. What are the areas that change could be introduced? Do you have processes and people in place that can clearly and diplomatically highlight and resolve change related issues with the customer? Given the choice, the team may decide not to escalate change related issues for fear of upsetting the customer.

4. Who is going to provide status updates to the customer? Failure to communicate with the customer in a clear and consistent manner throughout the project life cycle causes the client to quickly raise a red flag. Technical resources tend to enter the “cone of silence” once they capture the information they need to launch the design and development effort. Someone needs to be on point for regularly providing good quality status reports (in writing) and proactively managing issues as they arise.

5. Who is going to facilitate core team meetings? Who will provide leadership on the team by facilitating effective team meetings? This function includes the communication of progress and upcoming critical activities to team members. It also includes identification and follow-up on key project issues and action items. Both of these areas should be documented and available to the team (usually in the form of meeting minutes and/or status reports). Again, if left to their own desires, technical resources may vote to eliminate team meetings, and cause angst on the part of the customer due to the limited amount of communication.

What Options Do You Have?

There are several options to the project manager dilemma, if the project budget truly cannot afford the additional hours associated with project management. Again, depending on the gaps identified by asking the questions above, you can decide which option best mitigates the risks introduced.

1. Technical Lead takes on the PM role – In the absence of a Project manager, the option that is often selected is to have the technical lead on the project assume the project management role/duties. An experienced technical lead generally has the leadership and client relationship skills to effectively facilitate team meetings, provide project status, and possibly control/manage change. However, the technical lead often gets wrapped up in design and delivery of the solution, and the risk increases that the schedule and budget will not receive the appropriate level of attention..

2. Add a non-billable PM to the team – Based upon the risk associated with not adding project manager hours into the project budget, the organization may choose to assign indirect, non- billable, responsibilities to a project manager to provide oversight for the project. This person would likely provide help with creating and managing the project schedule and budget, and potentially managing changes. However the day-to-day leadership and communication related responsibilities would likely be assigned to other members of the project team. This approach generally falls in the category of “you get what you pay for” (or in this case what you don’t pay for). Given the choice between billable and non-billable activities, the non-billable project manager may not spend the time required to effectively identify and escalate problems associated with the project.

3. Reduce the PM role to the minimum – Rather than eliminating all of the hours associated with the project manager, the organization may choose to reduce the role of the project manager (and reduce the hours accordingly). Based upon the answers to the questions above, the project manager’s role and time on the project would be limited to the areas that cannot be assigned to other team members. This option introduces a risk similar to option #2, because the project manager will be part-time on the project, and will be dealing with competing demands from multiple projects. For consulting companies maintaining acceptable utilization rates for project managers is always a problem when they are balancing multiple part-time assignments.

4. Add a PM that can fill multiple roles on the team – This option is similar to option #3 from the perspective that the project manager role is reduced to accommodate the hours that can be included in the proposal. In many cases, the project manager role is limited to specific functions listed above. However, rather than assigning other projects to the part-time project manager, the project manager assumes other roles on the same project. The most common example of the multiple role option is to have the person perform a dual role as a project manager and business analyst. This approach assumes that the person assigned has the skills / knowledge to effectively perform both roles. This approach is often more effective than Option #3 because the project manager is not dealing with competing demands across multiple projects. The project manager and team need to prioritize his/her activities across multiple roles within the same project.

Advertisements

8 Bad Habits – Creating and Maintaining Your Project Schedule

I have always believed that you can learn as much or more from challenges and problems on projects as you do from successes. It is amazing how much you as a project manager contribute to the project’s challenges (in a bad way). The project schedule is a good example of where a project manager can have the best intentions in the world, and yet they create a schedule that is difficult to understand and nearly impossible to maintain. The bad thing about a poorly constructed project schedule is that it is something you have to live with the entire project life cycle. I have been on more than one project where we decided it was best to have a “do over” on the schedule than continue to struggle along with the one we were using.

There are a handful of traps that project managers fall into when creating a project schedule, either because at the time it seems like their approach is a “shortcut”, or they don’t understand the scheduling tool well enough to know any better. These bad habits make the schedule difficult keep up to date to reflect progress on the project, as well as changes in the work to be performed. In addition, these bad habits make the schedule difficult to understand by key stakeholders (sponsors and team members), which usually results in the need to create additional tools and reports to communicate work assignments and provide project status updates. Below are the 8 bad habits that I most frequently encounter.

The 8 Bad Habits

1. Failure to Use MS Project – This first habit seems obvious, but it is amazing how many project managers use tools other than MS Project to create and maintain their project schedule. Many project managers create visuals of the project timeline using tools like PowerPoint or Visio for stakeholder presentations and believe this same visual can be used effectively to manage progress/work on the project. In addition, some project managers feel that MS Project represents “overkill” for their project, so they use tools like Excel or SharePoint Task Lists to maintain project tasks and work assignments. These tools are fine until you need to understand things like task dependencies, resource utilization, or overall progress (% complete).

2. Poorly Structured WBS – Many project managers start entering tasks into the project schedule without taking time to think about how the tasks should be organized in the context of a Work Breakdown Structure (WBS). The Work Breakdown Structure is what provides you with the ability to roll-up activities and track/report effort and progress by major project components. It is a good practice to ensure that the WBS is organized based upon the way work is planned to be completed throughout the project life cycle. A strong WBS allows you to closeout large segments of the schedule as your move through the project life cycle.

3. Unnecessary Constraints – Inexperienced MS Project users will often insert unnecessary constraint dates into the project schedule. Their logic is that they should just enter the date the task will start or finish. The problem with this logic is that when dependent tasks change, the task with the constraint will not move as well. There are times when a constraint is appropriate (e.g., external dependencies), however overuse of arbitrary constraints results in a lot of manual intervention when maintaining the schedule (or worse – incorrect reporting of task start/end dates).

 


 

4. Dependencies Tied to Summary Tasks – One of the “shortcuts” that project managers will use is tying a dependency to a summary task. This approach eliminates the need to maintain dependencies for each of the individual tasks in the group of tasks. The problem with this “shortcut” is as soon as one of the tasks in the group has a different dependency, the dates for the individual task will be incorrect because the summary task dependency takes precedence over the individual task dependency. In addition, it is difficult to understand where the actual dependency exists when there are dependencies tied to summary tasks.

5. Lack of Clearly Defined Milestones – Milestones represent events or points in time that are critical to the success of the project. A milestone is established in the project schedule automatically by creating a task in the schedule with “0 days” duration. It is a good practice to focus on milestone status in executive sponsor project reviews. It is difficult to understand significant planned project accomplishments without clearly defined project milestones in the project schedule.

 


 

6. Incorrect Resource Loading – Many project managers load resources into the project schedule to assign resources to tasks, with no attention paid to the work effort established for the task. Loading resources at 100% utilization for the planned duration for each task results in significantly overstating the overall work effort for the project. The work effort can be adjusted by entering the estimated work hours for the task or the allocation % for the resource.

7. Improper Set-up of Schedule Options – The Options maintained in the project schedule establish the default behaviors of the project schedule. Many project managers do not understand why certain information does or does not change when other fields are updated in the schedule. In most cases, the update behaviors are tied back to the default Options that have been established for the project schedule.

 


 

8. Poorly Organized Views – MS Project provides the ability to define views that are used to track different information maintained in the project schedule. In addition, these views can be defined in MS project templates to ensure that projects are reported in a consistent manner across the project office. Unfortunately this is functionality that most project managers do not use very effectively. Project managers attempt to overcome poorly constructed views by creating visuals of the timeline and resource utilization in tools such as PowerPoint.

Benefits of Good Practices

Applying good practices to create and maintain your project schedule will save you time and ensure that you are presenting the right information in an accurate manner to your stakeholders. The following are the specific benefits associated with good schedule management practices.

  • On-Going Schedule Maintenance – You will spend less time updating a project schedule that has been well constructed.
  • Presentations to Stakeholders – You will have the ability to present information to stakeholders as a byproduct of maintaining the project schedule (without using separate visuals of the schedule in other tools).
  • Understanding & Communicating Resource Requirements – Resource utilization information is available to understand and manage over or under allocation of critical project resources.
  • Enterprise Enablement – Use of good schedule management practices is a prerequisite of successful implementation of enterprise project management tools (e.g., Project Server).

Note from the Author:

First of all, I apologize to my readers for not posting new content on my blog for a little over a year. I don’t really have an excuse, other than you tend to go through “seasons” where you are more passionate and motivated to write about the things you see and do as a project manager. Writing a blog is like cutting your grass or cleaning your house. If you keep up with it on a regular basis the work is not too difficult, but as soon as you let it slip a bit it becomes much harder to get motivated to take on the bigger task at hand. I have recently been exposed to some new project management approaches and tools, so I am hopeful to keep up the momentum and post more regularly.

Secondly, my good friend, Tom Hoffmann, and I frequently joke about his less conventional approach to project management. In fact he takes great pride in frequently practicing bad habit #1. It is with a smile on my face that I dedicate this post to Tom’s Worst Practices (TWP).

PM-Foundations – Understanding the Maturity of Your Project Office

Let me start by saying that this blog post does not dive into the depths of project or capability maturity models. I am focused in this discussion on how to build a project based organization that delivers in a consistent and effective manner across the project portfolio. I run across many clients that hire, contract, and develop a team of strong project managers, and still describe situations where they are achieving mixed results in terms of the success of their projects. Although people are certainly an important element of building a solid project office, it is not the only component required to provide tangible value to the overall organization. Establishing a mature project organization represents the process of assembling the right team, supporting the team with solid processes and tools, and most importantly creating a project based culture and competency that consistently meets or exceeds customer expectations.

Why is Maturity Important?

Maturity within the project organization represents an enabler to improve project delivery results. Below are several reasons that maturity helps increase the value that project organizations provide within your company.

  • Consistent Outcomes – First and foremost, maturity helps drive consistency within your project organization. Consistency represents a standard way of doing project work, and when implemented correctly also translates into improved project performance (e.g., time to market, quality of the product delivered, reduced costs and resources).
  • Scaling Up – Maturity represents a foundational element that allows project organizations to scale up the work that is performed and delivered. Scaling up means project organizations can take on more projects concurrently, as well as increase the overall size and complexity of projects.
  • Taking it to the Next Level – Lastly, maturity enables project organizations to more effectively drive continuous improvement. Mature project organizations are much better equipped to successfully implement significant process improvements and tool upgrades (e.g., Enterprise Project Management and Collaboration platforms).

6 Indications Your Project Office is Mature

In this discussion I am not providing you with a prescription or recipe to build maturity within your project office, but below are 6 essentials of a mature project organization. Understanding where your team is at in these 6 areas, as well as focusing on ways to perform more consistently and effectively in these areas, will definitely help improve the overall maturity of your project organization.

1. Project Organization – Forming the project team sounds pretty basic, but it is amazing how many project teams launch the project without performing stakeholder analysis, and defining the project organization. Important elements of the project organization include project sponsors, the core team, and understanding other key stakeholders. The RACI represents a flexible and effective tool to define roles and responsibilities within the project team. Do your project teams include the important elements listed above? Are roles on the project team well defined and understood?

2. WBS – The WBS defines the scope of the project and breaks the work down into components that can be estimated, scheduled, and easily monitored/controlled. Simply put, a WBS is a deliverable oriented hierarchy that defines the work of the project, and only the work of the project. The WBS is best discussed and defined using cross-functional facilitated sessions. Do project teams use a WBS to define and breakdown the scope of project? Does the WBS represent the entire scope of the project? How do teams gather the information required to create the WBS?

3. Resource Loaded Project Schedules – The project schedule utilizes the WBS to define the activities, sequence, durations, and resources required to complete the project work. What does a good project schedule look like? Here are a few questions to help test your schedule:

  • Are the deliverables and activities broken down to a level that can be estimated and tracked?
  • Has accountability / responsibility been established for deliverables and activities?
  • Can you easily follow the flow of the project work?
  • Do the milestones appear to be reasonable and achievable?
  • Does the resource usage link appropriately to the project budget?

4. Measuring Performance – This maturity indicator involves keeping your eye on the appropriate project performance measures to proactively identify potential problems, and engage the team to identify and implement corrective actions. Measuring project performance includes schedule, budget, and supplier performance. Earned value represents one of the more effective tools available to measure schedule and budget performance. Do project teams use consistent metrics and processes to measure and communicate project performance? Are these measures used to communicate project performance across the project portfolio?

5. Closing Projects – Project closure starts with effectively shutting down project activities, validating all project 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. Do project team validate that project deliverables are complete, and product issues are resolved before closing the project? Do project teams create a final project report? Do project closure reports include actions required to drive continuous improvement within the project office? Are continuous improvement actions regularly reviewed and implemented?

6. Processes & Tools – To be considered a mature project organization, you must establish and document the project management processes associated with what you consider to be the critical few best practice areas (e.g., schedule management, cost management, change management, issues and risk management, project closeout). In addition, mature project organizations will implement tools and templates to ensure that the best practices are performed in an efficient and consistent manner. The most important aspect of project management processes and tools is that when you examine project work closely within your organization, you find that these are the processes and tools that are utilized on a day-to-day basis by project teams to achieve positive project outcomes. Have the critical few best practice areas been identified within your project organization? Have the processes associated with these best practice areas been defined and documented? Are process documents, tools and templates readily available and consistently used by project teams?

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?

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 – “H” is for Humble

A few weeks ago I listened to the eulogies at my father-in-law’s memorial service and reflected on the fact that it was not what he had accomplished in his lifetime that was so important, but rather how he accomplished it. My father-in-law was an accomplished mechanical engineer who during his time a McDonnell Aircraft was involved in testing the first Mercury space capsule prior to its flight. He moved with his family to Dayton in 1960, and was employed at Wright-Patterson Air Force Base, where he spent 30 years as a Structural Test Engineer. During his career, he was responsible for conducting full-scale tests and is the author of many technical reports describing these tests. He received numerous awards and letters of commendation for his work during his career. During all his years as an engineer, he was most known for the dedicated and unassuming manner in which he led these mission critical tests. This humble and committed approach carried over to his personal life as a husband, father, and grandfather. He was the person that would quietly “step up” and solve problems, whether it was finding the missing homework, or picking up the grandchildren from a band competition.

I share these thoughts about my father-in-law because I think they are very relevant in the context of the role of a project manager. The project manager role is responsible for leading the team to achieve specific project goals and objectives. Team members tend to more clearly remember and describe how the goals and objectives were achieved, vs. if they were achieved. Traditional project leadership involves a command and control type of approach, with the project manager monitoring and directing activities. In contrast, the servant leadership style puts the needs of the team member first, and the project manager’s role is focused on supporting project activities and removing roadblocks. I am not saying that there is one “right answer” to the appropriate project leadership style, but I do believe I would prefer to be remembered as a hardworking and humble project leader, than a hard-driving and demanding project leader. The servant leadership style creates a high degree of engagement and participation of team members in decision-making, as the project manager encourages and supports team members to leverage their full potential and abilities. Below I highlight several ways that a project manager can take a more humble and supportive approach, while still leading the team to successful project outcomes.

7 ways to be humble while leading a project team

As a project manager, there are a number of tangible things that you can do to establish a servant leadership approach to project management. This approach places heavy emphasis on creating a fully engaged team, establishing a positive project environment, and focusing on supporting vs. directing project activities. These 7 tips represent a combination of applying servant leadership based skills, and implementing practical techniques to enhance the project environment.

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

2. Focus on Facilitating vs. Directing – Much of what a project manager does involves facilitation – enabling project teams to collaborate to get work done. Project managers facilitate meetings, decision making, and issue resolution (to name a few). Effective facilitators understand the impartial role of the facilitator, ask good questions to promote meaningful discussions, and leverage facilitation tools to achieve the desire results. Facilitation encourages team members to perform project work in a highly collaborative manner.

3. Exercise Active Listening – Active listening is required to understand what people are working on, identify challenges team members have encountered, and capture ideas to improve project performance. Active listening also provides the project manager with better “peripheral vision” (things that are not in the project manager’s direct line of sight) to identify potential problems or risks. Many project managers feel that leading involves a lot of talking, and I would argue that leading involves much more listening.

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

5. Be Accountable to the Team –The servant leader will quietly take accountability for actions required to remove roadblocks encountered by the team. You complete these actions with the same diligence and urgency that you would expect from other team members. You don’t want to become the “weakest link” that is responsible for an open issue that blocks progress, and impacts project success.

6. Recognize Contributions – It is extremely important to recognize people’s contributions on the team. There are two categories of contributions that I recognize on the team – (1) efforts that help the team achieve its goals, and (2) efforts that demonstrate or promote teamwork. As the project manager, you are recognizing contributions that helped drive positive project outcomes based upon either the work that was performed, or the way in which it was performed. A significant amount of positive energy can be created on the team by recognizing the right efforts at the right time. The recognition does not need to be elaborate, but it must be sincere, and a bit of creativity helps generate a fun atmosphere on the team.

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

This blog post is dedicated in loving memory of Murray N. England (May 7, 1930 – January 24, 2013).

PM-Foundations – Using Earned Value to Identify Budget Variances

Within the world of IT projects, labor generally represents the largest and most complex component of the overall project budget. As a result, the development of the project schedule is a major driver in creating the project budget. Deliverables and activities are identified and sequenced, resources are estimated, and the project timeline is established. The project staffing plan is created from the resources loaded in the project schedule, and this staffing plan generally represents the largest component of the overall project budget. Ironically, after the project budget is created using the project schedule as a primary source of information, project managers often disconnect the linkage between the schedule and the budget when analyzing these two critical project artifacts during project execution. Many project managers identify and report on budget variances by comparing actual costs to planned costs (by reporting period), without taking into consideration planned vs. actual progress on the project. In this post I use an example from an actual project to help articulate the value of using earned value techniques to perform budget analysis.

Traditional Budget Analysis

The picture below depicts the labor related budget and actual costs from a project. This is the information created / captured during the planning (project budget information) and monthly budget update (actual cost information) processes.

If you are strictly comparing actuals to planned amounts, the budget performance looks fairly positive, and you would draw the following conclusions:

  • Tracking $6,153 under budget (Planned Costs to-date: $292,680 – Actual Costs to-date: $286,527)
  • $71,555 is the forecasted remaining costs to complete the project (Total Budget: $364,235 – Planned Costs to-date: $292,680)
  • $ 358,082 is the forecasted Estimate at completion of the project (Actual Costs to-date: $286,527 + Estimated to Complete: $71,555)

Even without completing the earned value calculation, you get an early indication of a potential schedule and/or cost related issue when you compare the total progress to-date from the project schedule (72%) to the total costs spent to-date (78.6%).

  • 78.6% of budget spent to-date (Actual Costs to-date: $286,527 / Total Project Budget: $364,235)
  • 80.3% is the planned completion % (Planned Value: $292,680 / Total Project Budget: $364,235)

Using Earned Value Techniques

If you progress the schedule on a regular basis, using a tool such as MS Project, you have all the information required to calculate earned value metrics. Start by organizing the information you need to calculate the key earned value metrics:

  • Planned value (PV) is the total amount budgeted through this time period (November 2010)
  • Earned value (EV) is calculated as the total budget * % Work Complete (from the project schedule)
  • Actual costs (AC) through November 2010
  • Cost Performance Index (CPI) = Earned Value / Actual Costs
  • SPI = Earned Value / Planned Value

In this case both the SPI and CPI are less than 1, which indicates that the project has a negative variance, both from a schedule and a cost perspective.

Upon completion of these calculations you are ready to calculate the key earned value metrics (estimated to complete, estimated at completion, and variance at completion):

  • Estimated to Complete (ETC) is $111,427 vs. $71,555 computed based upon planned vs. actual
  • Estimated At Completion (EAC) is $397,954 vs. $358,082 computed based upon planned vs. actual
  • Variance At Completion (VAC) is over budget ($33,719) vs. $6,153 under budget based upon planned vs. actual

Using the earned value technique for budget analysis, it becomes evident that the project is both over budget and behind schedule, and corrective action is most likely warranted. Integrating the work and time dimension in with the traditional budget and schedule analysis provides a whole different perspective on the project performance.

When to Use Earned Value

The example demonstrates the value associated with the earned value technique. The following points highlight a few considerations when determining the appropriate use of the earned value technique to measure project performance:

  • Good use of this technique requires that reliable schedule and cost data are available in a timely manner throughout the project life cycle:
    • Actual hours and costs are reported in an accurate and timely manner
    • Schedule progress (% complete) is updated regularly and is reasonably accurate
    • Planned % complete is available (either based upon budgeted hours or based upon the baseline established in the schedule)
  • Obviously budget control / management must be part of your role as the project manager to fully utilize the earned value technique. However, the same metrics can be derived by replacing costs with hours. The only thing that the earned value technique using hours will not highlight are rate related variances (since you are only using effort hours to drive the cost and schedule variances).
  • The earned value technique is most effective when there is a strong correlation between cost and the schedule. This is not an effective technique for example if 80% of the project cost is associated with a single purchase, and 80% of the project timing is associated with the implementation effort (which is only 20% of the cost).
  • The best metrics to utilize to track the cost and schedule performance trends are the CPI and SPI. These are fact based data points that are valuable to report to the project sponsors on a regular basis (as support of the rating of the overall health of the project).
  • The majority of this section (including the example) focuses on providing the analysis through the end of the project. However, if the cost and schedule information are organized properly, this analysis can be performed based upon major milestones (e.g., project phase). This practice would be best utilized for very large and complex projects involving several different large work efforts.

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 – Performing Stakeholder Analysis

As a project manager, when I am assigned a new project I quickly dive into the “what” associated with the project.

What is the product we are building?

What is the scope of the project?

What is our budget?

What is the target date?

Equally important, but often overlooked, is the “who” component of the project. Performing stakeholder analysis early on during project initiation helps the project manager have a better understanding of who is interested in the project, who is impacted by the project, and who is going to help define and deliver the project. Having a better appreciation for these elements of the project helps the project manager develop a more purposeful approach to defining the project scope, budget, and timeline. Stakeholder analysis represents an effective technique to identify and assess the importance of key people, groups of people, or entities who can significantly influence or impact the project. Stakeholder analysis is generally performed once at the beginning of the project, but may be performed on a regular basis to track changes in stakeholder importance and influence/impact over time.

Purpose and Benefits of Stakeholder Analysis

Stakeholder analysis is one of the first steps to understanding and level setting stakeholder expectations. It also represents an excellent opportunity to initiate engagement of key stakeholders in the project. Stakeholder analysis related discussions helps the team identify:

  • Who may affect or be affected by the project
  • Potential issues that could disrupt the project
  • Target audiences for information distribution during the planning and executing phases of the project
  • Groups that should be involved in different stages of the project
  • Ways to manage negative stakeholders

In addition, stakeholder analysis related discussions are utilized to start to build the relationship between the project manager and key stakeholders, providing the following benefits to the project:

  • Provide stakeholders the opportunity to express their ideas/issues/concerns related to the project (before the project “has left the train station”)
  • Establish a sense of accountability and/or responsibility for the project
  • Enable effective risk identification & response planning
  • Create an excellent learning opportunity for both the project manager and the stakeholders

Who are the stakeholders?

The different types of stakeholders can be represented like layers of an onion (see the diagram of sample stakeholders below). Stakeholders closer to the center represent the “primary” stakeholders that are directly involved in or impacted by the project. Stakeholders depicted in the outer layers of the diagram represent the “secondary” stakeholders that are indirectly involved in or impacted by the project.

The “key” stakeholders are the primary and secondary stakeholders that have significant influence or importance associated with the project. The goal of the stakeholder analysis is to identify and capture information about the “key” stakeholders associated with the project. It is critical to gain a good understanding of the people that are important and relevant to the project, but you also do not want to create an “analysis paralysis” situation by including too many potential stakeholders in the process. Some of the questions utilized to identify the right people to involve in the stakeholder analysis include:

  • Who will use the product being delivered by the project? Who will represent the needs of these users?
  • Who initiated this project? Is this person / group the project sponsor?
  • Who is paying for this project?
  • Who will be involved in defining, designing, building, and implementing this product?
  • Who will support this product after it is implemented?
  • Are there external entities impacted by or influencing this project?
  • Will this project negatively impact individuals or groups within the organization (e.g., changing job responsibilities, or loss of jobs)?

Information Captured During Stakeholder Analysis

The following represents the type of information captured about each of the individuals identified during the stakeholder analysis:

  • Stakeholder Name / Group: Who is the stakeholder? What is their title and/or role? Where does this role fit in the organization?
  • Stakeholder Type: Is the person a primary (direct) or secondary (indirect) stakeholder? Based upon their influence or importance related to the project, are they considered to be a “key” stakeholder?
  • Date Identified: When was this stakeholder initially identified? Knowing when a stakeholder was identified / involved in the project can be useful when assessing potential changes introduced throughout the project life cycle.
  • Stake: What does the stakeholder stand to gain or lose based upon completion of this project?
  • Commitment: What is the stakeholder’s priority for this project compared to other work? I keep this simple by assigning “high”, “medium” or “low”. Generally the stakeholder’s priority assigned to the project is directly related to the stake in the project. Commitment level translates into the amount of attention or time the stakeholder intends on spending on the project.
  • Impact on project: How critical is this stakeholder’s involvement in the project? A stakeholder may be critical to the success of the project, even though he/she has little stake in or commitment to the project (based upon their overall influence / importance within the organization).
  • Next Steps: What specific needs/issues does this stakeholder have related to this project (e.g., status reporting, approval of deliverables, involvement of specific resources)? How can these needs or issues be addressed during planning or execution of the project?

After capturing the stakeholder information, I will generally sort the stakeholders by type (key stakeholders), and stake in the project. Sorting the stakeholders in a particular order helps to identify specific actions required based upon the information captured within the stakeholder analysis. Below is an example of the stakeholder analysis template that I utilize to capture stakeholder information.

I also summarize the key stakeholders utilizing the following four box matrix.

 

Low Interest

High Interest

High Power / Importance

Project Funding Approval

Project Advisors / Mentors

Project Sponsors

Steering Committee Members

Core Team Members

Low Power / Importance

Not relevant to the project

Extended Project Team Members

Subject Matter Expertise

 

How is Stakeholder Analysis Used to Manage the Project?

After spending the time and energy to capture and document stakeholder information, it is critical that you actually “do something” with it. Below are some of the very tangible activities that I rely heavily on the stakeholder analysis to complete.

  • Identify/Form the Core Team – Who are the key contributors required for the project? The stakeholder analysis provides information required to identify the individuals with the right skills and experience to effectively contribute to the project. This process also helps identify individuals that have a high level of interest in being involved in the project (for a wide variety of reasons).
  • Identify/Form the Steering Committee – Who are the individuals that will guide / govern the project? The stakeholder analysis provides information required to identify the individuals with the appropriate influence and interest associated with the project to make timely and solid decisions to resolve issues, manage changes, and approve milestones – keeping the project moving in the right direction.
  • Identify Additional Resources – Who are the additional resources required to contribute to specific deliverables or phases during the project? Similar to the core team, the stakeholder analysis helps identify additional resources that are required to successfully complete specific deliverables or project phases (based upon particular skills, and/or interests in the project). Important resources that fall into this category are the subject matter experts (SMEs).
  • Identify Other Actions Required – Based upon information captured during the stakeholder analysis are there other actions or activities that should be built into the project plans? These may be actions required to address specific issues / concerns that the stakeholder has about the project, or specific requirements they would like to be addressed throughout the project life cycle (e.g., status updates).

Your comments are very much appreciated. When and how have you performed stakeholder analysis? What has been the impact of stakeholder analysis on the overall success of the project?

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?