Project team contract
link management, sponsor, and core team into a "superteam"
The presentation will show how a core project team can develop a project contract and use it to link management, sponsor, and themselves into a “superteam” with greater probability business success on new product commercialization projects. It will also explore how the contract will truly empower the core team and demonstrate how it will simplify project tracking and progress reporting. The contract will be the integration tool used to link project planning, plan execution, and change throughout the project phases and spanning knowledge areas.
This presentation is based upon the experience gained over several years and hundreds of new product development, capital improvement, and other projects facilitated by the author and other members of the former Commercialization Services Department of 3M. The department was chartered with the development, training, and transfer of new product introduction and project management best practices throughout 3M corporation.
The charter, planning, and contract process outlined, has been incorporated into the 3M commercialization process as it was established by a team of over 100 individual contributors from across the corporate divisions and staff groups.
The type of environment that is being referred to in this paper is somewhat less structured general manufacturing, research and development arena. Cross-functional teams have been used for product development projects for at least a decade. The projects have gotten larger, more complex and the teams larger with their make up being not only cross-functional, but also cross-corporate.
Even though these teams may have been cross-functional they may not always have been empowered. This empowerment is a necessary ingredient to allow for the use of the project contract. For teams willing to stretch development and execution of the contract can help generate empowerment.
The key players of the “superteam” are management, sponsor and the core project team. These people are usually separated, by hierarchy position, task type or functional activity type. They are in effect operating in small islands throughout the business unit. The project is the common link between these members yet they will tend to work independently in their silos. Even though these members are the usual people, they will now be link in a new different way—The contract.
The contract is not a true legal and not necessarily formal document. It should at least be formalized enough to bind all parties to delivering on the agreements they document in the process. The contract essentially brings the key players together in a manner that facilitates each to fully fulfill the role: they should play, that they are most effective at, and is necessary to the project. The contract helps define where commitment is necessary and aids in generating the level of commitment they should have. The responsibility the parties should bear in making the project a business success is also defined in the contract—There are fewer cracks to fall through.
In order to sustain the business, each of the key parties involved has some specific job responsibility that may lie outside the boundary of the project. In addition people tend to do the things they are most comfortable with—The project may involve stretch type activities. Because of this not all parties will fulfill the role they should play to assure project success.
Upper management’s role should be giving strategic direction, opportunity analysis/selections, portfolio management, sponsor selection, team empowerment and project support. Strategic direction may be out of the realm of any one project, but portfolio determination and management could actually be made easier or facilitated by the use of contracts across the range of all the projects being done in any one business unit.
Empowerment is a core value issue and may be impacted directly by the executive style or ability to let go and trust the process and the teams that are empowered. The contract will work to increase this trust and comfort level because issues are clearly spelled out and responsibilities defined. Where they fail to empower core teams and actually micromanage projects the company loses on two scores. Executives are no longer doing what they should be accomplishing, and they are to be far removed from the task they try to micromanage, to be effective at it.
In many cases a sponsor for the project may in fact be a member of the business unit operating committee. Even if this is the case the selection of the sponsor should ultimately be the responsibility of the business unit executive. This selection should be based on several criteria: highly placed in the organization, knowledgeable in the organization culture, trusted as a counselor and coach, member of top management or quality steering team, able to remove roadblocks to progress, and a logical choice to the project. A good choice will legitimize the project and the team throughout the organization.
The sponsor role is considered critical because they actually span between management and the team. The main role of the sponsor is to act as an assessable source of support able to remove barriers or political issues the team may have. There are several other activities the sponsor must do for the team: give the team the charter, kick off the project, approve the project contract prior to final approval, support and guide project leader and team, attend management project status reviews, team maintenance, and provide team recognition.
There is a dimension to sponsorship that is usually over looked—They need to assume responsibility for business success of the project. This responsibility should not be delegated to the core team only. Because of this responsibility the sponsor should be allowed to help choose the team leader and other team members. In this way the sponsor’s commitment is forged by the ability to have a part in the creation and resourcing of the team.
The metrics that may be applied to the sponsor can be made clear in the contract. The contract will provide the framework the sponsor needs in order to define what they need to negotiate in order to make the project a success: resources, capital, equipment, time, etc. It will also define project metrics the sponsor needs to monitor. While the contract cannot help poor selection mechanisms, it can help the sponsor fill the pivotal spanning role.
The position is very complex due to the skills and power the sponsor must possess. This individual may not always be as effective in the role as they need be. This usually happens due to lack of well defined selection criteria, having a sponsor that is not responsible for the project success, and not held accountable for it.
A role whose importance was long over looked, not well understood and not fully reinforced was that of the functional manager. The various individual functional managers play an integrating role in how projects are run. If they fail to perform the correct role, they are in the same type of dilemma as the upper management—They can in fact contribute in negative ways. The Functional manager’s role is mainly two-fold. They are the resource, and in the case where the project has no formal budget, the person providing funding for activities and expenses on the project.
As a resource provider they are critical for three reasons. They can control the level of resources they allocate to any given project from their functional departments, the maintenance of the resource commitment, and the technical skill level of the resource that is assigned. The manager should be aware of the level of resources applied on the project as it progresses. If they realize that more resource is required they should alert the team leader and offer to help in what ever is way appropriate. It is also essential that the managers leave resources on the project and not redirect an individual’s effort so they are no longer able to adequately fulfill their responsibility on the project. A third more subtle resource impact the functional manager has on projects is due to the integrity of the technology maintain within their departments. If the overall quality of the department slips the ability to support projects falls accordingly.
In the case where new product development projects are not formally budgeted, funding must come directly out of the functional manager’s departmental budget. These budgets must then be adequately forecast on such a manner that funding will be available for the project at the appropriate time. There can also be a degree of conflict between traditional functional expenditures and project expenditures.
It can clearly be seen that without clear definition, the manager can fail to fill the role to provide adequate resources, with the correct skill sets, at the right time, and adequate funding. It is not so apparent that without the contract the manager not only may fail as the provider but also can slip into a role they are not supposed to play. Without clear definition of the contract, the functional manager will many times try to assume the role of project leader, who in many cases may report to them. Hence the damage is negative in two ways. Project needs are not met and role conflict occurs.
There is at present no well-defined process for choosing project leaders/managers. In many cases for smaller projects the leaders may have no experience at leading projects but have been determined to have good potential and the appropriate skills necessary to lead a project. For larger more complex projects or programs an individual is chosen that has proven themselves through the trial by fire, and been successful. Because there is no clearly defined selection and training process team leaders are more or less given the opportunity to succeed or fail on their own. There are however, many safety nets in place to help assure success if the management, sponsor, or team leader chooses to use them. There is individual and intact team training for project management, project planning, team concepts, and leadership.
Although they are considered members of the core team, the project leaders are in a unique position with a specific role different than the remainder of the core team members. Some of the role they need to fill is created by the fact that they are usually working more closely with the sponsor and need to fill an integrative position between sponsor and team. The main responsibilities of the team leader include: clarify project objectives, Maintain focus on key issues, Coordinate activities with functional managers, Lead project team meetings, Help team deal with change, Reflect change in project plan, Resolve conflicts and remove barriers, Report project status to management, Clarify project objectives and priorities and help with Team maintenance.
As mentioned earlier the team leader often may report to a functional manager as do the other core team members. This creates a situation where the team leader has much of the responsibility and no authority over the core team members. This situation is starting to be addressed by virtue of giving the team leader some input on the performance appraisal of core team members.
The contract can again be used as the definitive document to specify just what the team leaders role and responsibilities are in relation to the project deliverables, team, and managing the project.
The final role to be filled on the “superteam” is that of team member. Although it is being discussed last the team member is by no means any less important than any of the other roles and is likely the most important. The obvious responsibility is to do the functional and team activities necessary to complete the project. This is an over simplistic description of what the total role responsibilities are all about.
In most cases the team members are assigned to projects because they have technical expertise relevant to the project, have been doing preliminary concept research prior to official start of the project, or may be an available resource with the needed skills. There are some divisions in which team members are being given the opportunity to choose which projects they want to work on. In more and more cases team members ore coming from across corporate boundaries and may not have meet each other before the first official kickoff or planning meeting.
The core team should be cross-functional with representation from all functions of the business unit and any specialized resources required for successful completion. The team member’s role is almost determined by its very cross-functional nature or vice versa. Each member is fulfilling an integrative role by representing his or her functional department to the team. The reciprocal of this is also required; they need to represent the team to the functional department. This may seem trivial in difference, but requires the team member to take an opposite advocacy position in each case. By representing the function they need to bring the best functional expertise possible to the team while trying to do what will best serve the department.
In representing the team to the function the member must negotiate with the functional manager to get buy in to what they are being asked, and agreeing to commit to for the team. As an example they may need to negotiate the level of time they need to commit to a team as a resource.
With respect to the central role, team members must be responsible to determine the work task activities for the function they represent, achieve task assignments within schedule and cost target, and communicate progress and potential problems to the team leader and their supervisor.
All of the definition is done in a participatory style in a Team project Planning Workshop. Once defined all are included as part of the project plan and contract. Just as in the previous cases the contract will document just what the team member needs to deliver as a team and is further defined in the project plan schedule. The schedule is included as a part of the contract.
Because all team members are given the opportunity to determine, define, and author their own portions of the contract/plan they buy in more readily and completely than if they are just assigned their tasks. This buy in creates a much stronger commitment to the project. In addition to the commitment, there is a much clearer understanding of: what each individual is expected to do, team interdependence, what it will take to win in the marketplace, how it can be accomplished and an appreciation of what others do and contribute.
Contract development starts once management completes project, sponsor, and team selection. With the Key players in place, management and the sponsor should develop a relatively detailed project charter and give it to the sponsor and team as the official empowerment document—The team is given an in-depth outline of just what is to be done, and legitimized as a team. The charter does not tell the team specifically how to accomplish the project even though opportunity, time window, cost target, and product performance may be outlined as targets. It is still up to the core team to fully detail the plan and develop the contract that will document the how, realistic timeframe, and how much the project will take.
The process for development and implementation of the contract, by each core team is as follows: complete a comprehensive team planning session: determine contract elements; present the contract proposal to upper management; negotiate final agreement; implement the project/contract; and review project progress versus the contract.
The team kickoff is usually done as part of the comprehensive planning exercise in a facilitated Team Planning Workshop. All members of the core team need to be present along with the sponsor and in some cases the business unit executive for kick-off. This workshop usually takes one and one half to two full days for plan development, followed by a one half day team follow up to compress the schedule, and to optimize and finalize plan details. These details will then be put into the form of the contract for review, negotiation with, and approval by all key players: management, sponsor, team leader, and core team.
The agenda, for day one, usually follows the following format: kickoff, background, process orientation, customer expectations, goal unification, benefits documentation, assumptions recording, key issues/concerns/risk assessment, WBS development, milestone definition, task creation (duration and required resources,) and finally interdependency determination. There is usually some flexibility for customization to meet the needs of the specific business unit. After all this information has been generated and recorded, it is documented and a computerized critical path project model is generated. The model is then used in the one half day follow up session.
The team project planning workshop has been developed and used over a period of several years. Although it may seem simplistic, each element of the agenda is based on some specific team building need, project management principle, or project success factor. In addition, the documentation of all the details is in affect the foundation of the contract. Kickoff, background and process orientation help team members understand the framework in which they are expected to perform and details of what the charter spells out, significance of the project and project management basics. Goal unification is extremely important because the team gets the opportunity to define for themselves, or at least clarify the project objective based upon information team members have which may be more closely aligned with reality of technical capabilities. In any event it definitely enhances buy in.
We believe, it has been clearly demonstrated, that if there is no benefit or uniqueness to the customer a new product is likely to fail. With this in mind, every new product development project team needs to examine and demonstrate that they have examined this issue and determined they understand what the customer expectations are or plan to find what they are. This gives necessary information for product performance in the contract.
In alignment with customer expectations and focused internally are the benefits for the project. While it may seem trite, unless the team can clearly demonstrate and document benefits to the corporation and business unit that out weigh cost/risk tradeoff, the team may decide to kill the project. While this may be clearly documented in the contract there are some other benefits that should be reviewed. In addition the team should be easily able to develop a list of benefits to the team and individuals. While this may not be a part of the contract it certainly helps moral, buy-in and commitment.
In choosing and accomplishing the project many assumptions may be made, some by management and some by the team. It is vital that the team understands what these assumptions are, who made them, what their impact is if they fail to be true, and do they conflict. The real exercise is to determine if the team is being tied to expectations that cannot be met because faulty assumptions were made by management or there is conflict between what the team knows to be true and what management believes to be true. If any of the assumptions is suspect it likely becomes a major concern.
Every project team should know what its critical success factors are, or what it takes to make the project a business success and win in the marketplace. Linked to these issues are the concerns the team may have and the risks associated with them. If a team doesn’t know what the key issues are and can spell them out in the contract management may want to examine the situation more closely to help out or become concerned themselves. Team concerns are most often centered on resource, short schedule, technical feasibility, or market knowledge issues. Any concern by any individual is worth discussion and recording. Usually a concern is due to the fact that an individual has or doesn’t have some piece of information they need to feel comfortable about the project. They can be easily removed with information from the team or they can prevent a major problem for the team if they get the information up front and act proactively. If a concern isn’t raised it may come back later to haunt the project. The relation of concerns to risks is clear and risks need to be clearly spelled out, understood, and some mitigation plan put in place. The risks, probability, and impact should be spelled out in the contract as to what will happen to the project if they occur; i.e., Scope change; schedule and cost increase, performance loss etc.
The next part of the contract development is the definition of the work to be done. If the project is very complex or a possible government project the team will develop a work breakdown structure to aid in the planning and development of the tasks necessary to accomplish the project. Although contrary to project management methodologies many times the milestones and tasks can be developed without doing a work breakdown structure. This is partly true because the divisions use New Product Commercialization processes based on a corporate model. These NPC systems define many of the tasks necessary to complete a new product commercialization. In any event the WBS can be developed from structuring the task list and does help to develop the task list if done in advance.
The Milestones are defined as a team and laid out using Post-It® notes. Once the milestones are defined the team can now break up into breakout groups relative to certain task groups that need to be defined and developed. This is a series of negotiation sessions where the individuals negotiate with others about the deliverables they will need in order to perform their own tasks.
Task duration and resources are also defined through this negotiation process. Once all the work tasks are written on Post-It® notes the team is ready to determine how all the work will flow. Every task must have an owner who is responsible to the team for its completion. These responsibilities become part of the contract by schedule inclusion.
The work tasks are now placed in sequence with the milestones and all predecessor/successor relations established. When this data is entered into project management software the critical path and time schedule is established and a project network printed. In a one half day follow up session the team goes over the plan network to confirm the data, compress the time line and finalize the schedule and plan. Once finalized it is formatted into a project contract containing all the data.
The sponsor first reviews the plan and contract as developed by the core team if approved, the plan contract is presented to the division operating committee for approval and agreement.
What each key player is responsible to deliver in order to make the project a success is clearly defined. With the contract approved, the project can proceed and be tracked against the metrics and deliverables included in the contract.
Every one on the “superteam” gains many benefits by employing the project contract. The contract provides a strong linking bond between the three key parties, management, sponsor, and core team. Communication is increased and clarified, leading to better understanding between all members. Roles are better defined, which affords better fulfillment of those roles and less role conflict due to members doing inappropriate role activity. There is a heightened sense of trust built between all members because of the greater understanding and definition of deliverables for each.
Greater trust by management can allow them to be more comfortable in totally empowering the core team. By being empowered and given power of co authorship, the core team will be committed Vs just compliant. Accountability will be shared and increased by all parties due to clear definition of contract responsibilities. Project team effectiveness is increased by proper delegation of project activities, roles, and accountability. Because activities are being accomplished with the least amount of transference between “superteam” members, efficiency is also greater. When all these benefits are accrued the ultimate benefit is achieved—The overall business success is greater.
In closing it is again worth mention that the environment this type of methodology is used in is rather unstructured with less well-defined work packages than in the construction or department of defense type project. The organization is many separate business units, each with their own functional groups and some corporate technology centers for some special technologies. The projects tend to be new product development/commercialization projects where the core team is cross-functional, consisting of about 8 to 12 members. Extended team membership could range up to 35–50 persons. Many projects, in addition to being cross-functional, are cross-corporate.
Proceedings of the Project Management Institute Annual Seminars & Symposium
September 7–16, 2000 • Houston, Texas, USA