Showing posts with label Core Team. Show all posts
Showing posts with label Core Team. Show all posts

Friday, December 29, 2017

Project Team Leadership Tools & Techniques

Most projects are planned and implemented by teams of individuals. Therefore the ability to work effectively in a team is an important characteristic of successful project management. However, this is more than just being pleasant at meetings. The team normally represents diverse functions often with different, possibly conflicting, objectives. The team must be able to integrate the different needs of the functions and simultaneously achieve the goals of the project. Further, this is often done in an environment where no one individual has direct authority over the team members.

Many organizations have developed procedures for project team formation and project team behavior. I recommend that you use those if they are available. I have found several techniques to be very helpful when establishing and managing project teams. The first is the Core Team concept. This concept is useful for clarifying the team roles and responsibilities of project team members. The second technique that I will discuss is the use of Matrix Management when establishing teams. With the team established, the role of the Team Leader and Core Team Member will be addressed. Finally several useful techniques for addressing project team dynamics will be discussed including Situational Leadership, Team Development, Conflict Management, and Negotiation Skills. Of course, all of the techniques discussed in Project Management Communication Tools and Techniques have direct applicability to Project Team Leadership.

Core Team


The Core Team is the group of individuals who have day-to-day responsibility for planning and managing the project activities. This is typically a cross-functional group. The Core Team would consist of the Core Team Leader and the Core Team Member from each function that has a significant role in project execution. In my experience, Core Teams can vary in size from three to twelve members. The Core Team Leader for Focused projects often also wears the hat of a functional Core Team Member. For Full-scale and Complex projects with greater complexity, the Core Team Leader position is usually a full-time individual who does not also represent a specific function.

Core Teams are responsible for the detailed planning of a project. This includes the task planning, to include scope, schedule and resource planning for all project activities. Further the Core Team monitors the day-to-day project activities. When minor changes and tradeoffs must be made to the project plan and within the project boundaries, the Core Team has the authority to make those decisions. However, whenever their decision would cause the project to exceed one of it's overall boundaries, such as total budget, project completion date, or compliance to an external requirement, they should refer the final decision to the project sponsors or the PMO. Finally, the Core Team is collectively accountable for project success.

The outer ring of the diagram showing an illustration of a typical Core Team structure is the extended team, or full team members. These individuals are added to a project and removed from it based upon the current project activities. The individuals in this ring move from project to project or may be supporting multiple projects at any given time. These individuals are actively engaged in doing the project activities and the project cannot succeed without them. However, they typically do not play a major role in project planning and control of the project and are not held accountable for overall project success.

Matrix Management


Project teams can be formed within the business organization in several approaches. These include a projectized organization approach, a functional organization approach, or a matrix organizational approach. Many people today advocate for a matrix approach. The matrix has some advantages but it also has some disadvantages. Projects can be successful in any of the approaches, depending upon the nature of the project work and the goals for the project.

The projectized organizational approach creates a dedicated project teams. In this case all project team members are assigned and report to the project leader. They do not support any other projects during the life of the project to which they are assigned. The advantage of this method is that aligns all of the project team members with the project goals and objectives. The disadvantages are that expertise developed on one project is not easily shared across other projects and that there may at times be ineffective use of resources depending upon the schedule of project activities. Some individuals may be sitting idle waiting for predecessor tasks to complete. This approach is appropriate when either the project is truly stand-alone and there is no benefit for integration or best-practice sharing with other projects or when the project is Extreme in nature and the dedicated team is needed to quickly respond to changing circumstances.

The functional organizational approach does not create a formal project team. Rather, the business management determines a project is needed and then each functional department does their portion of the project in an isolated fashion. Either a project sequence is determined and each function does their activity when it is their "turn," or a set of high level requirements are agreed to and each function completes their portion of the project based upon staff skills and availability. The advantages of this approach are that the functional leaders can ensure the project activities are completed by the person most qualified to do the work and it allows functional managers to balance their internal workload across their people. The disadvantages are that there is very little project accountability with regard to overall budget or schedule and if tradeoffs must be made between the functional requirements of two or more functions, the people doing the work have no authority to resolve the issue leading to delays and inadequate project deliverables.

The matrix organizational approach was created to enable the achievement of the advantages of both the projectized and the functional approaches. When this happens, the functional managers enjoys the flexibility to assign the best person to the project activity in order to achieve functional excellence and can make the best use of scarce resources. At the same time the matrix fosters the integration of all the project activities in order to meet the project objectives. However, when the matrix is not implemented well, it results in the realization of the disadvantages of both the projectized and the functional approaches. There are delays and confusion in making decisions and neither the project or functional objectives are met. In my experience, there are two different approaches used for implementing matrix project organizations. One is referred to as a "Weak Matrix" and the other as a "Strong Matrix." Either approach can be effective. The monikers of "Weak" and "Strong" address the relative power of the project leader.

The Weak Matrix structure at first appears to be a functional structure. Each individual assigned to the project reports to their respective functional manager and their is no control by anyone with project leadership responsibilities. However, in this structure, there is a Core Team Member assigned in each of the supporting functions. These individuals are expected to communicate with each other and integrate their respective functional plans and deliverables so as to support the project objectives. One of these Core Team Members is assigned the role of Project Leader. This individual has the responsibility for calling the Core Team together and identifying when there are risks or disagreements that the Core Team is not able to resolve among themselves. At that point, the issue is elevated to senior management for their decision on issue resolution. The Project Leader is essentially an integrator and facilitator in this approach. The only decision-making authority he or she has is with respect to their function. In the example shown, the functions are just for illustration purposes. The Core Team should consist of all functions with significant responsibility with regards to project activities and the Project Leader could be assigned from any of the functions represented on the Core Team.

The Strong Matrix structure is a true hybrid of the projectized and functional approaches. Across the top of the matrix is the functional managers and down the side of the matrix are the Project Leaders. The Core Team Members are typically assigned by the functional managers with the approval of the Project Leader and the Core Team Members report to both their respective functional manager and to the Project Leader. This can lead to difficulty since the Core Team Members have two "bosses." If there is a difference of opinion about a project decision between the Project Leader and the functional manager, the Core Team Member can find themselves caught in the middle. However, when the issue is resolved by the Project Leader and functional manager working together to find the best solution for the business, this structure will speed the identification and resolution of issues. An important point of clarification, in the strong matrix is that the Core Team Members report to both the functional manager and the Project Leader. However, the extended team members report to the functional manager or their function's Core Team Member. They do not report to the Project Leader.


Project Team Leader


The Project Team Leader is the individual with responsibility for ensuring that the project is planned and executed. The Project Leader does not do all the work of project management, that is shared among the Core Team Members. However, the Project Leader does ensure that the work of project management is carried out on the project. The Project Leader is normally the individual who leads the Core Team meetings and is normally the individual who speaks for the project in project review meetings with the PMO or senior management. The Project Leader is also the person responsible for maintaining the project plan and the current project status and any associated project management documentation or databases. Finally, the Project Leader needs to review all major project decisions to ensure they are in the best interests of the project objectives. When the Project Leader believes a decision is inappropriate, he or she must take action to change or elevate the decision.

Over the years I have found that effective Project Leaders have mastered two vital aspects of project management. The first is Risk Management. The Project Leader must ensure that project risks are identified and analyzed, and not suppressed or overlooked. In addition the Project Leader should verify that risk response plans are established and implemented for all significant risks. The second aspect of project management that the Project Leader must do well is Project Communication. The Project Leader must manage the communication between the project team and stakeholders. In addition, the Project Leader must manage the communication between project team members. This can be very difficult when the project team members are not collocated.

The role of Project Leader is hampered by the fact that, unless the project is organized in a projectized approach, many of the project team members will not report to the Project Leader. This means the Project Leader must rely on their personal leadership skills in addition to any positional leadership authority that the title "Project Leader" may grant them. I have found that the Hersey Blanchard Situational Leadership approach to be very effective for Project Leaders.

Core Team Member


The Core Team Member role can often be viewed as a mini-project leader for their respective function. In this capacity, they are responsible for identifying the necessary activities that must be done within their function to support the project activities. Once those activities are identified, the Core Team Member is responsible for the planning and execution of the activities. The Core Team Member may be the person executing the activities, or they may be providing oversight to other individuals in their function who are executing the activities. Those other individuals would be considered extended team members.

A key role for the Core Team Member is to be involved in the day-to-day decisions of project management, They need to be able to adequately represent the interests of their function in Core Team meetings and they need to be able to commit their function to action plans - including schedules and deliverables. To do this well, Core Team Members should be capable of doing risk identification and analysis with respect to their function.

A problem I have seen in several organizations is that Core Team Members are selected based upon, "Who isn't doing anything right now?" rather than on their ability to represent the function on the Core Team. If an individual cannot be trusted to make wise decisions for their functional organization (within reasonable bounds) then they are not Core Team Member material.


Situational Leadership


The Situational Leadership approach developed by Paul Hersey and Ken Blanchard is an effective tool for project leaders to use when determining a leadership interaction style. Situational Leadership Theory can be applied in two different modes. One mode is for personnel development. In this mode the leader will have a long term relationship with the person being led - the follower, and the objective is to bring the follower to a point where they are highly capable and motivated. The other mode is the project mode. In this mode the leader expects to have a short relationship with the follower and the objective is timely and correct completion of project activities. I apply Situational Leadership in the second mode when working as a project leader. A key reason for changing leadership styles is to avoid over-leading or under-leading. Over-leading results in individuals feeling constrained, demeaned, and untrusted. Under-leading results in individuals feeling abandoned, insecure and confused.

The key in Situational Leadership is to determine the readiness level of the followers. Readiness is classified into four categories based upon the followers motivation and ability to do the project activity that is assigned.
Readiness 1: Low Motivation, Low Ability - this person is not skilled at the assigned task and does not want to do the work or work on this project.
Readiness 2: High Motivation, Low Ability - this person is eager to work on the project but is not proficient at the activities assigned.
Readiness 3: Low Motivation, High Ability - this person is capable of doing the project activities but for personal or business reasons does not want to do the activities.
Readiness 4: High Motivation, High Ability - this person is capable and motivated.

The Project Leader should respond to each individual situation be using a combination of task behavior and relationship behavior. Task behavior focuses on providing clear directions and guidance for the specific activities that are to be accomplished. Relationship behavior focuses on building an interpersonal bond between the Project Leader and the team member. For each of the follower Readiness levels, there is a corresponding Leadership Style.
Style 1: Directing - High Task, Low Relationship interactions - Provide clear directions and rigid accountability in order to get the person to expeditiously complete the project activity.
Style 2: Coaching - High Task, High Relationship interactions - Provide encouraging direction to both train the individual and maintain their high level of motivation, don't under-lead.
Style 3: Supporting - Low Task, Low Relationship interactions - Since this person is capable, you must focus on motivation. Relationship interactions will help to identify the underlying causes for lack of motivation and suggest ways to overcome them.
Style 4: Delegating - low Task, Low Relationship interactions - These individuals are budding superstars, so let them shine, don't over-lead.

Project Team Development


The project team development model that I find most useful is Tuckman's "forming, storming, norming, and performing." Although this model has been around for over 40 years, I find that its relevance to project teams is as true now as when it was first articulated. Project teams are often quickly put together and populated with people of different skills, backgrounds, experiences, and bringing different expectations with them. It is often multi-disciplinary, multi-cultural, multi- generational, and many time in multiple locations. This diversity can lead to excellent project definition, planning and execution - but only if the team can develop teamwork.

During the "Forming" stage, team members are being assigned and the team members are just trying to get acquainted. Soon the team progresses to the "Storming" stage as roles and responsibilities are assigned and arguments over activities, standards, and "turf" often are exposed. The project team should begin to resolve these issues and move into the "Norming" stage where they have agreed on activities, standards and levels of responsibility. As the team gains confidence in working with each other, trust develops and the team moves to the "Performing" stage.

One reason this model works so well for understanding team dynamics is that project teams are often unstable. The team membership changes during the life of the project. As activities are completed and new ones started, the roles and relationship between team members may change. As a project progresses through different phases, the standards of performance may change. From a team perspective this means that project teams will travel up and down the sequence of stages frequently. When a project team suddenly finds itself in the midst of conflict they should not view that as a team failure, it is just a cycling of the team dynamics throught the team stages based upon the changing project and business context. It means that once again the team must work through some conflict to establish new norms and again reach for high performing status.


Project Team Conflict Management


A technique that I have found useful for resolving team conflict is the application of the GRPI model of project teams. This technique has gained broad acceptance within the Six Sigma community for its ability to guide the team in a quick and easy approach for developing a project plan that is applicable to small projects. In the GRPI model, project development goes through four stages:
G - Goals: the goals of the project are agreed to by the team.
R - Roles: the roles and responsibilities of each team member are determined.
P - Processes: the actual project processes or activities are defined, estimated, and planned.
I - Interpersonal: as the project unfolds, everyone begins to work together and the interpersonal relationships are established and strengthened.

I use this model for conflict management by working from the bottom up. If conflict arises on the team, I first see if there is any interpersonal issue. If so, we work on resolving that issue. However, I always check the next higher level to see if the problem goes deeper into the project. Moving up a level, I check to see if there is a difference of opinion on what activities we should do or how they should be done. If that is the problem, we resolve that issue and usually the Interpersonal relationships are re-established. If there are Process problems I always look further up to see if there are problems with the assignment of roles and responsibilities. Once those are resolved, the responsible person can then make decisions about the processes and the interpersonal relationships are re-established. If there are problems with the roles, I always check to ensure the team is aligned on the project goals. If there is mis-alignment on goals, that must be resolved before we can even begin to create and execute a viable plan. Often if the issues is goal alignment, the stakeholders must be brought in to align the team members on the project objectives.


Project Team Negotiation


Virtually all projects are under some type of constraint. The constraint may be time, it may be resources, it may be regulatory/compliance, it may be technical limitations. These constraints lead to the necessity to balance conflicting demands on the project. This then leads to the need for effective negotiations between the Core Team Members in order to optimize the project and business performance.

The Thomas-Kilmann Model provides a suggested negotiation strategy for different conflict contexts. Based upon the desire to retain the relationship between team members and need for achieving a solution with a high degree of technically efficacy, different negotiation strategies are suggested. I recommend that the Project Leader be very familiar with this model and prepared to apply it whenever it appears that some goal or attribute of the project will need to be negotiated. Obviously collaborative approaches are often desired, but they may take a long time to reach a satisfactory solution. And sometimes there is no viable collaborative solution. In that case, the Project Leader must help the various team members decide which aspect of the team dynamic is most important at this time and implement the appropriate strategy.

Project Management Executing Tools & Techniques

Project Execution is the process or activities associated with completing the project activities defined in the project plan in order to meet the project objective defined during project initiation. This is the portion of the project where most of the project effort is expended. The focus for project management is the application of resources to project activities and the collection of information concerning the results of the project work.

The primary results of the Executing processes are the project deliverables and project performance information. In addition, when issues are uncovered while performing project activities, requests for changes to the project plan should be generated.

Once the project plan is in place, the most important aspect of successful Project Execution from a project management perspective is to ensure that appropriate resources are applied to each project activity so as to correctly complete the activity on time and on budget. The project manager must use the internal and external resources available to the project to ensure this happens. The management of internal resources is such as important topic that it is discussed on its own page:

Project Team Leadership Tools and Techniques


The application of external resources will be discussed below in the section on Conduct Procurements. Even with the application of the correct resources, sometimes the results of the project activities will be other than what was expected. Therefore the other aspect of Project Execution to discuss is the use of a Project Management Information System. This system will collect the data that is eventually used by the Project Control processes.

Conduct Procurements


Conducting project procurement consists of contracting with suppliers and vendors to perform the project activities that have been designated to be outsourced. The Project Planning page discussed how to determine the level of project management oversight required for a given project procurement. Now that the relationship has been determined, a supplier who is capable of performing the activity must be placed on contract. This entails typical procurement activities such as source selection and negotiations. The activities associated with administering the contract will be addressed in the Project Monitoring and Controlling page.

Project Management Information System


The Project Management Information System (PMIS) is the set of communicating methods used by the project team to share plans and results of project activities. Years ago we recommended that the team establish a central location where information could be posted for all on the team and the stakeholders to see the status. We called those project "War Rooms" - but in today's politically correct world we call them Project Management Information Systems. Another change from what we did years ago is that the typical PMIS today is an electronic system. It is an e-room, a website, a common folder on the shared drive, or a common file with different levels of access for review and update. In my experience, a PMIS today will be in one of the following forms. Which one you choose should be based upon the team dynamics and the organizational culture.

Project management software file available in a shared location.

This approach is generally used with Full-scale and Complex projects. In those cases the project complexity is so high that project management software is used because of its superior capability to track inter-relationships between project activities and project resources. This is the best PMIS approach for highly complex projects. The disadvantage with this approach is that all of the stakeholders and team members must be trained and competent at using all of the features of the project management software. Some of the software programs are complex and awkward to use. They can require a significant amount of time creating a project plan and then maintaining the project status. They require special training to know how to read information and to update information. If the stakeholders and team members are not frequently using the software, they have difficulty reading and maintaining project information.

To overcome these problems, companies are beginning to hire Project specialists who are experts with the project management software. These individuals will creaet and maintain the project plan in the project management software. They then create reports in standard formats that are provided to both team members and stakeholders.

Spreadsheet file(s) available in a shared location.

This approach is generally used with Simple and Focused projects. In those cases the project complexity is simple enough that the project activities can be planned and updated using several columns of a spreadsheet. This is often referred to as a WBS Dictionary, which is discussed in more detail on the Scope Planning page. The spreadsheet is typically easy for project team members and stakeholders to access and understand. The spreadsheet is able to manage a great deal of data and information. The disadvantage when using a spreadsheet for the PMIS is that it is difficult to track complex interactions between activities.

Meeting room or meeting space with a whiteboard, walls, and Post-it notes.

This method harkens back to the days when we used "War Rooms." This technique is often used with Extreme projects because of their rapid change and redirection. With the advent of modern technology the room may now be a virtual room instead of a physical room. When it is a physical room, the team meets regularly in the room to plan and track project activities. When an activity is completed, the information about the execution is posted on the whiteboard, a Post-it note, or some other document that is posted on the wall. When the room is a virtual room, the team meets in the virtual world and each participant posts their information using the tools of the virtual room technology. The advantage with this technique is the ability to quickly react to changing project conditions. The disadvantage is that everyone must have access to the physical or virtual room and if it is a virtual room there is the need for training in the use of the technology.

Project Management Communication Tools & Techniques

Communication is an essential part of project management. I have never met a successful project manager with many projects under their belt that was not a good communicator. This is due to the inherent nature of project work as compared to process work. Projects are unique one-of-a-kind set of activities. If we did exactly the same thing in every project, the same way, with the same people, and in the same sequence, then project manager communication skills would not be as important. An individual could be trained for a job, placed in it and the expectations would be clear. But project work is always different. That is why we need good communication. Those working on the project need to understand what is required on this project, when it is required, how it should be done, and what other activities it must integrate with. Without good communication, projects fall into chaos.

The methods and frequency of communicating will vary from project to project. One of the most important considerations is the project complexity. Simple projects require a minimum of communication, since it is usually a one person team and only one stakeholder involved. Focused projects require more communication planning and execution, but they typically are still relatively straight-forward since there are only a few people on the team. The project manager can often handle the communication through informal channels such as one-on-one meetings or calls to all of the team members and stakeholders. When the complexity grows to the size of Full-scale projects, the communication focus needs to shift. Now the project manager must spend dedicated time keeping everyone on the project aware of status, issues, and changes. Also, there are usually many stakeholders and stakeholder meetings on Full-scale projects. Once the complexity grows to the size of a Complex Program, the program manager is spending virtually all of his or her time doing communication and risk management. In fact, you could argue that communication IS risk management. These programs are typically managed as a portfolio of integrated sub-projects. The program manager is continuously communicating between the sub-projects to ensure they stay integrated and to guard against a problem in one sub-project cascading into all of the others.

Tools and techniques that are used by project managers to aid in communicating start with the Communications Plan. To develop a communication plan, a project manager will often do a Communication Technology Assessment. Of course, a Team List should be developed. Naturally, I recommend that when conducting a meeting - use good presentation skills, when composing a message - use good writing skills, when having a face-to-face encounter - use good interpersonal skills. However, these are not unique to projects so I am trusting you can get help on these from your Human Resources or Training department and you don't need me for that. I will stay focused on the parts of communication that are unique to project work.

The PMBOK includes Stakeholder Management activities in its communication chapter. I have placed the stakeholder management activities in Project Initiation and Project Controlling pages. Although those activities entail communicating, they are so integral to Initiating and Controlling that I felt it was better to address them in those sections.

Before I start to discuss the communicating tools, there are two topics I would like to address. The first is the understanding of a "Sender - Receiver" model. Whenever information is being communicated, it is translated from the sender's mind into a message and then from the message back into the receiver's mind. There are opportunities for misunderstanding in both translations, and for noise and errors to be introduced during the transmission of the message. That is why I believe every project leader meeds to focus on communication. Since project work is often new or unique, the chance for misunderstanding is even greater. There is no established pattern or expectation. I strongly encourage the habit of "Repeat it back." for all project communication to minimize misunderstanding.

The second is the recognition that listening is a three step process. If a team member does not seem to be listening, it is important to understand which step of the listening process is the issue. The three steps of listening are: 1) hearing, 2 understanding, and 3) judging. The Hearing step is just that. The actual receipt of the message. Team members who "aren't on the call" will not get the message. For vitual team members you may need to create special channels of communication to ensure they actually hear the message. The Understanding portion of the listening process is the team member translating the message into desired actions or changes to the project. Team members who do not understand the acronyms or whose native language is different than the normal language of project communication may hear the message that is being sent but not understand what it means. To determine if this is the problem, the project leader will need to have a directed conversation with the team member and ask them what they think the message is telling them to do. The third listening step is Judging. In this step the team member hears and understands the message and then decides whether or not they believe it applies to them and their project work. When this is the breakdown in listening the project leader will need to spend time with the project team member to determine either why the message does not apply in this special case or to explain to the team member why the message does apply to them.



Project Communication Plan


Every project manager uses a Project Communication Plan. Many project managers do not consciously develop one, instead they embrace one that has been imposed upon them from a previous project, they follow a procedure instituted by the PMO, or they conduct their communication in an ad hoc fashion. That is an approach for developing a plan - not a very good one - but an approach. I recommend that a conscious decision is made as to what communications need to occur for a successful project. I typically consider four categories of communication. All four types are not needed on every project, but they are typically found and should be planned for.

The first category I consider is management meetings. This category is often an extension of the Communication Strategy for stakeholders that I discuss in the Project Initiation page. For this category, consider which managers need or want information, the frequency they need or want it, and the content detail. Major communication sessions with stakeholders, such as technical reviews that I discuss in the Project Control page are often reflected on the project schedule as milestones and should be included in this portion of the Communication Plan. The management meetings should be planned and proper preparatin conducted. Some of these are face-to-face meetings and some are conducted using an electronic medium. A poor management meeting jeopardizes support for the project and reflects badly on the work of the project team.

The second category of meeting is the project team meetings. Depending upon the size of the project and the team, these can be short ad hoc conversations, conference call updates, email chats, formal pulse meetings, or a variety of other communication approaches. Regardless, these are where the project manager is able to track the day to day work of the project and resolve issues while they are still small.

The third category I like to consider is management reports. Many organizations require project managers to provide periodic reports for the management team. Often these are reviewed by managers who are not direct stakeholders in the project. These reports need to be able to stand alone in describing the project and its status. A project manager cannot assume the reader is familiar with the goals or risks in the project. That is why it is important to use the standard template or format the organization suggests/requires. The standard template guides those who are not familiar with the project to the areas of the project report that they are concerned with.

The final category that I consider is project records. These are the method that the project team uses to communicate to the future. Whether the future is teh business team members who use the project deliverables to implement business stategy, the next generation project, archives for litigation, or records for lessons learned, the records need to be complete enough so that whoever is reading them after the project has completed will be able to understand what has happened.



Communication Technology Assessment


The type of communication technology used by the project manager will vary based upon the organizational constraints of the project team and stakeholders. Factors that influence the technology include whether the team is co located, the confidentiality of any information that needs to be shared, communication facilities available to the team members, and the organization's culture for how meetings and disucssions are normally conducted. Some technologies lend themselves to large group interactions and others are more appropriate for one-on-one discussions. The table below provides an assessment of the advantages and disadvantages of different communication technologies for use in a project environment.



Project Team List


The Project Team List is a list or database with all project team members and their contact information. This includes the core project team members and extended team members. I typically will also include key stakeholders on this list. The list is provided to team members to aid communication. I want project team members to know who to call when they have a question or an issue arises. The list can be maintianed in as a spreadsheet, a word document, a file for your email server, a contact list in your project eroom, or any other mechanism that is a normal resource contact management system in your organization. One caution about the list, I provide business contact information, but not personal information. In this era of identity theft and the increase of "creepy people" I try to protect the team member's privacy as much as possible.

Project Resource/Budget Planning Tools & Techniques

The project resource/budget plan is a description of how the business resources will be applied to the project activities. It includes the identification and deployment of the team's human resources and the planned financial impact of the project on the financial accounts and reports of the business. Resource/budget planning links with schedule planning and scope planning since the resources are required to perform the project activities (scope) at a particular time (schedule).

Many organizations have customized tools or templates to assist the project team with resource/budget planning that are linked to the organization's human resources or financial systems. I recommend that you use those if they are available. I have found six resource/budget planning tools or techniques to be helpful, depending upon the uncertainty and complexity of the project. These are the Team List, the Responsibility Matrix, and the Staffing Management Plan, all of which apply to assigning and managing human resources on the project. For budgeting, I recommend the Spend Plan, the Project Budget, and the Appropriations Request. There are two topics that are integrally related with budgeting but are also integrally related to other project management topics so they have received their own topic page. These are Project Estimating techniques and Earned Value Analysis.

Team List


The Team List is a very simple, yet vital, project management tool. This is a list of all the project team members and appropriate contact information. This is normally the only human resource planning tool required for Simple and Focused projects. In these cases, the Team List is used to ensure that a representative from each organization that is required to perform activities on the project has been identified and contacted. Because the scope and complexity of Simple and Focused projects is limited, there is usually only one individual from a participating organization assigned to the project and that individual's role is seldom of a full-time nature for the life of the project.


Responsibility Matrix


The Responsibility Matrix (also called the Responsibility/Accountability Matrix or the Roles and Responsibility Matrix) is a table that is used to provide clarity for all of the project team members concerning their expected level of involvement on the project. The matrix is normally constructed by listing the project tasks or activities down the vertical side of the matrix and the project team members on the horizontal side of the matrix. The project teram member who is responsible for planning and ensuring that each task is executed properly is identified in the matrix. In addition, the matrix will normally identify other project team members who are involved in some fashion on the activity.

The designation of the role of a project team member within the matrix can be done using several methods. The most common technique is to an acornym RACI. However, I have seen three different definitions of RACI in use. My preferred approach is to designate the responsible team member with an "R." If the activity is a cross-functional activity, I will indicate the other team members who must contribute to the work of the activity with a "C." If the activity requires an approval of one or more of the other project team members I will indicate that with an "A." Finally, I indicate those team members who need to be informed that the activity has been completed with an "I." If using RACI, be certain you know and understand the definitions that your organization uses.

The Responsibility Matrix is used primarily on Full-Scale projects as a tool for both communicating assignments and for risk identification with respect to the capacity and capability of project team members. If a team member is carrying a particularly heavy load, for instance if they are "Responsible" for many activities, there is a risk that the team member will be over-allocated and unable to perform some of the activities according to the project plan. Also, the matrix can put a spotlight on an individual who is being asked to accomplish activities beyond their experience or capacity. I find it is easier to have a discussion with the individual or their manager when we are looking at the requirements of the individual's column on the matrix rather than implying that the individual is somehow unable or incompetent to work on the project. Further, the matrix will indicate those activities where there is no "Contributing" support for the individual who is "Responsible." In those cases, there is a risk that if the team member on that activity is reassigned or temporarily unavailable, there is no one who can be immediately turned to on the project team to keep the activity moving along.

Staffing Management Plan


The Staffing Management Plan is a document or spreadsheet that indicates how the pool of available program human resources will be deployed across the sub-projects associated with a Complex program. A Complex program is normally managed by dividing the work into a set of inter-related Focused and Full-Scale projects. Key individuals and resource pools are likely to be supporting several of those sub-projects. The Staffing Management Plan indicates how that individual or pool should allocate their time, for instance 50% to Sub-project A, 30% to Sub-project B, and 20% to Sub-project C. Also, the Staffing Management Plan indicates how many individuals from the pool are allocated to each of the Sub-projects.

The Staffing Management Plan normally shows the allocation of the resources across the sub-projects over particular time periods. I usually create the Staffing Management Plan in a spreadsheet with each column representing a month. However, I have occasionally allocated resources by quarter and by week. The Staffing Management Plan must therefore be integrated with the high-level schedule of each sub-project so that resources are deployed at the appropriate time and so that the program manager will be aware when resources will be available for redeployment to other sub-projects.

Project Spend Plan


The Project Spend Plan is normally developed as a spreadsheet and lists the planned purchases of the project team. This plan is usually created for Simple and Focused projects as a means of communicating the spending intention of the project team. Because of the small size of these projects, the projects often are not tracked as separate line items in the organization's financial system. For these types of projects, the Spend Plan usually is short - and many times is non-existent (nothing is purchased on the project). When I create a Spend Plan, I usually divide the list into investments and expenses. For investments, I list the actual piece of equipment I intend to purchase. With expenses, I will further segregate them into several categories based upon the type of expense. The categories I normally use are: material, travel expenses, and contractors/temps.

Project Budget


The Project Budget is the time-based spreadsheet that shows the project team's intent to spend the organization's resources on project activities. The spreadsheet is typically organized by listing the project activities in the spreadsheet rows, and designating each column as a time period. I normally set up the Project Budget with each column representing a calendar month. However, I have occasionally further decomposed the activities to have each column represent a week. The data created in the Project Budget is transferred to the organization's financial planning and management system. Some organizations have dedicated project financial trackiong systems. These systems will have budgeting templates, forms and screens to assist the project team with the budgeting process.

All of the project activities are usually listed by some organizing principle based upon the policies and procedures of the organization. The most common organizing principles are: project phases, WBS structure, department/business function, geography/location, cost center, and cost category. Depending upon the magnitude and complexity of the project, several of the organizing principles may be used in combination with each other.

Once the Project Budget is created, the intended costs for each time period are summed in each column. Often the total for each column is shown, and a cumulative total is created showing the total intended costs from project start through each time period. Also, these totals are normally shown in graphs to assist in communicating the spending needs of the project.

Project Appropriations Request


The Project Appropriations Request is part of an organizational process rather than just a form or template. Many projects result in the creation of an investment asset that must be recorded on the organization's Balance Sheet. Once the investment asset is in service, it must then be depreciated - impacting both the Balance Sheet and the Earnings Statement. The values on these financial statements has a significant impact on taxes and on reporting to the investment community. It is imperative that the organization's financial management is aware of the investments created or procured by the project team. The project team communicates its investment intentions to the organization's financial management through the Appropriations Request process.

Each of the organizations I have worked with had their own unique process. Some had forms to complete, others had spreadsheets to be completed, still others had internal websites that guided an individual through the process. Regardless of your organization's specific approach, there are several elements that seem to be universal in the process. These are:
  • Identification of the asset by name or type of asset(milling machine, server, facility expansion)
  • Purchase price or development cost of the asset
  • Date the asset will go into service and be available for use

In addition, many organizations require the project team to provide additional information about the investment asset such as:
  • The financial benefit the organization will receive from having the asset in use (this is usually the business benefit of the project)
  • The return on investment calculation (NPV, IRR, payback period, or whatever other method is preferred by the organization
  • The depreciation schedule for the asset (this is often predetermined once the asset category is established)
  • The asset's residual value once it is fully depreciated