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.