PM-Foundations – Planning & Conducting Effective Project Meetings

March 18, 2013 2 Comments

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?

Filed under Project Management Best Practices Tagged with , , , , , , , ,

Using MS Project to Manage the Critical Path

March 9, 2013 3 Comments

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?

 

Filed under Project Management Best Practices, Using MS Project to Manage Project Performance Tagged with , , , , , , , , , , ,

PM-Foundations – Using Earned Value to Identify Budget Variances

January 27, 2013 4 Comments

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.

Filed under Project Management Best Practices Tagged with , , , , , , , , , , , ,

PM-Foundations – Is my project funded?

January 12, 2013 5 Comments

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.

 

 

Filed under Project Management Best Practices Tagged with , , , , , , , , , , , , ,

PM-Foundations – That Will Leave a Mark

December 15, 2012 2 Comments

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?

Filed under Project Management Best Practices Tagged with , , , , , , , , , , ,

Using MS Project Server for Resource Management

November 1, 2012 4 Comments

One of the consistent struggles of working in a “standalone” project management environment is the fact that you do not have visibility of the “total picture” associated with resources. Resource loading in MS Project provides visibility of resource utilization vs. capacity on your project – not across all resource commitments (e.g., other projects and operational activities). You can utilize the “max units %” to reflect that a resource is something less than 100% available to the project, but this information is only relevant if it is regularly reviewed and updated.

In my opinion, the most significant benefit associated with Enterprise Project Management tools such as MS Project Server, is providing enterprise wide visibility of planned resource utilization vs. capacity. As a by-product of maintaining resource loaded project and operational schedules within MS Project Server, up-to-date resource utilization information is available in a very flexible and easy to access and consume manner.

 

5 Benefits of Using MS Project Server for Resource Management

1. Consistent definition of resources – Maintaining the Global Resource Pool in MS Project Server ensures that resources are defined in a consistent manner across all projects. Without consistency it is difficult to efficiently roll-up resource utilization information from multiple projects. Key elements maintained in the Global Resource Pool are:

  • Resource Name – It is important to establish a standard format for resource names (e.g., first name, last name).
  • Role – The role field provides the ability to view groupings of resources that perform a similar function across projects (e.g., Business Analyst, SharePoint Developer).
  • Base Calendar – The calendar field establishes the appropriate calendar for the resource (e.g., non-working days, working hours).
  • Generic Resources – The generic resource flag provides the ability to create generic resources that are utilized for resource loading purposes prior to assigning a named resource to the project.
  • RBS / Team Name / Department – MS Project Server provides a lot of flexibility to define the attributes/hierarchy specific to your organization (RBS, departments, and teams).
  • Booking Type – This field is utilized to establish the default booking type for the resource assignment. “Committed” represents a firm commitment/assignment to the project, and “proposed” represents a future/planned assignment.
  • Current Max Units % – Max units represents the % resources are available for work that is scheduled in MS Project Server. This field is utilized to calculate the resource capacity displayed on the resource availability charts.
  • Rate – The rate fields establish the standard and overtime rates utilized for costing / billing purposes.

Below is a summary view of the Global Resource Pool. Views can be tailored to meet the needs of your organization in the same manner that views are created in SharePoint.

 

Below are screen shots of the details captured for each resource.

 

 

2. Understanding resource availability across multiple projects – The Resource Availability feature in MS Project Server provides very useful views of planned resource utilization vs. capacity. These views display resource utilization for specified periods (days, weeks, months) for each of the schedules maintained in MS Project Server. The views are available in both chart and table format (depicted below). In addition, you have the ability to view utilization for a single resource or a group of resources.

3. Visibility of Firm vs. Planned Resource Commitments – Within the “build team” function, you have the ability to specify whether resources are loaded into the schedule as firm commitments (committed) or planned future assignments (proposed). The proposed booking type is utilized for planning resource utilization at a high level for future projects/periods.

 

The chart below depicts including proposed hours (in addition to committed hours) in the resource availability view.

 

4. Ability View Availability for Resource Groups – MS Project Server provides the ability to select groups of resources to view total resource utilization vs. capacity for a specific role (e.g., business analysts). This feature is particularly helpful when you have resources that are interchangeable across projects.

The chart below depicts resource utilization vs. capacity by resource for the selected periods (days, weeks, months).

5. Ability to “Drill Down” to View Resource Utilization – From the resource availability views MS Project Server provides the ability to “drill down” to view the detail task assignments for a specific resource or group of resources. The resource assignment details provide resource and project managers with the information required to resolve specific “peaks” or “valleys” in resource utilization.

 

3 Critical Success Factors for Effective Resource Management

The following are 3 factors that are critical to realize the benefits of using MS Project Server for resource management within your project environment.

1. Resource Pool – Data captured in the resource pool must be defined and captured based upon the resource management needs of your organization. This success factor includes standard naming convention for resources, logical structure of the organization and team hierarchy, and meaningful definition of the project roles. These decisions drive how data is displayed within many of the resource management views.

2. Resource Capacity – The capacity line is driven from the Max Units % maintained for each resource. This percent must reflect the availability of the resource to be scheduled on the projects and operational activities maintained within the MS Project Server implementation. For example, if MS Project Server implementation does not include system support activities, then the Max Unit % should be reduced to reflect the time allocated to these activities for each resource. A process should be established for reviewing and updating this information on a regular basis (I recommend monthly or quarterly).

3. Resource Loaded Projects – The information associated with planned resource utilization on projects and operational activities is only as good as the accuracy and completeness of the resource loading within the individual project schedules. This is a very obvious statement, but I have seen many Enterprise Project Management implementations fail because the resource data within project schedules did not reflect reality. Coaching and mentoring of individual project managers is often required to ensure that project schedules are resource loaded and updated accurately throughout the project life cycle.

Filed under Using MS Project to Manage Project Performance Tagged with , , , , , , , , , , ,

PM-Foundations – Implementing Project Management Best Practices

September 8, 2012 2 Comments

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.

What Do Best Practices Look Like?

Best practices represent the practical application of the concepts, processes, and tools defined in the PMBOK® and other sources of knowledge. To better explain best practices, below I have broken down the elements of a successful project management best practice implementation.

  • People – Best practices start with hiring good people – people that have the desire, capabilities, and core knowledge to be a professional project leader. When mentoring potential project leaders, I usually recommend pursuing the PMP certification path to validate that they have the base knowledge associated with the project management competency.
  • Concepts/Approach, Processes & Tools – Represents the components of the project management knowledge base utilized to define your best practices, including the knowledge created within your company’s project environment. This knowledge establishes approaches, processes, and tools associated with solving project management problems. The key is to leverage existing sources, and not spend too much time creating new content. This content should be upgraded on a frequent basis through on-going continuous improvement, in the context of completing work in your project environment (e.g., actions from a lessons learned process).
  • Critical Few – Best practices focus on the “critical few” areas that if performed well on a project significantly improve project outcomes. Organizations often “get lost” in building out elaborate processes and tools, when a limited set of best practices is what is required to deliver a project successfully.
  • Practical Application – Best practices are not theoretical or text book solutions. They represent approaches, concepts, and tools that have been consistently and effectively utilized in “actual” situations to delivery positive results on projects. If you cannot provide examples of the best practice in use then maybe you should consider dropping it from your arsenal of best practices.
  • Appropriate Situation – The best practices define the situations that specific approaches, processes, and tools are most effective. “One size does not always fit all” when it comes to use of best practices. The appropriate situation is learned over time, and through collaboration with colleagues and mentors.
  • Artifacts – Creating artifacts within the project office’s knowledge base converts something “done well” on a project into something that can be leveraged for future project efforts. Process documentation and templates are required to ensure that best practices can be implemented in a consistent and effective manner across all projects. I also find it helpful to maintain a library of examples (reference stories) of best practices applied to solve specific problems on projects.

Are these really the “Best” Practices?

One of the notions often challenged around the topic of best practices is that it may be a bit arrogant to propose that your practices are the “best”. There is generally more than one way to solve most project management problems, and very often one way is not significantly better than another. The goal is to consistently utilize project management practices that deliver positive project outcomes. Whether or not the practices are the “best” is irrelevant if they consistently drive the desired results. I use the term “best” practices because it is a term that seems to be understood across the industry, and represents an aspirational goal for the project office (vs. a factual statement).

What are the Benefits of Best Practices?

A thoughtful implementation and diligent application of best practices will drive tangible benefits realized immediately within individual projects, but more importantly by creating a project management culture and competency that consistently meets or exceeds customer expectations. The following represent specific benefits you can expect by implementing and re-enforcing project management best practices:

  • Results – The cornerstone of project management best practices is driving positive project outcomes. These best practices are utilized to ensure that quality products are delivered when they are supposed to be delivered, and based upon the estimated effort / cost to deliver it.
  • Ramp-up – Project managers will become productive leaders on new projects quicker, because they understand the key areas to focus on during the on-boarding process.
  • Productivity – An effective project manager will use and tailor existing approaches, processes, and tools, vs. building and inventing processes “on the fly”. Use of best practices increases the project manager’s capacity to take on more work (increasing their role on the project, or assigning them responsibilities on other projects).
  • Consistency – Consistency unto itself is not a tangible benefit. However, if projects are managed in a consistent manner it is easier for team members to engage in project work because project managers “speak the same language” (utilizing the same processes and tools) across the portfolio of projects. This consistency also improves the ability to integrate projects in a multi-project environment.
  • Continuous Improvement – Placing emphasis on best practices establishes a “baseline” for continuous improvement in your project environment. As teams identify new practices, or enhance existing practices (in the context of completing project work) it becomes natural for the project office to capture the improvement and incorporate it into the best practices utilized across all projects.

How do you Implement Best Practices?

Below are the steps required (not necessarily in this order) to implement a strong best practices centric project management culture in your project office.

  • Identify / Define – Identify the “critical few” best practices that if applied effectively in your organization drive positive project outcomes. Leverage existing resources (within the project management industry, and within your organization) to define these best practices. These best practices are defined in the form of approaches, processes, and tools.
  • Assemble Team – Build 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.
  • Train – On-going training on the best practices is a must. I recommend focusing the training on how to apply the best practices when performing project work. Therefore it is logical to organize the training around the project life cycle. I also recommend that ALL project managers (even senior level project managers) participate in the training – you will not achieve the desired results without getting “everyone on the same page”.
  • Re-enforce – How many times have you attended a training course that you thought was pretty good, and then you did nothing different when you got back to your “real” job? The best practice implementation must involve re-enforcement of the best practices. Our training involves a case study that requires team members to apply the practice in a real situation. Mentors are assigned to the participants to help coach them on the application of the practice, and ensure they really “got it” for effective use on future projects.

Filed under Project Management Best Practices Tagged with , , , , ,

PM-Foundations – My Favorite Project Management Slang

August 26, 2012 6 Comments

Part of my leadership style as a project manager is not taking myself too seriously. I find that creating a challenging and fun atmosphere on the team helps improve both teamwork and project outcomes. My use of project management slang is something that makes people smile, but also helps make a point in a not too serious manner. Below are a few of my favorite project management slang phrases, as well as some project management phrases that I do not like as well. For those of you that know me, you will recognize quite a few of these phrases, because I am not afraid to use them during daily team interactions.

My 9 Favorite Project Management Slang Phrases

1. In the Weeds – This occurs in team meetings when the discussion gets totally off topic. I see this a lot when the team tries to solve an issue rather than just identify the appropriate action items. This also can occur when a team member heads the wrong direction on a task, or attempts to make a task into something bigger than it was intended to be. “I think we might be in the weeds” is a nice way of saying we need to redirect the discussion or work to focus on the things that are required to keep the project headed in the right direction.

2. Arthritic Abandon – This phrase is definitely one of my personal favorites. Arthritic abandon occurs when teams seem to be working real hard, but are getting very little accomplished. A symptom of arthritic abandon is when team members talk about how busy they are, but you are seeing very little progress actually realized in the project schedule. This phenomenon usually points to the need to reassess how work is performed, or decisions made (e.g., too many meetings, or too many approvals).

3. Religious Discussions – I had a boss that said to me one day, “Do you know the difference between a terrorist and a methodologist? The answer is that you can negotiate with a terrorist.” His point was don’t waste time analyzing and discussing methodologies to get work done – select one that is appropriate for your project and use it consistently and effectively. Obtaining consensus on methods and processes is like trying to convert someone’s religious beliefs – it won’t happen. When I encounter a discussion where it appears that we have reached the core of people’s belief systems, I will make the comment that we may be in a bit of a “religious discussion” where there is no “right” answer. At this point you need to raise the discussion up a level, and agree on a path forward that is acceptable to the team (or if necessary mandate the path forward as the project manager).

4. Solving World Hunger – “Solving world hunger” occurs when the team is attempting to solve something that is too big. I use this phrase to encourage the team to break the problem down into components and identify actions items required to move forward. Another version of this phrase is, “I think we might be trying to boil the ocean.”

5. The Wedding Planner – I have several phrases that describe types of project managers. I don’t use these phrases to be mean, but rather mentor PM’s on adjusting their focus or behaviors. My personal favorite is the wedding planner. The wedding planner is more concerned with planning events (e.g., project celebrations, steering committee meetings, milestone reviews) than managing project outcomes. The wedding planner likes planning logistics related issues (e.g., meeting rooms, invitations, AV equipment and meals) more than resolving issues and completing real work. A couple other project manager terms that I have encountered are:

  • Clipboard Project Manager – This is the project manager that walks around and “checks” off tasks as they are completed. This project manager is usually so busy with the details that they do not notice when a major milestone is slipping.
  • Content Free Project Manager – The content free project manager wants nothing to do with understanding the product that is being delivered by the project – that is “not their job”. If you have ever tried it before, it is very difficult to help resolve issues or complete work with zero comprehension of the solution your team is working on.

6. Dog Knot – A dog knot is when project issues have brought progress on the project to a complete stop. This is also referred to as “gridlock”. Disagreements or confusion related to specific issues can cause teams to lose focus on the actions required to “move forward”. A dog knot situation usually requires intervention on the part of the project manager to facilitate issue resolution.

7. Pushing a Rope Uphill – This phrase refers to team members that are trying to do something that is very difficult, and is unlikely to have a positive outcome. The team member’s idea or effort does not fit well within the goals or strategy of the project or organization. A similar phrase is “going against the grain”. I will us this phrase to get team members to drop the idea or effort in the spirit of gaining consensus on the team.

8. This Dog Won’t Hunt – I was introduced to this phrase when managing a product development effort. When describing the lack of market acceptance for the product, the product manager said, “I don’t think this dog is going to hunt”. This phrase gently conveys the message that the project is delivering a solution that is not going to meet the project objectives. This phrase is used either to help the team decide on the appropriate corrective actions, or recommend to cancel the project.

9. Feeding Frenzy – A feeding frenzy refers to something that can occur in a team meeting. One person says something and it causes the team to go on a wild tangent. Generally the feeding frenzy is not positive (a lot of griping can occur in a feeding frenzy). I use the phrase in an attempt to get the team to calm down a bit, and refocus the discussion on the topic at hand.

Not My Favorite PM Slang Phrases

Here are the phrases that I am not as fond of. I don’t like most of these phrases because they are too negative about the project or the project team. The other reason I do not like some of these phrases is that they touch on aspects of the project that should be managed / solved by the project manager.

  • Scope Creep –Some project managers fall back on the excuse that the project is over budget or late because there were constant changes, but often cannot quickly explain the changes that account for the primary deviations from the original plan. Projects with too high a percentage of unexplained variances, is usually an indication of a project with inadequate attention to change control processes. In these cases, too many changes are “flying under the radar” and hence the use of the term “scope creep”.

  • 9 Women cannot have a baby in one month – This phrase refers to the fact that you cannot just “throw” more resources at a project to deliver on a target date. This phrase is not my favorite mainly because it is overused. I also do not like it because it infers that there are limited options that will fix the problems on the project, even additional resources. I believe the project manager is obligated to work with the team to find options to get a project back on track, especially when the sponsor is offering to help with additional resources.

     

  • Death March – The phrase “death march” refers to a project assignment that is doomed from the start due to unrealistic commitments/expectations (aggressive deadlines, under-funded, and short staffed). Referring to your project as a “death march” from the beginning of the project becomes a self-fulfilling prophesy. Honestly, I have never taken on a project that I felt was a “death march”. If the project commitments truly are unrealistic, the “facts” discovered throughout the planning process can be utilized to help reset expectations.

  • And then there was a miracle – This phase is used when the team feels that the only way a successful project outcome will occur is if something beyond their control happens. As a project manager, I like to believe that the team has been empowered to successfully deliver the project. To say that a “miracle” is required is in essence shirking responsibility for the project results, and/or conceding defeat/failure.

Filed under Project Management Best Practices Tagged with , , , , , ,

Using SharePoint to Maintain Project Archives

August 11, 2012 6 Comments

When working with clients on how to use SharePoint to improve their project environment, I am frequently asked about what should happen to a project site at the end of the project. This is a great question! With any luck, your projects will end, and therefore your project site will also have an end of life. The information captured on the project site throughout the project life cycle represents intellectual property that can be leveraged to improve future project delivery efforts and support future product releases. Decisions need to be made at the end of the project in terms migrating project information to a “permanent destination” and deleting the project site. These decisions are dependent on the type of project deliverable, and the status of the solution/product delivered by the project. The following are your options for migrating project information:

Project Site – If a there are plans to initiate another project associated with the solution/product, the information may be migrated to another project site. This situation applies when plans to enhance the solution/product are identified during the project closeout process.

Product/Solution Site – If the deliverables are linked to the product or solution, the information may be migrated to a product or solution related site (e.g., product support, or product development sites). Examples of this type of content are requirements documents, test plans & scripts, support & operation manuals, and training materials.

Project Archives – If the deliverables are tied to how the project was delivered, the content may be migrated to a project archive library (generally maintained within the PMO or Project Office site). Examples of this type of content include the project charter, project management plan, project schedule, project budget, risk/issue list, change request list, and the project closure report.

The main point is that purposeful action needs to be taken at the end of the project in terms of content migration. Project sites left unattended at the end of a project become irrelevant, and useful information that is not migrated to the appropriate location becomes difficult to find, and sometimes altogether lost. In my opinion, the project manager is responsible for making sure the content migration process occurs in a timely manner during the closeout phase of the project.

The focus of the remainder of this post is how to create and maintain an effective project archive document library within your project office site to facilitate storing and retrieving relevant project delivery information related to completed project efforts.

Moving Project Information

The administrative closure process should include the activities required to clean-up the project site, and migrate the site content to the appropriate location. To me this activity is just as important as facilitating the lessons learned session and creating the project closure report. The timing of migrating the project site content is important, because if it does not happen in the first 30 days after the project is complete, it is unlikely it will ever happen (after team members have moved on to new roles).

The first step in the content migration process is identifying the content that will have value to future initiatives. Old versions of deliverables should be purged, and interim work products should be deleted. Content maintained in lists are generally exported to Excel spreadsheets, and saved as a document in the new location.

In terms of physically moving the content from the project site to the new location, you have a couple options:

Save the document to the new location: Select the document, and the use the “Send to” option to move / copy the document to a new location.

Move the Documents Using Explorer View: Open up two windows, one with the current location and one with the future location. Change the view in both windows to Explorer view and then “drag and drop” the document from the old location to the new location. If you choose this option, you will need to utilize the “check in” function for each of the documents in the new location.

After the content is moved to the new location, delete the item in the old location, and add the metadata to the item in the new location (using the edit properties function).

Capturing Project Archive Data

As I explained in my blog on Using SharePoint to Organize your Project Deliverables, I do not recommend creating a Project Archive library with sub-folders for each of the projects or asset types. It is a best practice to maintain the Project Archive files in a single library, and capture metadata for each document that enables searching, sorting, and filtering of the files.

Capturing the following information for each document maintained in the project archive library enables storing and retrieving project archive information in an effective manner:

  • Project Name – Represents a look-up of project names maintained in the project portfolio list.
  • Project Asset Type – Represents a choice of valid types of project assets (e.g., schedule, budget, project management plan, project status report, project closeout). This could be a long list of individual types of project deliverables, or groupings of project deliverables.
  • Project Manager – Represents a look-up of resources in the project office resource list.
  • Fiscal Year – Text field utilized to capture the period (year or month) the project was completed.

The Rating setting is “turned on” to facilitate rating of documents maintained within the project archive library. This function makes it easier to find a “good” example of a specific deliverable from a previous project (one that another project manager has marked as a 4 or 5 star).

The following is an example of the process asset type choices utilized to categorize the types of project documents maintained in the project archive library.

Creating Views for the Project Archive Library

As in the case of lists that I have described in previous blog posts, SharePoint Views are used to display the project archive documents in the best manner for each target audience. Based upon the metadata created for the project archive deliverables, views allow you to sort and group the project archive document by project, project asset type, or period (year). The sorting and grouping provides the ability to find what you are looking for, without “digging through” folders and sub-folders.

Below is the Project Archive by Project view that groups all documents maintained in the Project Archives for a particular project. This view is utilized by people interested in researching or reviewing documentation associated with a specific project.

Below is the Project Archive by Asset Type view that groups all documents maintained in the Project Archives for a specific type of project asset. This view is utilized by project managers when locating a good example of a specific type of project deliverable.

Below is the Project Archive by Period (Year) view that groups all documents maintained in the Project Archives for a specific time period. This view is utilized by people reviewing project deliverables produced during a specific time period.

5 Ways to Ensure Project Archives are Useful

1. Clean-up – Prior to migrating content from the project site, perform clean-up of information maintained on the site. You want to limit the information migrated to content that will be of value for future reference or efforts. The clean-up effort includes deleting old versions of documents, purging interim work products, and migrating content maintained in lists to spreadsheets.

2. Timely – Establish project closeout processes that include ensuring that project site content migration is performed in a timely manner. If the project site content is not migrated before team members move to new roles, it may never happen and valuable intellectual property will become hard to find.

3. Organize – Utilizing metadata to organize your project archive library is a much more effective approach than creating sub-folders for each project or asset type. The use of metadata allows the project office to create views of information maintained in the project archive library that are tailored to the needs of specific audiences or use cases.

4. Views – Views can be tailored to meet the specific needs of your project community (using groups, sorts, and filters). The goal is to make it easy to find information that can be leveraged for future project efforts, enhancing the culture of continuous improvement.

5. Rating – Document rating is an excellent collaboration feature that allows people to “rate” how useful a specific deliverable was for them. This feature is particularly helpful for project managers attempting to locate a good sample project deliverable from a previous project.

Filed under Using SharePoint to Improve Project Delivery Tagged with , , , , , , , ,

PM-Foundations – The Project Charter

July 28, 2012 6 Comments

Every project needs to start somewhere. Someone in the organization identifies a new idea, a problem to be solved, or a business need to be fulfilled, and initiates the project through some form of communication to the group that manages the project initiation process. Depending on the organization and the type of project request, the initial communication has different names – project charter, business case, enhancement request, service request, or investment proposal (to name a few).

In my experience, the project initiation process is a critical component of the overall project delivery process because the time lost “up-front” identifying and formalizing new projects is seldom recovered throughout the remainder of the project life cycle. No matter what you call the document that is used to initiate the project, the process and content utilized to capture and approve the project concept will have a significant impact on time to market and reduce the number of “false starts” associated with new project requests. Consistent and well-understood project initiation processes and deliverables makes it “easier to do business” with the project delivery organization.

For purposes of this blog, I refer to the project initiation deliverable as the Project Charter. This is the term most commonly utilized within the project management community, and is often adopted as the name of the project initiation deliverable within organizations’ project delivery processes / methodologies.

Project Charter Content

The information captured within the project charter is utilized to provide a high level description of the project concept (business need or problem to be solved), and answer some basic questions utilized to justify approving initiation of the next step in the project delivery process (project planning and execution).

  • Why? Describes the goals and benefits of completing the project. A good project charter will provide a description of tangible benefits to the organization, including quantification of the potential range of benefits (optimistic – realistic – pessimistic).
  • What? Describes the high level scope of the initiative, and the key requirements associated with the request (often in the form of critical success factors).
  • Who? Provides a list of the primary person/organization requesting the project (the project sponsor), and the key people/organizations impact by the project (stakeholders). It is helpful to describe how the people/organizations are impacted (e.g., suppliers, subject matter experts, end users, customers).
  • When? Highlights timing related requirements associated with fulfillment of the project request (e.g., window of opportunity). In some cases, how the project request will be fulfilled is known, and the project charter provides key project milestones and target dates.
  • How? Describes what is known about the project delivery process. In many cases the project is not starting from a “blank piece of paper”. The project may represent an enhancement to an existing product or system, or the implementation of a product / technology that has already been identified or purchased.
  • How much? Establishes funding available to complete the project request (e.g., amount budgeted in the organization’s budget), and/or cost related parameters associated with fulfilling the project need. In many cases, the project charter will define a rough order of magnitude type estimate for completing the project (e.g., +/- 50%).
  • What else? The charter will include any additional information that is relevant to approving the project request and initiating the next step in the project delivery process (e.g., project assumptions or constraints). The project charter may also include an assessment of risks and issues associated with the project request.

Listed below are elements commonly found in a project charter. Many project charters include a summary section that “scores” the request based upon the initial estimates of benefits, costs, timing, and resources. This score is utilized to help evaluate the relative value of the request (compared to other requests) within the project initiation process.

Elements of an Effective Project Charter:

  • Background / Description
  • Goals & Benefits
  • High Level Scope
  • Key Product Requirements
  • Critical Success Factors
  • Proposed Project Delivery Process
  • Project Sponsor & Key Stakeholders
  • Cost Estimates / Targets
  • Target Dates / Milestones
  • Assumptions & Constraints
  • Known Risk & Issues
  • Score / Ranking

Project Charters do not need to be lengthy documents that represent a long and arduous process to complete. The specific content within the project charter should be tailored based upon the type, size and complexity of the project request. The project charter should be viewed by the customer of the project initiation process as an “enabler” vs. a “blocker” to launching a new project.

Who is Responsible for the Project Charter?

Ultimately the person or group that has identified the business need or problem to be solved is responsible for the project charter. However, in my experience, many areas of the organization do not have the experience, knowledge, or skills required to create an effective project charter. Their “best attempt” frequently does not adequately describe the business need, high level scope, or the best approach to fulfill the need. These project charters are often “hung up” in the project initiation process, requiring significant rework and additional justification prior to approval. Again, delays during project initiation are seldom recovered in the remainder of the project delivery process.

To solve for this problem, I recommend assigning a member of the project office to help the project initiator with gathering and documenting the information required to create a strong project charter. If the person assigned is also the person that is anticipated to be the project manager for the initiative (assuming it is approved), assisting the project initiator with the project charter will streamline the project manager’s on-boarding and ramp-up during the official project launch and planning processes.

6 Attributes of a Good Project Charter

1. Written – Although the initial idea may be communicated and vetted verbally, project initiation requires some form of written documentation to efficiently approve the request and launch the project planning effort. In addition, documenting the project charter enables collaboration of key stakeholders, and improvement of the end deliverable.

2. Objective – The project charter should fairly represent the perspectives of all key parties involved and impacted by the project request. Although the project charter is not intended to be a legally binding document, it is expected to be a reasonable representation of the anticipated benefits, as well as the estimated effort required to fulfill the request.

3. Explicit – A project charter should clearly and concisely communicate each of the key elements of the request – goals/benefits, timing, costs, risks/issues. Based upon the information known at the time the project charter is created, these elements should be described in detail, and quantified if possible. In many cases, the use of project assumptions enables quantification of benefits, costs, and timing. Project charters that contain ambiguous elements are often the source of contention and change during the project planning and execution processes.

4. Available – The project charter should be maintained in a location that is available to all stakeholders. Collaboration on the project charter improves the quality of the end deliverable. In addition, the project charter represents a deliverable that will continue to be referenced throughout the project life cycle, particularly during the project planning process.

5. Consistent - Establish a template for the content and organization of the project charter. Within the template describe how the content can be tailored based upon the size, complexity, and type of request. Best practices and lessons learned from previous projects are used to continue to enhance the project charter template.

6. Approved – As defined by the organization’s project initiation process, the project charter should be approved by the appropriate parties (including sign-off) prior to launching the project planning process. All project charters (in process, approved, and rejected) should be maintained in the project office’s project archives.

Filed under Project Management Best Practices Tagged with , , , , , ,

← Older posts

Follow

Get every new post delivered to your Inbox.

Join 168 other followers