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?

With Project Server 2007, I think Microsoft demonstrated a bigger commitment to Project Server and really started to move up in the still very competitive market. Project Server’s positioning continued to improve with Project Server 2010, but I sincerely believe with the latest release (Project Server 2013 and Project Online) Microsoft is going to emerge as one of the leaders in the EPM tools space. In my opinion, Microsoft has addressed most of the functional and usability issues, and they now have the most compelling story around providing a scalable project management platform. This platform can be leveraged to drive tangible benefits through improved project team collaboration, as well as more effective management and measurement of project performance.

Project Server 2007 & 2010 Gains Ground

The following are the improvements associated prior releases of Project Server that set-up this platform to emerge as a leader with the release of Project Server 2013 and Project Online:

1. Integration with SharePoint – The Project Server platform was migrated to leverage the capabilities of the SharePoint collaboration platform. To me this was the biggest decision that Microsoft made that enabled them to improve the positioning of Project Server. The integration of Project Server into the SharePoint platform enabled significant flexibility within the already strong schedule management application (e.g., enterprise views, custom fields, and workflows). In addition, the integration provides the ability to provision and access team sites, configured to reinforce the organization’s project management best practices, from within the Project Server application. The most powerful aspect of this integration is that each Project Server release by default takes advantage of on-going improvements / enhancements to SharePoint.

2. Resource Management Capabilities – Enterprise-wide resource planning and utilization is one of the most challenging business problems solved by Enterprise Project Management tools. As a result of exposing resource loaded project schedules to the enterprise, the organization can improve visibility of resource demand. The capability to display a graphical representation of resource demand by resource, resource type, and project is impressive within Project Server. These capabilities include the ability to “drill down” to task level details associated with resource demand.

3. Streamlined Time Reporting – Creating a timesheet and updating task status in past versions of Project Server was cumbersome. As a result this function was a struggle to roll-out across the enterprise, and even more difficult to drive compliance / adoption. With Project Server 2010 this function is both streamlined and flexible based upon the specific time reporting needs of the organization. Time reporting in Project Server is also fully integrated in with schedule management processes to update / progress the project schedules in an automated manner (including configurable approval workflows).

Project Server 2013 is Ready to Compete

The following are the 5 key areas associated with Project Server 2013 that are very exciting to me, and I think will be leveraged to drive tangible improvements in an organization’s project performance:

1. Cloud Offering – With Project Server 2013, for the first time there is a true “cloud offering” for Project Server leveraging Office 365. This offering makes it much easier for small to mid-size organizations to start and scale out Project Server implementations. Also introduced with the Office 365 capabilities is the concept of Project Online. In simple terms, Project Online enables users to create and update project schedules without purchasing/installing the client software (MS Project Professional). This is a capability that could drive significant cost saving in the rollout of Project Server, but as a project manager I honestly would not be satisfied without access to MS Project Professional.

2. User Interface Improvements – The overall look and feel of Project Server 2013 is very slick. MS Project Professional and Project Server 2013 have fully implemented the Windows 8 look and feel. For the first time that I can remember, MS Project is on-par with the look and feel of the entire Office Suite of products. This is an intangible benefit associated with Project Server 2013, but I believe to be a very significant aspect of the ability to drive market acceptance of the product.

3. Lightweight Project Management – Project Server 2013 provides project managers with the option to use a SharePoint list to manage project tasks (vs. creating a project schedule using MS Project functionality). This capability addresses the argument that “I am managing a small project with a limited number of tasks, and MS Project is overkill and too difficult to use.” It also enables the ability for all team members to easily update the project tasks. This new feature was implemented in a manner that most SharePoint users will already be familiar and comfortable with.

4. Consolidated Task Management – One of the most significant functional improvements of Project Server 2013 is in the area of task management. The “My Tasks” feature provides a consolidated view of tasks from multiple sources (MS Project schedules, SharePoint task lists, and Outlook tasks). The new task management capabilities also provide consolidated views for task managers to review and assign tasks received from multiple sources (e.g., project task lists, project schedules, and customer support requests).

5. Demand Management Upgrade – Project Server 2013 expanded on the ability to capture project ideas, and manage project proposals through the project intake process (using SharePoint workflows). These capabilities include the ability to create views of the proposals in the pipeline. Although this area represents a step in the right direction, I still feel that “out-of-the-box” Project Server’s portfolio management capabilities fall short of other solutions.

I hope you share my enthusiasm for Project Server 2013 and Project Online. I am sincerely looking forward to future opportunities to engage with clients to implement Project Server 2013 and Project Online to upgrade their project environment.

“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?

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?

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

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.

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.

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.

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?

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?

If there is more to project success than delivering within the boundaries of the triple constraint (time, cost, and quality/scope), how do you judge if a project is successful? In my experience these measures are a good start, but they do not portray the “total picture”. Project success should also take into consideration the impact the project has on the organization, the processes utilized to deliver the project, and how customers feel about the project outcomes.

This post covers my thoughts on what should be considered when defining project success, as well as the project manager’s accountabilities and responsibilities related to project success.

What does success look like?

In the context of project delivery, success is generally defined in terms of attainment of predefined goals. Projects are often judged to be successful based upon more than just the goals/objectives established in the project charter or project management plan – project managers lament this fact. Below are factors I consider when assessing project success.

• Time & Cost – Is the actual project delivery date and cost less than the baseline delivery date and cost (also taking into consideration the impact of approved changes)? Time and cost are the success factors that project managers talk about the most. These are the factors that project managers are directly responsible for managing. In addition, these success factors are relatively easy to measure and report on.
• Scope – Did the project deliver the “what” was expected to be delivered? Scope is not limited to the product features and functions. Scope also includes the deliverables that ensure that the product is properly implemented and supported. I have seen my share of projects viewed as failures due to the lack of attention to deliverables such as training, product marketing/adoption, and support processes.
• Quality – Does the product delivered perform the function it was intended to perform? Many project teams fall into the trap of judging product quality solely based upon the number of defects identified. All it takes is one or two defects to prevent the product from performing as intended. Quality related success measures should be judged based upon the ability to achieve operational goals (e.g., number of transactions processed, average calls per hour), as well as the ability to respond to product related problems.
• Process – Were processes consistently and effectively utilized to deliver key elements of the project? Processes such as change control, communications, and resource management can significantly influence the perceived success of the project. The predefined goals of the project may have been achieved, but if it was delivered without collaboration or with limited flexibility, stakeholders may not view the outcomes in a positive manner.
• Significance – Has the project delivered had a positive impact on the organization? Should projects that have limited or no impact on the organization be considered a success? As a project manager, you may say, “It is not my fault the project has not delivered the desired benefits to the organization.” This may be true, however I have seen many examples of projects where what was delivered, or how it was delivered, had a direct impact on the benefits realized. I have also managed projects that were delivered late or over budget, but delivered benefits that far exceeded expectations, and therefore were considered a success.
• Stakeholders – Are stakeholders happy with the project outcomes? Stakeholders are the people that were involved in or impacted by the project. It is a problem if the overall stakeholder community, or large segments of the stakeholder community, do not speak positively about the project. Feedback can be a very subjective measure of success, but I do believe that how people “feel” is a valid component of the success of the project. In most instances, specific actions can be taken to change the nature of feedback received from stakeholder – do not take this feedback too lightly.

6 ways you can improve the success of the project

I am a firm believer in the fact that the project manager role significantly influences the success of the project. Below are six project management best practice areas that have a direct impact on the success of the project.

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. Getting the “right” people engaged in the “right” roles has a significant impact on the project teams’ ability to meet the needs of the organization.

2. Baseline Plan – As a project manager you are introduced to new situations all the time (new clients and new projects), and it is extremely important to hit the ground running leading project teams through the planning process. Adapting a consistent planning approach from client to client, and project to project, significantly improves outcomes of the project planning process (both time to market and quality of the plans). Strong baseline plans represent the foundation for a successful project delivery process.

3. Measure Project Performance – This best practice area 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. Effective use of project performance metrics helps the project manager identify and implement
the appropriate project delivery adjustments before they become “big problems” that stakeholders are not quick to forget.

4. Collaborate – Stakeholder engagement in project activities has a significant impact on how people feel at the end of the project. Project managers enhance the collaboration on a project by facilitating effective team meetings, implementing collaboration processes & tools, and providing consistent and useful project updates.

5. Manage Change – 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 level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

6. Close the Project – At the end of a project, many project managers are busy 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 and key product issues closed, and smoothly transitioning resources to new roles. The second aspect of this best practice area is preparing the project performance report (also referred to as the post-project assessment). Creating the project performance 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 significantly influence stakeholders’ perception of project success.

Your comments are appreciated. What is your experience with judging project success?