Rapid team building on troubled projects
At the recent London Olympics, Team GB (Great Britain) won a record number of medals, not achieved since the early 1900s (Smith, 2012). In comparison, the English team at the football World Cup of 2010 suffered one of its worst humiliating defeats. The primary reasons cited by the English football team for their dismal performance were accusations of poor leadership, poor tactics, and “intransigence “from the England Manager, Fabio Capello (Fifield, 2010, p. 13). Other underlying reasons also provided was the inability of the English team to communicate with their Italian manager whose English was limited, claiming they “appeared tired” (p. 13).
Whatever the goal, and however perfect the plan, no matter the cost, at the heart of any project is the team. Projects can go a long way with inadequate sponsorship but they will not go very far without a high-performing, integrated team aligned and moving in the same direction with a common understanding of the objectives of the project.
There are many reasons why projects run into trouble. One reason is the team. Teams are often blamed directly for project failure. For example, having a weak team member, the wrong people, or a lack of team cohesiveness due to issues such as placement of individuals on a political level or there is nowhere else the individual fits in the organization, can cause problems in projects (West, 2012). Other common reasons for project failure are missed milestones, poor communications, project leadership, poor quality control, or breakdown in relationships and trust, which do not just happen by themselves and all relate directly back to people (e.g., the team and project management). Although team issues emerge as the project, they are usually rooted from the beginning of a project, through lack of alignment, integration, and clear leadership and direction.
This paper will illustrate through real-case study examples, how team issues arise and how a project manager can swiftly rebuild a high-performing team, creating an environment for recovering a troubled project, aligning the team (even if team members are virtual) with the recovery plan.
The Project Team
Project stakeholders are defined as “individual and organizations that are actively involved in the project or whose interests may be affected as a result of the project execution or project completion” (Project Stakeholder Management, 2008). While project team members may be stakeholders, stakeholders may not necessarily be team members, as highlighted in Exhibit 1. There are many different types of teams. For example, there are executive teams as well as project teams, all who are essentially “an interdependent collection of individuals who work together towards a common goal and who share responsibility for specific outcomes of their organizations” (Sundstrom, DeMeuse, & Futrell, 1990, p. 2). For project teams the effort is within a defined timeframe.
Exhibit 1 _ Stakeholders and Team Members
Projects bring teams together. These are individuals who can be both internal and external to an organization, who bring with them their own individual values, skills, reasons, and beliefs for being on the project.
Although the challenges of team building have not changed over the years, the conditions under which project managers now build and manage teams have changed. It is increasingly common in today's competitive global economy, to have distributed teams. It is now estimated that 70% of managers above first-level supervisor now have at least one team member who is not co-located with them, and the number of projects managed virtually has doubled every year since 2001 and sits at over 80% of projects (Turmel, 2010, p.10). Although this global ability to build both co-located and virtual teams of required talent enables businesses to respond quickly to organizational needs providing a competitive advantage, both dispersed (remote) and virtual teams have brought new dimensions for the project manager, and by their very definition of being remote, new complexities.
Although technology will help support these multifarious changes in managing and communicating with distributed and virtual teams; for the project manager bringing these distributed teams together to work on a project is made even more difficult when they are multi cultural and global. Language constraints between different countries are an obvious difference; however, culture influences the performance of a team on how they reach consensus or how problem solving is managed. The level of skill required by a project manager increases in line with distance and cultural complexity, and they not only need the skills to be a good leader, but they also need the ability to relay these same messages and information to global team members and build relationships and trust. This requires more emphasis on different skill strengths and abilities of the project manager in order to achieve optimal team performance. Communication is fundamental to project success and if the project manager is not a skilled communicator, then in troubled project situations they could make the situation worse.
Additionally, the type of approach adopted for delivery of a project, such as Waterfall or the agile framework, will also change the relationships and dynamics between the team members and the project manager. The former approach gives a greater interaction with all team members, whereas the latter framework results in the project manager having less interaction and control with core team members, as illustrated in Exhibit 2.
Exhibit 2 – Project Management Relationships with Team Members
In today's economic climate, with ever increasing pressures on business survival, skilled, motivated, and high performing teams are essential. There are numerous group development theories that articulate team development and maturity and how they evolve into high-performing teams, thus determining their success or failure. One of the most well known models is Tuckman's four-stage development and behavior model (Smith, 2005), which is not necessarily a straight evolution. Tuckman's theory describes how a team matures, and as it does, how this relates to a need in leadership style changes. Exhibit 3 illustrates the basic four-stage model (Smith, 2005) and the relationship between the leader and team:
Exhibit 3 – Project Manager & Team Dynamics Based on Tuckman's Group Development Model
‘The most frequently heard complaint from team members is that they lack visibility on a day to day basis about the tasks that they are supposed to complete. If they are working on multiple projects at one time, they are often confused about task priority (West, 2012). Conversely, ‘project managers often complain that the reason they cannot achieve the project goal is that they do not have the right people.’ (Graham, 1989, p. 88)
The most common reasons why projects fail are: poor communications, lack of planning, lack of top management support, no quality control, inadequate coordination of resources, scope, and costs becoming out of control, suppliers or key stakeholders not included in the plan. The relationship between these common reasons for failure and the relationship and impact to a team are detailed in Exhibit 4
Exhibit 4 – Common Project Issues and Impacts on Teams
When a project begins to flounder, the project manager and the team come under increased pressure, with senior management going into micro manage mode. This, in turn, further undermines the project manager and team. At a time when a team needs the most support, the opposite often happens, with teams asked to work increased hours while activities become crashed at the expense of quality. While it is acknowledged that many people work better under a tight deadline, it is a mistake to assume that a team can work effectively under constant time and delivery pressure while remaining engaged and innovative with the work (Inderscience, 2009). Certainly in many troubled situations, where teams are put through these reactive measures, the effect is a downward spiral of exhaustion, de-motivation, and a descent into the blame game. It is important when assessing the health of a project to look at the emotional aspects of the team, as well as documented evidence.
A key area of research has been understanding why some teams develop and result in high team effectiveness, and why some teams do not develop and perform poorly, resulting in less effective delivery. There are many factors, which can sway how a team performs, but in particular:
- Organizational culture and its influence and impact on projects should not be underestimated, particularly those that are inclined toward a blame culture. A blame culture, which is fundamentally about retribution and control, encourage ‘the attitude of a person or a group of people of not accepting the responsibility for making a mistake in order to avoid the risk of being criticized or prosecuted’ (Campbell, 2011, p.1). Organizational culture and its relationship to management style and ultimately its connection to project motivation are shown in Exhibit 5.
Exhibit 5 – Organizational Culture Impact on Project Teams
- Emotions or moods have been identified as having an affect on the project team, for example, enthusiasm (Knight, 2009). A negative attitude will be detrimental to how a team performs because it will not provide the right type of leadership.
A case study with a global drug manufacturer, whose objective was to implement a new automated manufacturing and dispensing system, highlights the effect of organizational culture and leadership style on a project team. The program department did not have a high reputation for delivery, but the program manager had made an unsubstantiated promise to the business to deliver the system in a year. The organizational culture was hierarchical and renowned for the hiring and firing of personnel.
This complex project was to be delivered by a multicultural project team, with an off-shore development and test team. The team had a mix of permanent and contract staff, with numerous work streams. The project management office (PMO) had been trained on enterprise project software for which they only had the permission to use, not even the project managers were allowed to use it. This situation meant that the PMO had to attend all meetings, and were in a position of being the only ones who knew the project status. The planning had also been conducted by the PMO and had been done in silos. The plan lacked any depth or meaning. Leadership from senior management was based on a lack of trust with the team members, and bullying was rife. This situation resulted in the following outcomes with the team:
- Each work stream was put in competition with each other, and each individual was encouraged to only focus on his or her tasks, resulting in closed communications and no collaboration
- Without open communication, team members would only tell management part of the story so issues were submerged
- Sick leave by permanent staff and the churn of contractors caused a high loss of knowledge and constant re-teaching and re-work
- Team members had closer relationships with the PMO than they did with the project manager, and no members understood the overall project direction
The outcome was that the project was not delivered within the timeframe, and did not meet the business expectations.
Turning a Team and Project Around
One of the characteristics of a troubled project is the increased pressures due to time often being of the essence. Traditional approaches to turning a project around have primarily focused on analysis and reports, with potential team changes, all of which take time. In troubled project situations the team has reverted to Stage 2, Storming, in Tuckman's group development model (Smith, 2005), including team deterioration with the use of a traditional approach, which encourages teams to sit around in groups discussing why a deadline was missed or a project failed, and who was responsible, thus furthering a blame culture.
The Rapid Project Development ©(RPD) process and technique put at the center of turning around the project with team building on the following cornerstones, as illustrated in Exhibit 6:
- Visual: Although project management tools are essential for project delivery, not every team member comes from a project background, or speaks the same language and it can be very difficult to visually work with groups when building a plan. Additionally, there is evidence from studies to indicate that communication that has a visual component can be far more effective than communication that does not; however, there is evidence the most compelling communication combines both visual and nonvisual content (Campbell, 2011). The RPD process uses a visual approach.
- Team building: ‘Teambuilding activities are loads of fun, but they can also be tools for strengthening your group.’ (Wittneben,nd) Team-building activities in a troubled situation can be useful, but can also be counterproductive in time pressured situations, causing further irritation with team members, who can view these as a waste of time, and a distraction from their already pressured activities. The RPD technique uses the basis of team building principles but focuses the team on the delivery, while using these underlying techniques, by encouraging problem solving, lateral thinking, and collaboration in a supportive environment.
- Project planning: The RPD technique addresses many of the planning weaknesses and issues, and moves away from silo working, or individual project planning, and aligns and integrates the team, encouraging accountability and responsibility. Importantly for those in dispersed environments this provides a platform for understanding all the dependencies of the project, and enables relationships with the wider team to be built.
Exhibit 6 – RPD Team Building
RPD involves the following steps to rebuilding the team and turning the project around:
- Step 1: Management Support: it is essential to obtain the backing of management, and agree on the needed timeframe for delivering the strategy, while granting team members a blame amnesty.
- Step 2: Team Building workshop: rapidly develops a collaborative team and integrated recovery strategy
- Step 3: Restoration: converting the output of Step 2 into recognizable project management materials and maintaining the momentum and collaboration of the team.
The most fundamental step, which focuses on the re-commencement of team building, is Step 2. During the session a key role of the project manager will be to build the team through driving and facilitation of the session.
In the first case study of a project in trouble, the team was divided between Germany and the United Kingdom. A retail solutions provider had promised a customer delivery of four self-checkout machines for a specific delivery date. The project was nine months behind the promised delivery date, and the client was losing faith in the ability of the company to deliver. The team consisted of designers, developers, hardware implementers, implementers, and trainers.
In the second case study, a leading international insurance company wanted to deliver a new end-to-end customer online system to improve its services to its business customers. The client rollout involved over 700 clients throughout the United Kingdom and Europe; at the heart of the team was a sales team, who was in a dispersed environment, and responsible for the deliverables that would be required to deliver the project. This project was beginning to flounder, and customers had been promised a new system some months before, but nothing had been delivered and there was a high risk of the clients moving to other health suppliers.
In both cases, after establishing the individual perspectives and issues from the individual team members in the first week, it was agreed to hold an RPD workshop in the second week. Although technology can assist in overcoming distance, it is essential that there is budget to bring the key stakeholders together for this workshop in order to ensure, in the first instance that face to face contact is made to build the team and the recovery plan. Face to face communication is important to build dynamic relationships and form effective communication (Boyer, 2011). It is also essential that the project manager meets the team members to understand the types of characteristics of the team members that will need to be managed. In the case studies provided the following were some of the key players on the troubled projects: the ‘grenade’ person who waits until the last minute to divulge information, which can derail the project, or the ‘keeper of the knowledge’ for job security; or the ‘arm-chair sitter’ who waits for the team to come up with the information and plan but has no intention of taking accountability. These team member behaviors cannot be so easily identified over the phone, but can be recognized by body language.
The RPD workshop has eight key elements (Exhibit 7), which are designed to build the team. As the workshop progresses the behavior of the team members moves from individual to collaborative.
Exhibit 7 – Team Behavior and the RPD Step 2 Elements
Element 1: Ground rules
The first responsibility of the project manager is to establish the ground rules of the session, articulating what may be expected and the form of the session. Critically it is essential to convey that the accountability of the information remains with the team. The attitude of many team members at this point is that ‘time is being wasted,’ if it was not for this session they could deliver. Full engagement is not present.
Element 2: Objectives
It cannot be assumed that the project objectives are understood collectively by all of the team members, and at this point it will be on an individual basis. The team members are asked to articulate their understanding of what the overall project objectives are, rather than the project manager presenting the objectives, so that (i) the ownership is not totally with the project manager and (ii) the project manager can understand whether or not the team is on the same page. This begins to encourage open discussion‥
In the first case study, the team members were not on the same page and had varying opinions of what was being delivered. It took over half an hour to reach a common agreement on the actual scope of the project, with many arguments taking place. In the second case study, the objectives were at a vision level rather than having been vetted through the key stakeholders as to what was actually to be delivered.
Element 3: Mind Mapping
The same way the traditional approach for taking notes is in a chronological order, many project managers often resort to trying to put together a work breakdown structure or, worse, trying to complete a project plan with the team. When recovering a project, one of the off shoots of the blame culture is that people will seek to hide mistakes, and of course the damage done can grow while a mistake stays hidden (People Alchemy, 2012).
Mind mapping will (i) encourage dialogue and positive discussion and (ii) rapidly identify what work is remaining, particularly when someone may be holding back information.
In both instances, the individuals on the team began to realize what their team members had to deliver, and an understanding of the overall picture of what had to be delivered. In each case, the mind mapping took about twenty minutes, until team members slowed down giving ideas. This part of the session can also be used to stimulate and summarize what has been achieved to date.
Element 4: Benchmarking
Pressure on individuals will come from many different sources, outside those of the project team members, and therefore it is essential to get consensus from the team, so they are of one view. It is therefore important as a first step to establish if the project can still reach its target delivery, based on the information driven out of the mind mapping. If they cannot be met, then there is collective recognition, accountability, and consensus obtained that a new strategy will be required.
To do this, a large chart on brown or flip chart paper will need to have been prepared before the session. It will need to contain the following: (i) dates on the X axis (these should be on a day by day basis for the first three months of the project timeframe) and (ii) the milestone dates that have been promised by the project to the key stakeholders.
The first activities that are required to deliver the first promised milestone are then taken from the mind map, and the time, dependencies, resources and effort required are plotted against the first milestone. This is repeated for the second milestone.
It is a powerful part of the process, because if a team member after this changes his or her story, he or she will be asked not only by the project manager to explain how the original milestone, may be met, but also by the other team members.
In both instances, it took five minutes for the teams to collectively realize dates that had been promised to management could not be achieved, due to dependencies of work required by other team members, rather than just their own individual tasks.
Element 5: Producing the Recovery Strategy
At this point in the workshop process, the team will now begin to work in collaboration, and not as individuals, thinking laterally, with collective problem solving as they begin to work through solutions and a way forward, still taking the information from the mind map.
As each step of the recovery plan is plotted on the chart, each team member can understand the dependencies, resourcing requirements, and risks around each of the activities. Importantly, each person present, by undertaking this activity moves from silo working and into full team accountability. Exhibit 8 illustrates a high level view of the chart.
Exhibit 8 – High Level View of a chart from Case Study 1
Element 6: Recovery Outputs
The tangible outputs from this workshop will include: an integrated recovery strategy and plan; the risks and issues as they pertain to the recovery plan; resources required; clear dependencies and constraints and immediate actions. Critically, the team will be working and thinking collectively.
One of the key challenges in the workshop will for the project manager to ensure that all team members communicate and participate, and that no one ‘opts’ out by not communicating. As on any project, there are numerous characters that need to be observed: the person who does not divulge information until at the last possible point, the person who opts out, the person who is a political appointment, or who is just there because there is no other place and so forth.
Step 3: Restoration
To maintain the momentum and to continue to build the team it is essential that the project manager takes the materials and converts them into recognizable project material. This project plan and the associated details need to be collectively played back to the project team members, to ensure agreement and pick up on any changes. Occasionally, team members will come back to the project manager, to advise that they have not disclosed information or that dates they committed to in the workshop may not be able to be achieved. In these instances, the information will then need to be communicated to the rest of the team and the project materials updated.
Ongoing challenges for the team that are likely to be faced are:
- Senior management may not accept the revised dates and will challenge them. The team will be at this point in full consensus so the evidence can be easily presented and discussed
- Many team members are in a matrix situation, and either have other operational priorities or other projects they are involved with; therefore, once the workshop is complete it is important to re-enforce each person's commitments in the workshop, due to time constraints of other priorities.
- Fundamentally, the project business case still needs to be viable. The budget will need to be re-confirmed or revised, and the outcome may be that the business case is no longer viable. In case Study 2, it transpired that the following had not be considered, (i) what it would take to transition the customers, and the resources required and (ii) the support required to support both internal and external users. As a result, the business case was no longer viable, and an executive decision was taken to sell off this part of the business.
Waterfall Agile Comparison
The type of project will determine the approach taken to delivery (e.g., Waterfall or an agile framework). In either case, this simple process and technique can be applied to put the project back on the road to recovery and bring the team together. The team roles in the Step 2 workshop should remain essentially the same in both types of projects (e.g., Test Manager, Business Analyst, Business representatives, Suppliers, Change Manager and so forth). On an agile project, with a Scrum approach the ScrumMaster, an instrumental member, needs to be present, as well as the Lead Developer.
Social Media and Technology Impact on Team Building on Troubled Projects
Undoubtedly, new technology and social media speed up communication and make it easier. Use of internal and external communication systems has been effective in bringing a virtual project team together; daily communication (in lieu of face-to-face), often called communicator or external technology, such as Skype, Webex facilities, or Kanban boards have made communications much easier across distributed and virtual teams. These tools enable virtual team members who need to work closely together to stay informed and in touch, keeping project costs down by not having to be collocated. External social media such as Linkedin, Twitter, and Facebook needs to be used with care, as company confidentially should not be breached.
Many times, team problems can occur through a lack of communication and understanding because there is a “holder” of all the project documents or they are inaccessible to some team members, causing delays, misunderstanding, and miscommunication. Most companies now use technology to facilitate document management, including Dropbox and SharePoint. These tools have many capabilities. The key elements pertinent to increasing team effectiveness and efficiency include managing document versioning within amid and among virtual/distributed teams and accessible project management documents and information.
However, new technology does not negate the need for formal and regular communication or face to face communication. On troubled projects, when teams have to be rebuilt, it is essential that there are face to face meetings, so that relationships can be built. Once an understanding and trust are, rebuilt then technology assists in maintaining these communications.
Teams on troubled projects have often regressed into a blame culture, which destroys key team attributes for project success, such as trust, open communication, and relationships on which high performing teams are founded. The RPD© process and technique can be deployed to assist in rebuilding these key elements needed to refocus and motivate the team on the overall goals of the project. However, the organizational culture, positivity, and leadership skills of the project manager are vital to the success of re-building the team.
Boyer, A. (2011). The importance of face-to-face communication. Retrieved from http://randjpr.com/blog/the-importance-of-face-to-face-communication/
Campbell, N. (2011). The blame game. Granite Consulting. Retrieved from http://www.graniteconsulting.com.au/granite-consulting-com/_img/Blame.pdf
Fifield, D. (2010). World Cup 2010: Five reasons for England's failure. The Guardian. Retrieved from http://www.guardian.co.uk/football/2010/jun/28/england-failure-world-cup-2010
Graham, R. (1989). Project management: As if people mattered. Sydney: Primavera Press
Inderscience (2009). Teams are not innovative when under constant time pressure. Science Daily. Retrieved from http://www.sciencedaily.com/releases/2009/04/090424114317.htm
Knight, A. (2009). Positive affect and project team development and effectiveness (doctoral dissertation). University of Pennsylvania, Philadelphia. Retrieved from http://proquest.umi.com/pqdlink?Ver=1&Exp=08-20-2017&FMT=7&DID=2016832911&RQT=309&attempt=1&cfc=1
People Alchemy Ltd. (2012). The effect of a blame culture. Retrieved from http://www.alchemyformanagers.co.uk/topics/r9S9hRuUHQMJTDfB.html
Project Stakeholder Management(2008) Definition of Project Stakeholders. Retrieved from: http://www.projectstakeholder.com/
Smith, C. (2012). Great Britain makes most of London Olympics with massive medal haul. Forbes. Retrieved from http://www.forbes.com/sites/chrissmith/2012/08/08/great-britain-makes-most-of-london-olympics-with-massive-medal-haul/
Smith, M. K. (2005) 'Bruce W. Tuckman - forming, storming, norming and performing in groups. The encyclopedia of informal education. Retrieved from www.infed.org/thinkers/tuckman.htm.
Sundstrom, E., DeMeuse, K. P., & Futrell, D. (1990). Work teams: Applications and effectiveness. American Psychologist, 45, 120–133.
Turmel, W. (2010). Three reasons why virtual teams fail. MaaS360. Retrieved from http://magazine.maas360.com/article/669-three-reasons-why-virtual-teams-fail/
West, C. (2012). Four common reasons why projects fail. Project Insight. Retrieved from http://www.projectinsight.net/white-papers/four-common-reasons-why-projects-fail.aspx.
Wikipedia (2010). Tuckman's stages of group development. In Wikipedia, the free encyclopedia. Retrieved from http://en.wikipedia.org/wiki/Tuckman%27s_stages_of_group_development
Wittneben, J. (nd). Teambuilding games and activities. SSC Teambuilding Games and Activities Ohio DECA Summer Leadership Retreat. Retrieved from http://www.deca.org/_docs/chapter-resources/DECA-teambuildinggames.pdf).