Sick and tired of leading lousy teams? Here’s what to do

As we enter a turbulent century, more organisations are looking for new ways to respond to:

  • the growing demand for speed and accessibility of services,
  • the emphasis on delivering an effortless, integrated customer experience
  • radical innovation in technology, technological concepts and platforms,
  • the trend towards a more globalised environment, social responsibility, and
  • uncertain economic pressures.

Challenges at the workplace are so complex, they cannot be solved by a single person, but by a team. Though all teams are groups, not all groups are teams. Groups are made up of two or more people with shared characteristics. Teams, on the other hand, come together to bring about an agreed beneficial change within a fixed duration. In short, teams are formed to accomplish projects.

Teams can either make or break a project. Besides the Project Leader and Sponsor, the real foundation of a good team is people who:

  • dedicate themselves to making the team succeed, are willing to collaborate with others to reach a mutual benefit,
  • possess the requisite knowledge, skills and experience, and
  • become excited at the notion of contributing to a project.

When a project is started, there is often no clear idea about who the specific members are. Organisations frequently make the mistake of picking a member just because he is available, rather than because of his ability. Although effective teams are made up of people with different abilities, it makes sense to pick members with knowledge, skills and experience that are relevant to the project.

Before a team is created, the Project Leader and Sponsor should work out the general direction of the project. For example, is the project process-driven? Does it require changes to an enterprise resource system? Will it modify a long-standing policy? These questions will help the Project Leader and Sponsor pick the correct members for the team. More importantly, though, it will also help the Project Leader and Sponsor assess if existing employees need training, and secure the necessary funds for it. Early planning for teams is essential, and will result in a Team Charter, as well as a Team Profile.

The Team Charter

It is natural for each team member to possess different ideas about the project. Persuading the team- especially cross-functional ones– to travel along the same direction can be challenging. A simple tool like the Goals, Roles and Procedures Pyramid may serve as a useful map. Split into four levels, the Pyramid also doubles up as a powerful troubleshooting tool. If a problem appears at a particular level, for example, the team should look up one level in the Pyramid to discover its root cause 1.

Project Goal

To be effective, teams must maintain contact with the goals of the organisation 2. Therefore, project goals must be firmly linked with the organisation’s mission, vision and strategies. As the project’s goal becomes clearer, so does the team’s purpose. Both are interrelated.
All teams benefit from a shared vision of what the project will achieve, as well as a general idea on what effort is required to deliver outcomes. Project Leaders and Sponsors have a special responsibility to describe how the team’s efforts impact the larger organisation.

When the team works on something they know is important to the organisation, its members become more motivated to give their best. Hence, purpose is the most significant reason for a team’s success. It furnishes the team with focus, as well as direction.

Project Roles

Project Leaders are usually the managers of the day-to-day business functions that will be impacted by the project; while Sponsors often own and control the resources that are required for the project to succeed. Both Project Leader and Sponsor must be in complete agreement about the project, its outcome, and the other key roles that team members will serve in the project. Other key project roles 3 might include:

  • Client: Coordinates or represents the interests and needs of of end-user groups. If there are several end-user groups, each with a differing view, there may be multiple clients.
  • Information Technology Expert: A required resource if the project involves information technology or impacts an enterprise resource system.
  • Technical Specialist: People who possess expert essential skills or high levels of crucial access.
  • Buyer: They procure or commission projects on behalf of end-users and are judged primarily on their ability to source for reliable suppliers and negotiate competitive prices on contracts or services.
  • End User: Often, to streamline and aggregate the concerns of this potentially large group, end-users are represented by clients. However, this does not mean that the project will not benefit from directly communicating with this group at different stages of the project.
  • Quality Assurance: Although popular only in large, protracted projects, the Quality Assurance expert plays a very important role in ensuring that prescribed methodologies are carried out properly.

Experienced Project Leaders sometimes introduce a RACI Matrix to outline the project-related activities that are expected from each Project Role. The RACI Matrix is particularly effective for large, complex teams whose members carry out multiple roles, as it neatly defines the key responsibility areas of members who are:

  • Responsible
  • Accountable
  • Consulted
  • Informed


The Pyramid outlines the general procedures that are required to sustain the project’s momentum, such as the form and frequency of official meetings. Because different project frameworks exist, the methodology that the team intends to adopt for its projects should be mentioned, to provide a useful reference point for future projects. Some examples of project frameworks include Lean Six Sigma’s DMAIC, Agile’s SCRUM, or the omnipresent PDCA method.

At an early stage, Project Leaders must work together with the team to establish ground rules. Ground rules determine:

  • How team conflicts are handled,
  • How project decisions are taken, and
  • A code of conduct that emphasises clarity and respect during discussions and team meetings.

When teams possess a strong understanding of how their work will proceed, they become particularly effective in carrying out their duties.


Team members are individuals who have their own set of motivations and temperaments. When brought together, conflict is likely. Although most people associate conflict with anger and tension, it can be a positive force in projects. Conflict deepens discussions, forcing members to become more creative, and examine new ideas more thoroughly. Besides leading the effort to establish ground rules, Project Leaders must also develop plans to quickly bond the team. In the longer term, Project Leaders should acquire the necessary facilitation skills to manage conflict.

Relations must be managed at a broader level too, as it is vital for teams to know how they interact with other teams, departments and customers. The Project Leader and Sponsor must ensure that the lines of communication between the team and the larger organisation remain open and in working order. Key questions that teams frequently confront are:

  • How to ask for assistance from other teams or departments if it is needed?
  • How to obtain the data that it needs?
  • How to let the organisation know what they are * doing?

Team Profile

When teams form, they are rarely able to unlock the full knowledge of every member. Human capital remains locked because teams always get dominated by the most senior, vocal or confident member, even if they are not the most expert. The genuine experts, sensing that their views would not be appreciated, shut down and take a back seat.

A simple intervention, performed early in the team’s formation, can stop this negative outcome. When teams work together to create a detailed profile of every individual’s knowledge, skills and experience, they are more likely to use their knowledge to devise solutions to problems. In a study on this phenomenon, Professor Bryan L Bonner explains that the simple exercise can radically change the criterion for team power from Social Influence to Information Influence 4.

By listing out a team member’s abilities and how it relates to the project, individuals feel valued and become more engaged. It also helps the Project Leader and Sponsor identify the abilities that are immediately available, as well as any skills deficit that can be addressed either by training and development, or acquiring outside help.

A comprehensive team profile forms the baseline of knowledge, skills and experience at the beginning of every project, and helps the organisation measure the learning outcomes of the project, celebrate the growth of individual team members, and identify potential Leaders for future projects.

Show 4 footnotes

  1. Thus, if teams encounter problems in Relations, the actual cause might be found in unclear or conflicting Procedures. See Mary Federico and Renee Beaty, Rath and Strong’s Six Sigma Team Pocket Guide (McGraw-Hill), pg 63
  2. Peter R Scholtes, Brian L Joiner and Barbara J Streibel, The TEAM Handbook, Second Edition (Oriel Incorporated Publishing), pg 1-3
  3. Peter Hobbs, Essential Managers Project Management (Dorling Kindersey Limited), pg 18
  4. Bryan L. Bonner and Alexander R Bolinger, Bring Out the Best in Your Team (Harvard Business Review, September 2014), pg 26

Mapping team life cycles the right way

Working with teams, I am often surprised by the variety and depth of emotions that individual members express, from initial fear and anxiety, to delight once the project gets underway. Over time, I began to recognise patterns at different stages of a project’s life cycle. The infographic aptly illustrates the 5 main stages.

Not considering cost of quality is dangerous

In projects, teams often have a difficult time quantifying tangible benefits. This is tragic, since tangible benefits are an important way that teams communicate their achievements to the larger organisation. Moreover, tangible benefits help secure buy-in, especially from the organisation’s senior executives. Amongst the most enduring tangible benefits that are articulated are:

  • Labours Costs– a process that initially occupied 10 employees now occupies 4 employees. The savings are derived from the total estimated wage of the 6 employees that have been removed.
  • Material Costs– a process that initially required 20,000 sheets of paper to be printed now requires none. The savings are derived from the total retail cost of the 20,000 sheets of paper. Associated with this is also the cost of printing, which includes toners, staplers etc.
  • Cost Avoidance– a department resists a vendor’s attempt to raise prices by 5 percent, allowing the department to avoid spending an additional $200,000 that year. This usually involves avoiding a future cost increase by delaying, reducing or even eliminating a proposed price increase.
  • Cost Recovery– a department reclaims money that was previously spent on items that are now considered obsolete. Usually, this entails selling equipment back to a supplier, or to any other interested parties.

A tangible benefit that is frequently ignored is Cost of Quality, or rather, actions taken to ensure that a particular product or service meets expectations. These quantifiable activities may include:

  • Verification– costs of labour and materials that are needed to check incoming service, product or process setup.
  • Supplier rating– costs of labour and materials that are needed to assess and approve suppliers.
  • Waste– costs of labour and materials dedicated to performing unnecessary work as a result of errors, poor organisation or communication.
  • Scrap– Defective product or material that cannot be repaired, re-used or sold. Rework or rectification– costs of labour and materials needed to correct defective materials, services or errors.
  • Failure analysis– costs of labour and materials associated with activity to establish the causes of internal product or service failure.

Just about a month ago, my friend Mark submitted a request to his company’s IT department to set up a web server. The first person to receive the request was a Service Representative, who collected all the necessary information. The request was then passed to the Infrastructure team, who promptly asked Mark the same information that the Service Representative had earlier collected. Mark did not know better, and gamely repeated the same step he had done with the Service Representative. Then, Mark’s request was passed over the the User Accounts team, who, to Mark’s utter amazement, began to ask the same questions that the previous two parties had asked. Mark began to feel frustrated and wrote a complaint email to the the IT department. The IT department was apologetic, and promised to retrieve the information from the Service Representative.

Now, if the IT department had had a proper process in place, Mark would not have had to restart his application at every point in the request process. This would have saved a lot in terms of lead and cycle time. Waste is one of the most destructive Cost of Quality. Frequently, business units that are not organised properly cannot see waste, but waste is extremely visible to the customer.

The Ultimate Cheat Sheet on project selection

Modern businesses recognise the importance of driving innovation and continuous improvement through team-based projects. This does not mean, however, that organisations have gotten smarter at selecting the correct type of projects. In this cheat sheet, I list four mistakes that are commonly made, but easy to avoid.

Selecting problems that no one really cares about

It’s tragic, but teams, departments and business units still choose projects that nobody cares much about. Often, it’s because the scope of the perceived problem appears too minute, or the potential project might not be critical to business objectives. Whatever the case might be, a neglected project suffers from corporate inattention, and the team involved in it will wilt.

Selecting a solution to implement rather than a problem to investigate

Nothing alarms me more than facilitating a team of employees who, instead of investigating the root causes of a problem, have already determined the solution. I find this fairly typical in projects led either by newly-minted IT Professionals or employees who have grown too close to the process.

In this instance, a team of managers working at a college admissions office might describe their project with an ambitious title like: Automate the fee payment process with an online application. The title is already a warning sign that danger lurks ahead. By enlisting words like automate and online application, the team has already made up its mind on the solution. No problem was investigated.

There are very little exceptions to the rule. Projects should always be described from a process standpoint. The team from the college admissions office would do their project far greater justice by describing it as an effort to Reduce the turnaround time for students paying school fees instead.

Selecting a process that is in transition

Businesses nowadays face lots of turbulent change, either in technology or in regulatory compliance. Inviting teams to improve a process or function that is going to be changed soon will only waste company resources. There is no point investigating a manual leave application process, for example, when some other team is independently migrating it to an Enterprise Resource Planning (ERP) system. The work being done by the first team would quickly become redundant.

Selecting a system to study, rather than a process

A common error committed by new teams is to be too ambitious for their own good. Instead of breaking a project up into manageable bits with short durations and clear targets, they attempt to take on an entire system or framework of business functions at once. Leave such high-order improvements to management teams or portfolio managers. Ongoing work improvement teams have a better chance of success if they focus on a smaller process to study and subsequently improve. Realistic timelines and targets make for more motivated teams.

Are there particular types of projects that you consistently avoid? Do share by commenting on this post!