Project Initiation

Building Blocks of a Successful Project Part 4 – Human Resources

Professor of Project Management Project Initiation , ,

Initiation

The first step in obtaining your project’s human resource needs is to create a “Roles/Responsibilities” matrix. In the first column, you define the project roles required. For example “Project Manager”, “Business Analyst”, “Subject Matter Experts”. These are not job titles but roles defined for the needs of the project. The second column describes the scope of responsibilities for that role. The third column is the name or names of those people assigned to that role. The rest of the columns contain contact information, and the assignee’s department and manager.

The next step is obtaining the commitments for these resources to work on the project. I have seen many projects given the approval to begin without the commitment (or even awareness) of key stakeholders (business units that will have project task assignments). This leaves the Project Manager in the position of negotiating with the business units for resource time and priority. This is typically the result of lack of Project Portfolio Management and control of the project intake process, especially in regard to resource capacity.

A best practice in Project Management is to secure the resource commitments prior to the approval of the Business Case. This means doing a thorough stakeholder analysis of all of the roles and responsibilities needed for the project. A brainstorming session with those having a broad knowledge of the business functions can help identify key stakeholders.

The Executive Sponsor (with support from the Project Manager) is responsible for communicating with the affected business units and securing the commitments. If these commitments have not been made and the project is directed to proceed, then this must be handled using formal Risk Management (which will be addressed in a future post).

In addition to having committed resources, they must also be the right resources. They must have skills that match the assigned roles. If they don’t and you have no resource alternatives then your project must include a plan for skills development and your task estimates must take into account the skill levels of the task assignee.

For your “core” team (the small group that attends almost all meetings and contribute to planning) you must make sure they are empowered as decision makers. If your team is constantly saying “I have to get my manager’s approval”, your schedule may be significantly impacted.

Advertisement

Building Blocks of a Successful Project Part 3 – Executive Commitment

Professor of Project Management Project Initiation

Initiation

If your company actively manages its Project Portfolio, then this building block should already be in place. However, many companies begin new projects without any consideration of the impacts to projects already in progress or in the “pending” queue. This is the single biggest root cause to the Project Manager’s #1 headache: resource contention.

Before projects can begin, you should have satisfactory answers to the following questions:

  1. Are any existing projects competing for the same resources?
  2. If so, do these resources have the availability required for the new project?
  3. Where does this new project rank in the corporate priority?
  4. Is there a process in place to prevent the next new project from interfering with this one?

The answers to the above will tell you if you have Executive commitment for your project. Without it you will every day be at risk of losing key resources and jeopardizing your schedule.

The Project Charter – Stakeholders

Professor of Project Management Project Initiation ,

Initiation

Project Stakeholders are the people and entities affected or impacted in any way by the project. Defining this list is critical in communication planning. It will also help you in defining the project scope. Stakeholders are identified by reviewing the Project Scope and consulting with Subject Matter Experts for the domain of the project.

There are two classifications of Stakeholders:

  1. Those that will be needed to perform project tasks.
  2. Those that will interact with or receive the product, service or result of the project.

The Stakeholders in classification 1 are the members of your project team. Some of these will constitute your core team and will be needed full-time or near full-time for the duration of the project. Others will be needed only for specific tasks over limited periods of time. When you have this list I recommend creating a spreadsheet with these names along with their roles, responsibilities, manager, and contact information.

The Stakeholders in classification 2 are your project’s “customers”. These are the people who will be the target of a formal Change Management strategy (more on that in upcoming posts). The success of your project will often depend on how you manage communication and change with this group of Stakeholders. The five key areas for managing this group of Stakeholders are:

  1. Awareness – communicate early and often with this group before they are impacted
  2. Desire – impart an understanding of why this is good for them and for the company
  3. Knowledge – training in new processes and behaviors
  4. Ability – make them successful by setting up a support structure
  5. Reinforcement – monitoring the expected behaviors and business outcomes and being prepared to make adjustments as new knowledge comes to light

There are some Stakeholders that can be a member of both groups. Typically members of the Project Sponsor’s team will participate in the project and also be affected by the result.

The Project Charter – Timeline

Professor of Project Management Project Initiation ,

Initiation

The Project Charter should contain a high-level timeline so that expectations can be set and preliminary commitments established. If not enough is known at Charter time to be reasonably certain of this timeline, then it should be noted as to when the baseline schedule will be established.

The timeline will contain elements that depend on your organization’s methodology. You will want to note target completion dates for major milestones and phases. Here is an example for a software development project:

  • Requirements – Jan 31
  • Design – Feb 23
  • Development/Unit Testing – April 8
  • System Testing – April 30
  • User Acceptance Testing – May 21
  • Transition to Production – June 8
  • Production Stabilization – July 8

For projects not involving software, your phases and major milestones will be named according to the nature of the project. Here is an example where the project is to order and install new equipment in several locations:

  • Scope established – Jan 15
  • Products Ordered – Jan 30
  • Products Tested – Feb 21
  • Products installed in pilot locations – March 15
  • Products installed in all locations – June 1

The Project Charter – Scope of Work

Professor of Project Management Project Initiation ,

Initiation

At the Project Charter level, the scope of work is not meant to be all-inclusive and at a fine level of detail. That is done when detail requirements are addressed.

You can derive part of the scope by taking each Project Objective (refer to the post on Project Objectives for more detail) and listing the major work activities needed to accomplish that objective. These should be at a level of detail enough to get a high-level understanding of the effort and duration of the activity. This is a judgment call and varies by type of project.

In addition to the above, you can list the major business processes that are impacted by the project. A process is impacted if one of the following is true:

  • there will be new or changed process steps
  • there will be new sources of data or information for the process
  • there will be new recipients of data or information from the process
  • there will be changed or additional owners of the process.

Listing the major activities and the impacted processes should be sufficient for scope at the Project Charter level. Your organization’s standards may require more, but this should be the minimum.

The Project Charter – Project Objectives

Professor of Project Management Project Initiation ,

Initiation

Project Objectives are very different from Business Objectives. I have seen Project Charters with the two types of objectives mixed into one objectives section and I find it very confusing. I recommend placing Project Objectives in its own section.

Project Objectives should satisfy the following criteria:

  • Produce a product, service or result that survive and are maintained after the project is over. Some examples of this are (1) a new business “Standard Operating Procedure”; (2) new software installed that meets all of the acceptance criteria.
  • Have a definition of “done” that is agreed to by the Project Sponsor and the Project Team.

Project Objectives are important for the following reasons:

  • They define the scope of the major deliverables of the project
  • They will be used to define much of the activity scope of the project
  • Meeting all of the Project Objectives is one of the criteria for project closing

The combination of having well defined Business and Project Objectives will get your project off to a great start and help keep it on track. Take care to get these right.

The Project Charter – Business Objectives

Professor of Project Management Project Initiation ,

Initiation

As stated in the post “Building Blocks of a Successful Project Part 2”, Business Objectives are the “CEO’s view” of the project. They should make or save money, take advantage of opportunity, respond to new law and regulations, or increase competitive advantage. They should be specific and measurable to avoid what I call “Mom and apple pie” objectives like “We will be more efficient”. Really? Exactly how efficient? Will be be able to cut costs or deploy those efficiency savings to revenue opportunities?

Why is this important? Because everyone on your project is a decision maker whether you acknowledge it or not. Every day of a project, many “micro-decisions” are made without asking for clarification as that would be very inefficient. People will make these decisions based on assumptions due to lack of clarity in the objectives. Clearly stating the Business Objectives will help everyone make better decisions by asking themselves “does this decision support the Business Objectives as stated?”.

Another reason documented Business Objectives are important is they create a measuring stick for the health of the project. At any point in the project the question “Are the Business Objectives still obtainable?” needs to be asked. If the answer is “no”, the project is evaluated as to whether it should continue or not. Many projects forge ahead even if the Business Objectives are no longer possible because “we have spent a lot of time and money already”. This is a concept called “sunk cost” and this fact is irrelevant in good decision making. If a project no longer offers a return on investment (ROI), there is no point in throwing more money and time at it.

At the end of the project and at regular, predetermined intervals,  the actual outcomes need to be measured against the original objectives. If the outcomes met or exceeded the objectives, congratulations, your project was a success! If the outcomes fell short of the objectives, you can consider doing the following:

  • Find the root causes and address them, which may mean spending more time and money if the ROI warrants it.
  • If the ROI for spending more time and money to correct the root causes is not positive you can leave the project deliverables in place and not make any additional investment.
  • If the project results are actually having a negative impact and additional investment will not help you may need to reverse the implementation (if feasible) to prevent further damage.

My advice is to spend as much time as you need getting the Business Objectives right. It is the most important thing you will do on a project.

Building Blocks of a Successful Project Part 4 – Human Resources

Professor of Project Management Project Initiation

Initiation

The first step in obtaining your project’s human resource needs is to create a “Roles/Responsibilities” matrix. In the first column, you define the project roles required. For example “Project Manager”, “Business Analyst”, “Subject Matter Experts”. These are not job titles but roles defined for the needs of the project. The second column describes the scope of responsibilities for that role. The third column is the name or names of those people assigned to that role. The rest of the columns contain contact information, and the assignee’s department and manager.

The next step is obtaining the commitments for these resources to work on the project. I have seen many projects given the approval to begin without the commitment (or even awareness) of key stakeholders (business units that will have project task assignments). This leaves the Project Manager in the position of negotiating with the business units for resource time and priority. This is typically the result of lack of Project Portfolio Management and control of the project intake process, especially in regard to resource capacity.

A best practice in Project Management is to secure the resource commitments prior to the approval of the Business Case. This means doing a thorough stakeholder analysis of all of the roles and responsibilities needed for the project. A brainstorming session with those having a broad knowledge of the business functions can help identify key stakeholders.

The Executive Sponsor (with support from the Project Manager) is responsible for communicating with the affected business units and securing the commitments. If these commitments have not been made and the project is directed to proceed, then this must be handled using formal Risk Management (which will be addressed in a future post).

In addition to having committed resources, they must also be the right resources. They must have skills that match the assigned roles. If they don’t and you have no resource alternatives then your project must include a plan for skills development and your task estimates must take into account the skill levels of the task assignee.

For your “core” team (the small group that attends almost all meetings and contribute to planning) you must make sure they are empowered as decision makers. If your team is constantly saying “I have to get my manager’s approval”, your schedule may be significantly impacted.

Building Blocks of a Successful Project Part 3 – Executive Commitment

Professor of Project Management Project Initiation

Initiation

If your company actively manages its Project Portfolio, then this building block should already be in place. However, many companies begin new projects without any consideration of the impacts to projects already in progress or in the “pending” queue. This is the single biggest root cause to the Project Manager’s #1 headache: resource contention.

Before projects can begin, you should have satisfactory answers to the following questions:

  1. Are any existing projects competing for the same resources?
  2. If so, do these resources have the availability required for the new project?
  3. Where does this new project rank in the corporate priority?
  4. Is there a process in place to prevent the next new project from interfering with this one?

The answers to the above will tell you if you have Executive commitment for your project. Without it you will every day be at risk of losing key resources and jeopardizing your schedule.

Building Blocks of a Successful Project Part 2 – Business Objectives

Professor of Project Management Project Initiation

Initiation

There are  certain fundamentals that need to be in place to increase the probability of project success. The second of these is to have well-defined Business Objectives. These should be established as part of the original Business Case for the project. It is surprising how many times I have seen these absent from an initiative.

Business Objectives are the “CEO’s view” of the project. They should make or save money, take advantage of opportunity, respond to new law and regulations, or increase competitive advantage. They should be specific and measurable to avoid what I call “Mom and apple pie” objectives like “We will be more efficient”. Really? Exactly how efficient? Will we be able to cut costs or deploy those efficiency savings to revenue opportunities?

I will go into more detail on this topic when I address the Project Charter. Suffice to say for now that the main reason for having solid Business Objectives as a building block for project success is that it guides all decision making on a project. Whether you realize it or not, all of the project team members are decision makers, typically making many micro-decisions every day. The Business Objectives act as the beacon of light for these decisions. Any decision that will reduce or modify the impact of the Business Objectives must be escalated to the Project Sponsor.