NYU’s Team Management in a Project Environment picked up again this past week after spring break with a review of the Critical Success Factors for a project and the team.
Lacking one or more can be a catalyst for failure … dependent upon how success is defined some may carry additional weight above others.
Core knowledge and process areas to be aware of:
Project Teams are not Work groups because Projects are not Repetitive Assignments so the leadership, structure, management, throughputs and outputs of Project Teams are inherently different than that of Work Groups.
The Team Development Cycle:
Forming > Storming > Norming > Performing >Adjourning
Team Selection Phase is the forming stage and affects storming, or coming together, which becomes the Team Adjustment Phase. During the Team Identity phase norming, or the collective identity of the group occurs allowing performing of the project tasks to occur during monitoring and control. Adjouring is the breaking up of the team during the lessons learned.
Essential Teams characteristics … successful teams enjoy:
This is facilitated by quality soft-skills of Project mangers and the team members AS WELL AS protocols and proceedures in place to facilitate those soft-skills.
there are several models to provide an understanding of team dynamics:
The triple constraint model
Each angle in the triangle represents: Performance; Collective Identity; Personal Growth
and each of the arms in the trangle connecting them are: commitment; skill set; accountability
The Z Process by Inscape Pubs
Creator – idea generator
Advancer – makes it work
Flexer – Progressive
Refiner – perfects it
Doer – executes it
the Whole Brain Theory.
This week’s in-class assignment was to work on a a team building task were we self-defined what a team contact would look like. Team contracts can consist of any number of rules, expectations, protocols, etc. meant to help define the communication and documentation requirements of the team. No two contracts will be the same because no two projects and their teams are the same. After the assignment was complete we needed to document our experience with the task and our feelings on team contracts.
My in-class team quickly came together, discussed our past experiences in the team environments and what worked or didn’t work and began to draft sections of related expectations to which we then filled in what we jointly determined would be generally important to daily team life. These included methods of communication, meeting agenda and etiquette, documentation protocol, issue escalation and deescalation and the decision making process. The following is the result of the assignment:
The Team Contract represents the agreed upon methodology within the Project Team that:
- Sets expectations within the team.
- Directs inter-team behavior.
- Outlines the principles of communication.
- Establishes protocols for problem solving.
- Provides a foundation for the continuing team dynamic.
Team Contracts are created, maintained and executed by the team based on:
- The makeup of the project team.
- The requirements of the project itself.
- The evolving nature of the project lifecycle and team needs.
- Availability of tools to aide or support it.
- Support provided the team, the Project Manager and Project Sponsor.
The strengths of a well planned Team Contract arise from the:
- Process of its creation allowing the team to have a forming experience in creating it.
- Ability to establish team behavior, communications, documentation, etc.
- Potential mitigation of common potential misunderstandings and problems.
- An establishment of protocol for escalation and de-escalation of issues.
- Mutual ability to amend it based on changing team and project needs.
When established the Team Contracts can help compliment:
- Typical project management tools supported by PMI or other methodologies.
- Planning, tracking and reporting systems and technology solutions.
- Communication technologies and methodologies.
- Documentation environments.
- Conflict management theories and strategies.
- And other tools and techniques used in team development and project execution.
However, Team Contracts may fail when:
- There is not effective buy-in by the team as to the contract contents and structure
- The contract is ambiguous or does not effectively cover a particular need
- not adaptable to a changing environment
- Is not respected by the team or enforced correctly by team leaders including the Project Manager, Project Sponsor, etc.
- Execution is undermined by over-reliance on technologies, techniques or methodologies rather than common sense and mutual respect in team forming.
Team Contracts alleviate potential questions and confusion points within the team.
Typically, within teams I’ve worked in or managed, these included putting the entire team on an even playing field for the project by:
- Identifying which tools and methodologies would be used for which forms of communication and documentation.
- Presenting a common lexicon within the Project Team.
- Defining protocols for meetings and conduct for other interactions
- Setting expectations among Team Members for their accountability and responsibility within the Team.
The process of creating the Team Contract can also have positive effects on the team dynamic beyond the words of the document.
In my experiences in creating Team rules similar to these Contracts I have found they:
- Allow team members to have a stake in the team dynamic because their contributions to the document facilitate the storming phase of getting to know one another.
- Defining expectation of specific behaviors within the team dynamic helping making the norming stage more fluid for team members.
- Provide a foundation of communication strategy which can be beneficial to those who are inexperienced at effective communication (lack of knowledge, different native language, etc.)
- Prevent miscues and miscommunications that occur in similar projects that did not have an established set of Team Conduct Rules or those rules were not effectively enforced.
Generally, I find the value in Team Contracts within my project teams because it:
- Makes my life easier.
- Alleviates “teaching on the go” because the information is catalogued upfront.
- Produces a more cohesive team experience.