The True Role of a PM on Agile Projects
Blog Award Nomination

Team Solving: The Under Utilized Power

Team_solver_2 All projects face problems, but fortunately your team members have the best solutions.

Projects rarely go exactly to plan; they have a nasty habit of uncovering gnarly problems that were not anticipated, but need to be solved. This is illustrated nicely by Doug DeCarlo in his book Extreme Project Management.


The top black line depicts the planned approach moving in orderly fashion from start to finish. The lower blue line depicts how projects really progress with side tracks and setbacks as obstacles are encountered and overcome.

Yet, in attempting to solve these problems project managers too often overlook the best source of solutions, the project team. In this post I will outline why the team has the best practical solutions even when they may not be the best theoretical solutions. An example will probably help about now.

While managing a government project during an IT vendor change, we needed to quickly build rapport with the business users of the system and subject matter experts (SME) in order to maintain the development pace from the previous team. The problem faced was how do we get to know the business folks better and connect the team members and SME’s . Rather than contriving some project social event and trying to get buy-in from the business and team I presented the problem to the team in a planning meeting.

After some back and forth a team member suggested, that since quite a few of the business people went 10-pin bowling, then perhaps we should arrange a bowling social event. Others concurred, ideas for mixing the teams up (not us vs. them) were brainstormed and we ran the event. It went really well and led to other activities all of which greatly contributed to a strong relationship and a successful project.

As the PM I could have instead consulted the PMO, HR, or social psychology experts to determine the optimal team building event, but then I would have had to have sold it to the team. Here lies the first power of team solving:

Team Solving Power #1: By asking the team for a solution we inherit consensus for the proposal

The fact that the solution came from the team and not me, meant I did not have to sell it, it already had support. It is easier to steward a sub-optimal solution with good support to a successful outcome than build support for an optimal solution and ensure its successful execution. If challenges arise and people subconsciously ask “who’s bright idea was this?” the answer comes “Oh yeah, it was ours” and they are more likely to continue.

Team Solving Power #2: Accessing a broader knowledge of the facts
Team members are closer to the details and bring additional insights other than your own. I did not know that the business folks bowled, this was collective knowledge (Chris knew three users bowled and Julia knew two SME’s did also) together we found a new piece of useful information. Asking the group taps the collective knowledge of the team.

Team Solving Power #3: Solutions are practical
Anyone who has worked hard to craft a solution only to be told “That will not work here because...” will know how frustrating and disheartening these words are. Team sourced solutions have been vetted for practicality and, because created internally, solutions found for implementation issues.

Team Solving Power #4: When consulted people work hard to generate good ideas
Good_ideas The simple act of asking for suggestions engages team members beyond the role of “Coder” or “Tester”. People appreciate having their inputs valued and generally work hard to create innovative and effective solutions.

Treating workers as interchangeable resources is a poor model inherited from the command-and-control methods of the industrial revolution. Leading companies such as Toyota and 3M recognize that their best ideas come from inside their companies and we need to make use of this intellect. It is partly due to these methods that these companies innovate better, have higher quality products, and better labour relations.

Team Solving Power #5: Asking for help shows confidence not weakness
Asking for ideas and solutions to problems is not a sign of incompetence or an inability to manage. Just because we ask for input it does not follow we are dumb. Instead it demonstrates valuing the opinion of others, and being thoughtful.  In essence it demonstrates how all problems should be tackled, which is the next power

Team Solving Power #6: Seeking ideas models desired behaviour
Project managers have a leadership role of “modelling the desired behaviour” i.e. behave as we wish others to behave. If we stay silent, make decisions with incomplete awareness of the facts, and do not ask for help when we need it, what message is this sending to the team? Well, it is an obvious message that we expect team members to behave the same way and work in isolation. Lots of time and money is wasted on team building activities that are then eroded my management-in-a-vacuum.

By demonstrating good problem solving techniques team members are encouraged to solve their problems this way too. Teams that can effectively problem solve and build support for solutions are the real powerhouse of successful projects. We need to make sure as a leader we are supporting and mirroring these best practices


People do not want to be treated as work drones, ask them to think and they will amaze us with innovative, practical solutions that have great backing from the people that need to implement them. I used a trivial example of a team building activity because it was quick to explain, but this approach works best on complex, embedded process problems that would take days to outline to an expert. The team has the first-hand knowledge of the problem and more importantly, knows what is practical to solve it.

Of course this is no silver-bullet or panacea. Here are some cautions we need to be aware of.


Real problems - We should use this on real problems only, not on which brand of printer toner to buy. Remember we are modelling desired behaviour and if people take it too far and consult their team mates when deciding what colour dialog box to create; no work will get done. It is a tool for when you are stuck and the problem is important.

Poor team cohesion – If the team is fragmented and has opposing groups then resentment for “fixing their problems” will undermine the process. We need to get the team aligned for team solving to be most effective.

Team and Project Changes – Over a long period if a significant portion of the team changes, we need to re-canvas the team to ensure they are still on-board with the approach. Exercising the bright ideas of others is nearly as bad as not being consulted; we need to ensure people still agree this is a good policy. Likewise if the project changes significantly, we need to checkpoint in light of these new facts and get the team to review the approach.

Follow-through – once you ask for solutions make sure you follow through on them with execution. It is pretty demoralizing to be asked to work on a solution and then see it wither. It is fine to go back with implementation problems that need to be solved, but don’t waste peoples time by asking for input and then ignoring it.

Your team has the best solutions to your project problems. It is ironic that Toyota proved they could engage the internal problem solving skills of a workforce previously written off as a “hostile, uncooperative and lazy” by GM management to turn around the NUMMI production plant in Fremont, CA; yet most software projects are populated by smart, well educated people and we treat them like production line robots.

People relish inclusion and an opportunity to solve problems so unleash the Team Solving power on our projects.

(In a future post I will outline some tools and facilitation techniques to help run these problem solving meetings, but for now a great way to start is to outline the problem and all the issues candidly to the team, ask for help and then shut-up while they discuss solutions.)



Nice post. I find that command and control ultimately lowers motivation and inspired thinking from teams.

By giving true ownership to the team, you get better solutions, even if there is more conflict initially. I've seen lots of first time managers try to control projects by setting deadlines and promising results to stakeholders without actually getting buy in from the team. It's amazing how much more likely you are to get a result when team members estimate their own work and commit to their own deadlines.

The comments to this entry are closed.