PM-Foundations – Using Earned Value to Identify Budget Variances

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

Traditional Budget Analysis

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

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

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

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

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

Using Earned Value Techniques

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

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

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

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

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

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

When to Use Earned Value

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

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

PM-Foundations – Is your project a success?

Many project managers will proudly declare, “This project is a major success – we are delivering on-time and within budget.” When you take time to talk to some of the customers of these projects, you hear a much different story. In many cases, the customer’s version describes a product that was delivered that does not meet their expectations. In other cases, the customer’s version describes processes utilized to deliver the project that were not very collaborative or customer friendly. I refer to cases where you eventually achieve the goals of the project but stakeholders are generally not happy with the way you get there as “winning ugly”.

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?

Using MS Project Server for Resource Management

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.

PM-Foundations – Implementing Project Management 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.

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.

PM-Foundations – The Project Charter

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.

PM-Foundations – Why Manage a Project?

The other day I was at a client participating in a discussion on strengthening the portfolio management processes, when someone asked the question, “Do we understand what a project is?” This question made me smile. After all of this discussion, we don’t know what a project is, really? From my perspective it is best to keep the definition of a project very straightforward. A project is an effort to achieve a specific goal that has a definitive beginning and end.

 

When you break down this statement, the following are the important elements:

  • Effort – Projects require resources to complete. These resources generally include money and people. Therefore events that “just happen” are not considered projects (many refer to these as Acts of God).
  • Goal – The goal represents the desired outcome that the project is attempting to achieve. The goal is what defines the end of the project.
  • Beginning and End – The most important element of the definition of a project is that it is a temporary endeavor. Projects always have a beginning and an end (even if the end does not represent a successful outcome). The fact that a project is a temporary endeavor is what differentiates it from an operational process. Operational processes are repeated on a day to day basis to perform on-going business functions.

While most people can quickly agree upon the definition of a project, I think the more important question in the context of portfolio management is, “Which efforts should be purposefully and formally managed as projects?” Many project management enthusiasts would respond to this question with a passionate, “Everything, of course!” I would counter that projects can be managed as actions planned and executed within the context of operational processes. For example, I have seen many continuous improvement type initiatives successfully run “in-line” with the completion of operational work. From my perspective, the organization needs to define the efforts that should be separated from operational work, and managed as part of the project portfolio. This approach allows organizations to focus on achieving successful outcomes on the efforts that directly align with business strategies / priorities. Projects that do not fit in the project portfolio are either thrown out, or completed as part of performing normal business operations.

5 Guidelines for When to Manage an Effort as a Project

Below are my top 5 reasons to formalize an effort as a project, and manage it within the project portfolio.

1. Strategic Initiative – If an effort is tied directly to one of the organization’s key strategies or top priorities, it must be formalized as a project. These efforts need the visibility and rigor that a project provides to ensure the organization is demonstrating and communicating progress on its key strategies.

2. Requires Funding – Efforts that require additional funding / resources are difficult to run “under the radar”. The project initiation process facilitates the justification and approval of funds for these efforts. This process ensures that the organization is investing in the “right” initiatives.

3. Involves Opportunity Cost – An initiative may not require incremental funds, but involves a decision to reassign resources from another effort to initiate this effort. There is an opportunity cost related to stopping or slowing the other effort. Again, the project initiation process facilitates making decisions of this nature, and ensures that resources are working on the “right” initiatives.

4. Cross-Functional – Many efforts require facilitation of decisions and coordination of resources across different areas within the organization. Formalizing the effort as a project enables the level of coordination required to ensure its success.

5. Something New – When an effort is introducing something new to the organization (e.g., process, product, or technology) the effort needs a higher level of visibility to ensure the organization is prepared to accept and effectively leverage the new capability. Formalizing the effort as a project provides this increased level of visibility.

When do you need a project manager?

I feel obligated to discuss a related and somewhat controversial question within the project management community. When should a project manager be assigned to manage a project? From my perspective, all projects must have someone who performs the role of the project manager. I do not believe that projects will be consistently successful without someone that is formally responsible and accountable for what is delivered, when, and how much it costs. The question then becomes, when should the project manager assigned be a dedicated and fully qualified project manager, rather than a person that is performing the role as part of another role on the team (e.g., team lead)? Although I am of the belief that projects are generally more successful with a dedicated and fully qualified project manager performing the role, I do think there are projects and situations that can be successful without one. It is important to understand the project and situation when making the determination of who will perform the project manager role on the team. Here are some things to consider when selecting the project manager for your project.

  • Strategic – Is a key priority or strategy of the organization tied to the success of the project? If the answer to this question is “yes”, you should have a “real” project manager assigned to manage the project. It is common sense that a competent project manager will significantly reduce the risk of a challenged or failed project. Why put a key company priority at risk by cutting a corner on the project manager role?
  • Size & Complexity – As the number of deliverables and activities grows on an effort, so does the need for a qualified project manager on the project. The best indicator of complexity is the number and type of dependencies (both internal to the project, as well as dependencies on external activities or projects). An experienced project manager is going to do a much better job managing a large and complex project schedule, than someone who is performing the function as part of another role. In addition, an experienced project manager will more effectively manage the increased level of change that comes with larger and more complex projects.
  • Resources – Is the core team and stakeholder community cross-functional? Diversity on project teams helps drive better project outcomes, but also introduces challenges in terms of leading and controlling the project. An experienced project manager will more effectively establish and manage expectations on the cross functional core team and within the overall stakeholder community.
  • Cost – Is the cost of the project material to the organization (based upon impact on the investment portfolio or operating results)? Effectively managing a project budget is one of the most common areas that trips up an inexperienced project manager. Experienced project managers understand how to prepare a budget, forecast variances, and as required, implement corrective actions.

 

 

 

 

PM-Foundations – Using Progressive Elaboration

Have you ever been assigned a project that seems to be “stuck” in the starting gate? There are stakeholders that support of the project, but there are too many unknowns, and not enough funding, to get the project launched properly. Here are some of the usual characteristics of this scenario:

Benefits: The benefits have not been fully developed. Benefits have been identified at a high level, but measurable benefit targets have not been established, or committed to. Stakeholders feel that quantifying the benefits will be dependent on making significant product and project related decisions (requirements, solutions, costs, time to market).

Requirements: Requirements are at too high a level to be able to define the work to be completed. Resolving open requirements related decisions, and adding specificity to the requirements will have significant implications on timelines, work effort, and cost estimates. Stakeholders also feel that requirements will be influenced by the capabilities and costs associated with potential solutions.

Solutions: There are several options available to solve the business problem. The different options have a wide range of costs, capabilities, and effort/time to implement. Decisions cannot be made on the final solution until due diligence on the solutions options is completed, and the requirements are more fully defined.

Funding: Project sponsors feel that the project has strong management support, but funding cannot be obtained until the business case is developed. The management team feels that without the business case they will be signing a “blank check” with no commitment on the project ROI. For the business case to be finalized the team needs to understand more about the benefits, requirements, and solution options.

In this scenario you often feel that you are caught in a “chicken and egg” type situation – which comes first the benefits, requirements, solutions, or funding. The obvious answer is you need to go through the planning process to make relevant product and project related decisions, and establish the baseline plan. However, given this scenario there are still several challenges with getting the planning process launched:

  • Based upon the significance of the unknowns at the starting point of the project, there are a wide range of outcomes from the planning process – benefits, requirements, solutions, costs, and time to market.
  • Due to the size or complexity of the business problem, the planning process represents a significant effort.
  • Funds or resources are not approved to complete the planning effort.

What should you do? This situation represents a great opportunity to apply progressive elaboration techniques (also known as, rolling wave planning). The PMBOK® describes rolling wave planning as a progressive approach to detailing the project management plan, where planning and supporting processes are completed in an iterative and on-going manner. This means that you plan to define and refine the project management plan beyond the initial planning process – completing project work to turn an unknown into a known, and updating the plans accordingly. Below I discuss several tips to using progressive elaboration to effectively launch & plan your project, and manage stakeholder expectations.

An aside on the analogy of “peeling the onion” to describe progressive elaboration: Completion of the project planning process is utilized to remove the surface layers of the onion. In many projects you are able to quickly cut through a cross-section of the onion and get a clear picture of the onion layers (future project work). In other cases, due to the complexity / size of the business problem, you need to “peel back” many layers of the onion before you are in a position to cut through a cross-section of the onion to understand the full scope of the product and/or project. This is the situation where progressive elaboration represents an effective project delivery technique. There are things you can do as a project manager to effectively manage stakeholder expectations during the process of “peeling the onion” using progressive elaboration techniques to establish an effective project delivery approach – no need for tears during this process.

6 Tips on Using Progressive Elaboration

1. Plan what you know – The place to start is to develop detailed plans (scope, schedule & cost) for the work that is required to better define the product and project. Many people would refer to this activity as the “plan for the plan”. This initial planning effort may require a single iteration or several iterations to complete, depending on the size and complexity of the business problem to be solved. Developing this portion of the plan allows you to talk to project sponsors about what it will take to make key product and project decisions, and develop a baseline plan. This plan will include many of the following key deliverables:

  • Business requirements
  • Solutions Analysis
  • Solution Selection
  • Project Management Plan (project schedule, project budget, project scope)
  • Business Case (project ROI)

2. Use Planning Components – Decomposition of the plan will not be possible for all deliverables or components of the project (sub-projects) for future phases. Planning components are inserted into the WBS to depict deliverables or sub-projects that cannot be decomposed to the work package level. The planning components represent “placeholders” for the project areas with significant unknowns. Without planning components it is not clear to stakeholders the areas where additional work will be added to the plan upon completion of the initial phases of the project. It is difficult for stakeholders to visualize deliverables and sub-projects that are “missing” from the initial plan.

3. Establish a timeline & a rough order of magnitude – One of the problems that stakeholders have with progressive elaboration is that they are uncomfortable investing in “up-front” work without having any visibility of what the “end game” looks like. Inserting planning components to depict future phases, and assigning rough order of magnitude type estimates (-10% / + 50%) helps establish an early perspective of the overall project plan (timeline and cost). This approach creates angst for many project managers because they believe that once an estimate is presented (no matter how preliminary it is), it is the date or cost that stakeholders will remember. My response to this concern is that there will be many situations where the stakeholders will not give you a choice but to present the “entire” picture. When I put together a plan in this scenario, I clearly depict the timeline and budget in two buckets: 1) what is known vs. 2) what is unknown. I will also clearly articulate the difference in level of precision associated with the two buckets.

4. Insert meaningful milestones – Milestones always represent a key component of a good plan because they highlight key events or achievements within the plan (e.g., approval of key deliverables, completion of project phases). With the use of progressive elaboration, milestones take on new meaning and importance. They represent points in time when the project team will have more information, and plan to make adjustments to the project plans. In most cases, there will be a milestone that establishes when the project baseline for the entire project will be completed and approved.

5. Get funding for the first “wave” – The key to the initial planning effort is to clearly articulate the scope, timing and cost associated with establishing the plan for the entire project. Your goal as the project manager is to obtain the funding for the “up-front” effort, and approval to launch the project. Before the project will be funded and launched you must convince key stakeholders of two things:

  • Based upon what we know today, this project has enough merit to invest in an “up-front” planning effort.
  • The “up-front” effort will be successful based upon the information detailed in the project management plan (scope, schedule, cost, and project management approach).

6. Progressive elaboration in an Agile delivery model – By definition, rolling wave planning represents an iterative approach. Therefore, this approach can be adapted well to an agile delivery model. Many agile teams refer to the “up-front” effort as “Iteration 0”. During “Iteration 0”, the team defines, priorities & estimates the product backlog, creates the initial product roadmap (articulating the initial content of each sprint), and plans the first sprint in detail. At the end of each sprint, the agile team will continue to use progressive elaboration techniques to re-prioritize the product backlog and adjust the product roadmap.

PM-Foundations – 10 Steps to Create a Strong Baseline Plan

When interviewing project management candidates, my favorite interview question is: “When you are assigned to a new client/project, what is the process you utilize to establish the baseline project plan?” Some candidates lose points immediately because they describe a process where the baseline plan is equal to the project schedule. Many candidates start out pretty strong talking about identifying stakeholders and defining business needs, and then get lost on a rambling dialog through the entire project life cycle.

I like this question so much because 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.

10 Steps to Create a Strong Baseline Plan

  1. Ramping-up – The first step is to learn everything you can about the new project. In most cases, you are not starting the project with a “blank piece of paper”. Take the time to read through existing project artifacts, and meet with interested parties. The focus of this step is absorbing everything you can about the new project, and understanding where you are starting from in the project initiation process. The key to this process is active listening and observing — it is amazing how much you can learn when you are not doing the talking.
  2. Understanding the Stakeholders & Forming the Team – The next area of focus is starting to identify the project stakeholders. Throughout this process you are trying to understand the people that have a strong interest in –or- impact on the project. This is the point in time when you begin to form a high performing core team and a helpful steering committee (you can read more in my blog on the core team).
  3. Developing the Business Case – As the project manager, you can be the strong partner that facilitates improvement and finalization of the business case (aka, the project charter). With your fresh and unbiased perspective on the project, you can add significant value by ensuring that the key components of the business case (e.g., objectives, benefits, assumptions, high level requirements) are explicit, understood, and achievable.
  4. Creating the WBS – The Work Breakdown Structure defines the scope of the project by breaking the work down into components that can be scheduled and estimated and easily monitored and controlled. A well-constructed WBS represents the most effective way to define and validate the scope of the project (what deliverables will be produced). The project manager’s role in this step is to facilitate the organization and decomposition of the work required to successfully deliver the project, in the form of the WBS.
  5. The Project Timeline – The focus of decomposition in the context of activity definition is identification of the specific actions / activities that will be required to create the deliverables that were defined within the WBS. The Project Manager also works with the team to establish the relationships between project activities. The key to creating a logical flow (organization) of work within the project schedule is the definition of these relationships/dependencies (you can read more in my blog about managing project dependencies). The final component of this step is the process of determining how long it will take (in days) to complete an activity, or a series of activities (duration estimation). At this point in time, the project schedule starts to reflect a timeline with project milestones. This timeline is utilized to validate the reasonableness of previously established target dates (or establish target dates if they do not already exist). It is important to keep in perspective that at this point in the process you are trying to arrive at a first cut of the project timeline, and not create the final project baseline (in the spirit of an iterative process) – you are looking for reasonableness, not perfection.
  6. Resourcing the Plan – The Project Manager builds on the project timeline by estimating resource requirements for each of the schedule activities, and loading specific resource assignments and work efforts into the project schedule. At this point in time the project manager will also perform resource usage analysis and leveling techniques, and create the project staffing plan (you can read more in my blog about performing resource analysis and creating the staffing plan).
  7. Finalizing the Project Schedule – After resources are loaded into the schedule, the project schedule is for the most part fully formed. At this point, it is best to perform a final review of the project schedule (individually as the project manager, and also with the core team). The goal of this review is to determine: 1) Can the team deliver with this schedule? Are there opportunities to improve the schedule? 2) Is the schedule well understood? Are all aspects of the schedule fully documented?
  8. Finalizing the Project Budget – The step of finalizing the project budget is focused on efficiently leveraging the planning assets created to this point in the process, and performing the appropriate level of analysis to develop a project budget that will be understood and approved by the client, and just as importantly can be managed throughout the project life cycle. This step includes creating the labor budget, understanding other cost components and reconciling the project budget with project funding (you can read more in my blog about creating the project budget).
  9. Finalizing the Baseline Plan – The step of presenting the baseline to the Steering Committee is one of the most exciting times in the project planning lifecycle. If you have tied up loose ends with key stakeholders, sponsors and core team members, you are well prepared to bring the project baseline (scope, timing, and budget) to the project executives for approval. This meeting/briefing represents a key gate for moving forward with the project.
  10. Transitioning to Project Execution – As a project manager, you often rely as heavily on your “soft skills” as a project leader, as you do on your core knowledge as a project manager. This is particularly true during the transition from project planning to execution. It is the time period when you are on-boarding the entire project team, and moving from “planning the work” to “doing the work”. As you make this transition, you must establish a good rhythm on the project team (you can read more in my blog about establishing project rhythm).

Where do I go from here?

These steps are not a detailed prescription or specific recipe for project success, but they do represent a proven approach to move a team effectively and efficiently through the project planning process – from the time you are assigned as the project manager, to the time you begin the execution phase of the project. If you are able to describe this approach during the on-boarding discussion with your new project sponsor, you are likely to begin to establish credibility as an experienced and competent project manager. In addition, if we do happen to cross paths in an interview situation, you now have the input required to get you through the initial screening process.

10 Project Management Terms Customers Love to Hate

As I was starting to write a blog on creating a well-organized WBS, I was reflecting on the fact that the WBS is a term/activity that customers often do not understand or appreciate. That got me thinking about all of the project management terms and processes that customers do not like or appreciate. The other day a client said to me, “You talk like a project manager”. Given that I am a project manager, I took this as a compliment (although it may or may not have been intended that way). However, in the role of a project manager you are responsible for leading teams and building relationships, and certain project management terms and processes can disrupt team dynamics and ultimately impact the team’s performance. All of the terms I discuss in this blog are part of doing our job as a project manager, and the customer’s negative perception associated with these terms is usually a function of how they are applied during the project delivery processes.

Top 10 Project Management Terms Customers Hate

  1. Work Breakdown Structure (WBS) – The scope of the project is the most difficult component of the project baseline to define and describe. The Work Breakdown Structure (WBS) represents a best practice area to effectively confirm/validate the scope of the project. The WBS is a deliverable-oriented hierarchy that defines the work of the project and only the work of the project. The WBS breaks the work down into components (work packages) that can be scheduled, estimated and monitored & controlled. Due to a lack of experience and understanding of the WBS, customers do not always place value in the process of breaking down and organizing the project deliverables. They often view participation in facilitated WBS sessions as tedious and painful.
  2. Target Date – The customer’s irritation with the use of the term target date is generally their perceived lack of commitment to a date (project completion, or interim milestone). In most cases this can be overcome by explaining that the team’s commitment will be achieved as soon as the date is supported by an approved project plan (scope, schedule, resources, and budget). It is definitely a good practice to clarify when a date represents a target date vs. a committed date supported by the project plan. Upon completion of the project plan, I will highlight gaps between target dates and planned dates, and provide alternatives to “close the gaps” as part of finalizing/approving the plan.
  3. Progressive Elaboration – Progressive elaboration is a term and process that some project managers are not familiar with, let alone customers. Progressive elaboration is tied to the concept of “rolling wave planning”, where short-term milestones are planned in more detail than future milestones. As the project progresses, the work associated with future milestones is “elaborated” and planned in more detail. This practice works well with iterative project delivery approaches, but makes customers uncomfortable because “up front” the timeline, budget and scope are not fully developed. In these cases it is important to establish high level scope, schedule and budget expectations that the project team manages within. This is an extremely effective practice, and customers gain confidence in it when team utilize it well to streamline project delivery processes and reduce the overall time to market.
  4. Assumption – Assumptions are things that you believe to be true which may not be true. Assumptions help you clarify the thought process behind project plans. They also make it possible to get beyond seemingly impenetrable roadblocks during the planning process. Every project has a certain number of unknowns. If we waited until everything was known, a project would never get started. Customers get the most annoyed when assumptions are utilized as a CYA. I hate it when I run across assumptions like: “We have enough resources to complete the project.” –or- “The client will be available to approve the deliverables.”
  5. Constraint – Constraints are factors that limit options such as resources, budget, schedule, or scope. Constraints help teams clarify the “boundaries” that they must work within. At times teams utilize constraints inappropriately to define the project boundaries, and unnecessarily constrain the project delivery approach. Customers can view constraints as “excuses” for why it is not possible to meet customer expectations.
  6. Scope Creep – Honestly, this is not a term that I am too fond of myself. The project manager is ultimately responsible for project execution against the baseline. The project manager should be able to explain the evolution of that plan from the original baseline to the current plan, including all approved changes that have been implemented. 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”.
  7. Baseline – Upon completion of the planning process, the team establishes project delivery expectations (scope, schedule, and budget) that are called the baseline plan. They execute against the baseline plan throughout the project life cycle. The baseline is utilized to measure the team’s ability to deliver against these expectations. In addition, the baseline is updated throughout the project life cycle based upon approved changes requests. Customers’ difficulty with the baseline is that it is not always clear when the baseline has been established (the transition from project planning to execution is not well defined or communicated). In addition, teams do not always do a good job maintaining the baseline plan, and information comparing current plans to baseline plans is not helpful or relevant.
  8. Change Request – The overall goal of change control is to prevent changes from overwhelming a project or taking the project unnecessarily off track. The goal of change control is NOT to prevent all change. Change control enables proactive identification and management of change, in a manner that keeps the project moving in the right direction, towards successful completion/delivery. Effective change control maintains the appropriate balance between control/discipline to manage to the baseline plan, and flexibility to adapt the plans to meet customer expectations. Customers respond negatively to change control when this balance is not consistently maintained (too many changes vs. too inflexible to respond to change).
  9. Risk – All projects have some level of uncertainty and unknowns, and therefore an element of risk. The risk management process represents a best practice area focused on predicting, planning for, and managing events that might occur during the project (positive or negative) that would have an impact on project plans. Customers are apprehensive about risk management because it tests their “intellectual honesty” in terms of what “could happen” during the project. In addition, mitigation action plans are not always viewed as having a “real” effect on the reducing probability or potential impact of the risk.
  10. Contingency – Contingencies and reserves are utilized to recognize and mitigate risk inherent in the project schedule and budget. In many cases the plans do not clear tie the contingency or reserve to the risk it is mitigating. In addition, teams do not always do a good job of recognizing what events or actions have driven consumption of all or a portion of the contingency or reserve. For these reasons customers will equate use of contingency and reserves to “sandbagging” or “padding” within the plans.

What should I do?

The obvious conclusion that some people would draw from this blog is that these are terms and processes that you should avoid with your team and customers. That is not the take-away that I would recommend. These are industry terms that demonstrate your knowledge and establish credibility in your role as a project management professional. Of course, this assumes these terms are applied in the right situation and context, and supported by the right actions and approach. However, these terms should be applied throughout the project life cycle with an awareness of the audience (from the perspective of both the understanding and perception of your customers). When appropriate, clarifications should be provided to explain the concept behind the term (particularly the first few times you use the terms). You should also be aware of overuse of specific terms that are particularly annoying to your customers or team members (usually due to the customer’s past experiences on projects). These suggestions will help, but the real power associated with effectively leveraging standard project management practices is demonstrating in a tangible manner how these concepts and processes drive positive project outcomes. When customers see success based upon a solid project management approach, they truly appreciate the value of your industry knowledge and expertise.

Using MS Project to Manage Dependencies

The strength and integrity of your project schedule is built based upon the definition of deliverables and activities, the estimation of durations and effort, as well as the organization and sequencing of the work efforts. All three elements are important, but the one that I think project managers’ struggle with the most is organizing the deliverables and activities in a manner that reflects the way in which the work will actually be performed / completed. Organizing the work involves developing a work breakdown structure (WBS) that is arranged and decomposed in a structured manner, and sequencing the deliverables and activities based upon logical relationships (dependencies) between the deliverables and activities. This blog focuses on establishing and managing dependencies that are understandable and create a reasonable workflow. This discussion includes using project management tools like MS Project to efficiently define and managing dependencies within your project schedule.

Type of Dependencies

Understanding the types of dependencies inherent in the work that needs to be completed is one of the most important elements of creating a strong project schedule. There are 3 primary types of dependencies:

  • Mandatory Dependencies – These are dependencies that create firm relationships between two activities. Examples of this logic include:

    These two activities must be performed at the same time (starting and/or finishing at the same time).

    This activity cannot start until another activity finishes.

  • Discretionary Dependencies – These are “soft” dependencies that reflect how the team anticipates the work will be completed, or how the team “would like” the work to be completed. These types of dependencies enable the team to optimize the flow of work throughout the project life cycle. Most importantly, “soft” dependencies represent the tool that the project manager utilizes to create “float” in the schedule. This is a much more effective manner to drive the timeline than “hard coding” dates (artificial constraints) into the schedule. Examples of this logic includes:

    This activity will happen at the same time as another group of activities.

    This activity will start up a couple weeks after another activity is completed.

  • External Dependencies – These are dependencies that are outside the control of the project team, but nonetheless must be reflected in the project schedule. Examples of external dependencies include:

    Approval from an external organization must be received prior to starting an activity.

    Completion of a project milestone is linked to the completion of a milestone within another project.

Creating external dependencies within your project schedule can be accomplished in a couple different ways:

Insert a milestone that reflects the completion of the external dependency.

Insert a planning component (placeholder type task) that reflects the timing of the external dependency.

Link specific activities to activities in other project schedules (requires utilization of enterprise scheduling tools).

Dependency Relationships

Dependency relationships are utilized to link two tasks in the most logical manner possible. As in the case of dependency types, this relationship may represent a “hard” relationship (must happen in a certain manner) –or- a “soft” relationship (a relationship set up by the PM to establish a logical flow of the project activities). The valid relationships in MS Project are:

  • Finish-to-Start (FS) – This represents the default relationship in MS Project. If you do not specify the relationship, FS is assumed. This relationship is utilized to establish a sequential flow of work – this activity can start when the previous activity is completed.


  • Start-to-Start (SS) – This relationship is utilized when two activities will be launched at the same time. They may end at different times (depending on the duration of each activity), but they can start at the same time.


  • Finish-to-Finish (FF) – This relationship is utilized when the completion of two activities should be linked together. The two activities may start at different times (again, depending on the duration of each activity), but the completion of the two activities is coordinated.
  • Start-to-Finish (SF) – This relationship is seldom utilized (in 20+ years of using MS Project, I have never used a SF relationship).

In addition to establishing the relationship, predecessors and successors can be utilized to create leads (acceleration or overlap) and lags (delays or gaps) between schedule activities. Here are a couple examples of the appropriate use of lags and leads in the project schedule:

  • Lead: The technical design can be started after 75% of the requirements definition effort is completed. If the requirements represents a dedicated effort that will be completed over a 20 day period. The predecessor in MS Project for the start of the technical design would be reflected as: (n)FS-5D (where (n) represents the task number associated with the requirements definition effort).
  • Lag: The UAT test plans will be completed a week after the completion of the system test plans. The predecessor in MS Project for the UAT test plan would be reflected as: (n)FF+5D (where (n) represents the task number of the completion of the requirements effort).

Using MS Project to Establish Predecessors and Successors

Dependencies are created in MS Project using the Predecessor and Successor fields. The Predecessor is the task completed “prior to” the current task, and the Successor is the task completed “after” the current task. The dependency is entered with the ID of the Predecessor or Successor task, the Type of Dependency Relationship (FS, SS, FF, SF), and the Lag(+)/Lead(-) between the two tasks.

Below is an example of creating Predecessors and Successors within the MS project schedule.

Using the Predecessors & Successors Split view provides a good picture of the dependencies established for each task.

 

4 Tips for Effective Use of MS Project to Manage Dependencies

  1. Using Date Constraints – The most important take-away from this discussion is that establishing dependencies is the key to creating a logical flow (organization) of work within the project schedule. A “worst” practice is to hard wire dates (e.g., must start on, or must finish on date constraints) within the project schedule. As things change (and they inevitably will change) with regards to how the work is actually completed, these arbitrary date constraints quickly become inaccurate and difficult to maintain. They will impact not only the accuracy of the specific schedule activity, but also the accuracy of any subsequent dependent schedule activities.
  2. Using Summary Tasks for Dependencies – Another thing to avoid is linking dependencies to the summary tasks. During the first cut of creating the schedule, it may seem like a good shortcut if multiple activities are tied to the same set of activities, but ultimately this practice results in a schedule that is difficult to understand and maintain. All activities should be linked to specific activities, and not to summary tasks.
  3. Look for Activities without Predecessors or Successors – Activities should have both a predecessor and a successor, unless they truly represent the beginning or end of a project (or string of standalone activities within the project).
  4. Fully Leverage Dependency Relationship Capabilities – Dependency relationships (and leads/lags) are an aspect of creating a project schedule that should be well understood by the PM, and fully utilized. A project schedule that contains all FS relationships, and no leads/lags, is generally an indication that not a lot of effort has been put into understanding the activity dependencies, or the flow of the project work.