PM-Foundations – Is my project funded?

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

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

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

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

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

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

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

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

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

The Project Budgeting Process

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

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

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

Capital vs. Expense Project Costs

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

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

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

Project Funding

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

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

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

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

 

 

PM-Foundations – 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?

PM Foundations – Managing Change

In my experience as a project manager, I have found one of the most critical best practice areas during the project execution phase to be the ability to effectively 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. Nobody wants to be “that” project manager that leads a project that delivers on-time and under budget, but still has an unhappy customer. Below I describe in more detail the following aspects of managing change:

  • What defines a change in the context of your project
  • What are the sources of change
  • What are the early warning signs of change
  • Establishing a process to manage change
  • Measuring the cumulative impact of change

What Defines Change

By the end of the planning phase, the project baseline is established and approved by the project sponsor and project core team. Project scope, schedule, and cost are all part of the project baseline plan. A change represents a permanent deviation from this baseline plan. The term ‘permanent’ is important. It is possible that there is a deviation from the baseline plan that will be self-correcting and is really only a deviation due to timing (when something has occurred vs. when it was planned to occur).

  • Example of a timing deviation: A deliverable that was completed a week late because the sequence was switched with another deliverable.
  • Example of a permanent deviation: A deliverable that was completed a week late, because it took a week longer than anticipated to be completed (and that week cannot be recovered).

Change is identified and measured based upon the impact on the baseline plan:

  • Scope – Additions/reductions in scope can be either in terms of scope of the product or project – in both cases they change the deliverables articulated in the WBS.
  • Schedule – Planned timing of activities and/or deliverables. In most cases, changes to the schedule are only identified / managed if they impact the project end date or a major milestone.
  • Cost – Addition/reduction to the cost of the project (permanent variance of actual/projected costs vs. planned/budgeted costs)


The following guidelines associated with changes to the project are detailed in the Project Management Plan:

  • There is not one standard definition of a change. Change must be articulated in the context of the specifics of the project. It is important to distinguish between a change and a clarification of expectations.
  • Only changes that have material impacts to the baseline plan will be formalized and managed (the Project Management Plan defines materiality).
  • How the change is determined to be a permanent or timing project impact.

Sources of Change

During project execution, actual events will occur differently than planned, even with the best of plans. It is up to the project manager to proactively identify and manage potential sources of change, and adjust the project plan appropriately. The sources of change generally fall into the following categories:

Customer Needs / Requirements – Adding a product requirement is a common source of change.

  • Adding or changing a product requirement during the middle of development / build / test activities can have even more impacts because of re-work and impacts to other parts of the product.
  • Often the change represents more of a clarification of the original requirement, and not a change in the intent of the requirement. The clarification could still represent more or less work to be completed to satisfy the product requirement.

Technology

  • Implementation of new technology introduces a certain amount of risk / unknowns. During project execution these unknowns may introduce real changes in the work required to complete the implementation (e.g., hardware procurement and set-up, software configuration & customization).
  • An organization’s standard technology platforms may change. If the work required to comply with the new standards is not reflected in the plan, it often represents a change to the project.

Planned vs. Actual Execution – The most common source of change is simply that work is completed in a different manner than originally estimated and planned. The following are more specific examples of this source of change.

  • Inaccurate estimates – Activities take more or less time than was estimated. This is more likely to occur if this type of work had not been done previously by the company or by the resources providing estimates.
  • Change in resources – The skill set associated with the resource completing the work is different that the skill set the estimates were based upon. Changes in resources in the middle of the project introduce factors like ramp-up time, the skill level of the new resource, availability of the new resource, the billing rate of the new resource.
  • Change in deliverables / activities – The addition of or removal of deliverables from the WBS can impact timelines, costs, and quality (e.g. adding training materials). Also, there could just be a process / methodology change that requires new tasks or a change to a task even though there is not a new deliverable. For example, if quality standards change, that could increase the time it takes to perform some tasks.
  • Sequence of work completed (project dependencies) – New or different project dependencies are identified during the project execution that could permanent delays in subsequent activities / milestones.

External Influences – Factors outside the control of the project team often drive changes to the project. Examples of this include:

  • Changes in regulatory or other compliance requirements
  • Changes in other systems / environments that impact the current project
  • Changes in dependent projects
  • Changes in the business environment or economy (e.g., introducing new funding constraints)
  • Reorganizations that drive changes in team members or key stakeholders (this would never happen, right?)

Early Warning Signs

In addition to understanding the potential sources of change for your project, it is also important to understand and monitor key project metrics that help identify potential (or real changes) early on (early warning signs). It is fairly intuitive that the further the project is in the project life cycle the more costly and impactful the change is to the project.


Some early warning signs of change include the following:

Schedule slippage

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

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

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

Open Risks and Issues

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

Change Control Process

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.

The following represent the key processes involved in managing changes to the project:

  1. Identify Change: Either the project manager identifies, or is made aware of a change. Based upon guidelines established in the Project Management Plan (permanent vs. timing, and materiality), the project manager determines whether or not the change should be formalized and assessed.
  2. Assess the Impact: Once the change is identified and it is determined the team needs to assess the impact of the change on the project, the assessment is documented, using a change control tool (i.e., a project impact report).
  3. Review and Approval: Once information about the impacts of the change have been documented, the change should be reviewed by a Change Control Board and either approved or rejected.
  4. Implementation and Verification: Planning and execution of the actions required to implement the change. Implementation includes adjustment to planning artifacts to accurately reflect the new scope, schedule, and budget based upon approved change. Implementation of the change effectively establishes a new baseline for the project.
  5. Follow-up Verification: Perform a follow-up review to confirm that the appropriate actions were completed to implement the change (corrective actions), and that the change had the anticipated impact on the project (time, cost, scope, quality, risk).

Remember that change is inevitable and oftentimes necessary. However, it is important to control change so that changes are properly assessed and only approved changes are implemented within the project.

Assessing the Cumulative Impact of Change

It is important to understand the cumulative impact of changes on a project with regards to the scope, schedule, and cost/ budget. Throughout the life of a project, there will be changes. The project core team, project sponsor, and steering committee members should be aware of the cumulative impact of changes (comparing actual project performance to the original expectations established in the baseline plan).

The project manager is ultimately responsible for project execution against the baseline plans. The project manager should be able to explain the evolution of that plan from the original baseline to the current baseline, including all approved changes that have been implemented. Project managers often will fall back on the excuse that the project is over budget or late because there were project changes, but they cannot quickly explain the changes that account for the primary deviations from the original plan. Effective use of the change control log (see my blog post on Using SharePoint to Manage Change Requests) provides a tool to track and reconcile changes to the baseline schedule and budget.

Reconciling the actual project performance (schedule & cost) to the original baseline plan helps understand the “unexplained” variances. An unexplained variance is the difference between the total schedule or cost variance and the approved project changes / impacts. A project with too high a percentage of unexplained variances is usually an indication of a project with inadequate attention to change control processes. These projects have too many changes that are “flying under the radar”. I am a not a big fan of the term “scope creep” because it represents an excuse vs. an explanation. Good projects managers can pretty precisely describe the difference between the original baseline and the actual results – strive to be a good project manager.

Characteristics of Effective Change Control

Be proactive. The cost of implementing change increases later in the project lifecycle. Utilize project metrics to monitor trends and identify potential changes.

The level of control and rigor around analyzing and approving changes should be appropriately “sized” to both the organization and the project.

  • Project size, complexity, and risk profile are evaluated to adapt the change control processes to the project.
  • If changes have different impacts when they are implemented (higher actual cost or schedule impact), maybe there is not enough rigor involved with the change analysis process.
  • Projects that place more importance on schedules and/or cost constraints tend to require more control around analysis and approval processes.
  • Another consideration associated with change control processes is the visibility / strategic importance associated with the project.

Provide visibility of the change request throughout the change control process. This ensures that everyone involved with the project can easily find out the current status of any changes in the process, as well as the reasons for approving or rejecting specific changes.

Focus on the making sure the change gets appropriately implemented. Project teams often spend all of their time and energy on analysis and approval, and forget to adjust project deliverables to reflect the change.

  • Follow-up to confirm the implementation steps have been completed.
  • Compare the actual impact on the cost and schedule to the estimated project impact.

PM Foundations–The Core Team

At the heart of most successful projects you will find an effective core team that is fully responsible for the day-to-day leadership of the project. This is not to be confused with the strategic level guidance that represents the key function of the project steering committee. The project manager is responsible for ensuring that the core team is effectively selected, on-boarded, and fully engaged throughout the project life cycle.

What is the purpose of the core team?

The practical answer is that the core team is responsible for monitoring the progress of each of the key deliverables and making decisions about course corrections should the project begin tracking behind schedule, over budget or if major scope changes occur.

What are the important elements of a good core team?

A good core team is comprised of the key stakeholders who are empowered to represent a segment of the overall project domain (the segment is generally defined based upon an organization or competency/function they represent). Representing this segment means that the core team member is responsible for providing knowledge from their area of expertise, and making/influencing decisions that impact this area of expertise. Several key factors influence the process of identifying the core team:

  • Diversity: Diversity is a key element of the core team, because it is critical that different perspectives about the project and the project deliverables are fairly represented on the core project leadership team. These perspectives should be represented from day one of the core team — many project managers are tempted to exclude groups from the core team until they are needed to perform specific project activities.
  • Inclusiveness vs. effectiveness: The core team is not the entire project team working on different project activities. Sizing the core team appropriately is critical to the successful management of the project. As the project manager you need to strike a balance between including the right people in the day-to-day management of the project, and creating a team that is too big to effectively make decisions. Based upon my experience the appropriate core team size is somewhere between 6-10 people.
  • Assessing the Organization: The type of organization you are working in significantly influences the manner in which the core team is formed (depicted in the chart below). In a functional organizational, it is generally the functional leads that represent their area/department on the core team. In a matrix and project organization, the core team is generally formed based upon the role of the people assigned to the project. The type of organization also impacts the project manager’s role and authority on the project (from limited in a functional organization, to full control in a project organization).

clip_image001

Procuring the Core Team Members

The factors described above represent key considerations when performing the following steps to select the core team:

  1. Determine which roles should be included on the core team. I find the most effective method is to look for the roles on the RACI chart with the most significant R’s (Responsible).
  2. Decide what project team members can fulfill these roles, If the team has not been formed, the question becomes what people in the organization can fulfill these roles.
  3. Determine if the composition of the core team needs to be adjusted based upon disconnects between the roles on the core team and the names assigned to the team.

The following chart provides an example of assembling a core team, based upon ownership of the key project deliverables. Ownership does not necessarily represent the person that will complete or manage the deliverable, but rather the person that will be responsible for the deliverable. Responsible means that this is the role that will ensure that the quality, scope, timing and cost of the deliverable are satisfied based upon the expectations established in the baseline project plan. Key deliverables which do not have an explicit owner established on the core team generally represents a RED flag (project risk), because the project manager will likely be required to manage these deliverables outside of the project leadership team as a “one off” process.

clip_image002

You will find that multiple people may be required to fulfill specific roles, if one person cannot adequately represent the full scope of the deliverable on the core team. In addition, specific roles may be filled by consultants or third party partners.

Getting stakeholders, functional managers and other resource managers to agree to loan you the right resources for your core team can be a challenge. Having a solid project management plan with high level milestones and roles/responsibilities, Project Sponsor support for the initiative, and clear definition of the deliverables (in the form of a WBS) to reference during the discussion with the resource managers makes this process much easier. When assembling the core team it is important to interact with the potential core team members to understand how well they understand the project – and how they feel about the business case (benefits, scope, target dates). It is a bonus to obtain resources that are passionate about some aspect of the initiative (benefits to their organization, learning opportunities for them, team dynamics).

On-boarding the core team

Prior to the overall project kick-off, the core team is assembled for a planning meeting (or series of planning meetings, depending on the complexity of the project). The planning meeting helps level set the core team on project planning efforts that have been completed to date (prior to them joining the team), and launching the efforts to complete the remaining planning activities/deliverables. The Project Manager facilitates the discussion on project planning deliverables completed to-date (project charter, milestones/target dates, scope statement, RACI, and the Project Management Plan). Making sure everyone is clear about what their role on the project is one of the essential topics at this point in forming the core team.

The Core Team planning meeting is best structured in the following manner:

Goals and objectives

  • Communicate information about the project using project artifacts created to-date
  • Establish a common understanding of roles and responsibilities
  • Begin the process of completing the remaining planning deliverables

Activities / Discussion Topics

  • Icebreakers and introductions (particularly important for new projects, with a diverse cross-functional team)
  • Review of project deliverables (best to provide access to these deliverables in advance of the meeting, so this time is spent productively covering questions and open issues)
  • Establish core team priorities and begin working on the remaining planning deliverables

Core Team Best Practices

The following summarizes the best practices associated with selecting, procuring, and on-boarding your core project team:

Purposefully select the core team

  • The team’s diversity in terms of backgrounds, perspectives and talents significantly improves project outcomes.
  • Right-size the team to accomplish the task at hand – manage the day-to-day project operations. Make sure the team can adequately “own” the project deliverables, but is not too large to effectively manage team dynamics.
  • The core team should be formed in a manner that is consistent with the organization that is driving the project.

Work with the right people to procure the right team members

  • Clearly communicate with resource managers (about the project and resource needs).
  • Use the project sponsor appropriately to gain support of the initiative.
  • Obtain buy-in of the potential core team members (to understand their commitment to the initiative, and comfort with their role).

Make the effort to adequately on-board and ramp-up the core team

  • Spend time “forming” the team.
  • Clearly communicate the plans completed to-date. You want the core team to “own” the plans, even if they were not involved in making all of the decisions or creating all of the planning deliverables.
  • Focus on getting immediate traction on the work ahead. Quickly align the core team with the project priorities, and ownership of next steps.