When Good Projects Go Bad
Symptoms of this all too familiar problem include: a lack of business context to the problem being solved, communication breakdowns across functional groups and finally, the project plan execution not reflecting the current preparedness of the team. Typical attempts to fix these problems involve team retreats, the ceremonial sponsor motivation speech, and most widely attempted-altering how meetings are run. All of these strategies can help, but they do not address a fundamental issue of how teams become effective units.
What if the missing ingredient is how teams learn? What would it mean to be part of a self-characterized "learning team"?
One way to define a learning teams is "a group that continuously tests and updates the experience of those around them, then transforms that experience into improved work processes and knowledge that is accessible to the entire team and relevant to its core purpose."
Put in English, maybe the missing piece is not a well defined project plan, but how comfortable the team members are in telling the truth about their roles, tasks and dependencies on each other. This focus requires dialogue and reflection, with an emphasis on eliminating "group think" that prevents people from exploring alternative approaches and creative thinking.
The Key Ingredient
At the heart of an effective learning team is leadership that actively manages the learning process of the group. In many organizational initiatives, project managers have come up through the ranks starting as technical experts, then moving into managerial roles. Their ability to understand and debug technical problems may be strong, but getting the team to operate on all cylinders is a different matter.
Technologists turned project managers need to strip away assumptions of what members "should be able to do" to accept a greater emphasis needs to be placed on the "process of learning". For example, functional leads may understand the ins-and-outs of a particular program, but place little emphasis on communicating their progress to others who are dependent on them. Additionally, they may keep technical problems that are difficult to solve to themselves for fear that others will negatively judge their appropriateness on the team.
Great team leaders understand that groups learn by trial and error, just as individuals do. Without a leader who is able to extract open dialogue across the team, people will quickly form sub-groups that can inadvertently sabotage each others' progress. When you start to hear things like "That's not my responsibility" or "At least my piece is done-it's no longer my issue", the problem has taken root.
It's the equivalent of musical chairs, or hot potato, with everyone focused on not being left holding the bag.
Framing the Challenge
How do great leaders approach teams in the learning process? The first step on a complex project is to frame it as an organizational initiative versus technology initiative.
Because leaders of complex projects often bring strong technical skills, it makes sense they would be managing it as a "technology project". It becomes much easier to immerse the team in deliverables and deadlines based on the technology and not on how it impacts the organization.
Framing the initiative as an organizational versus technical challenge shifts how the team approaches learning on two levels. One, learning becomes more about how the team needs to address organizational issues versus merely acquiring individual technical skills.
Two, the emphasis on organizational impact requires the team to better communicate across functional groups on the impact of each others' work. This reframing will help break down the silos that form across groups.
How Perfect Do I Need To Appear?
For the group to value and work in a learning environment, project leadership needs to make it safe for people to make mistakes. Nothing slows down individual or group progress faster than reluctance to make mistakes. "Trial and error" is at the heart of skill building, and when it's not explicitly encouraged, people won't risk making mistakes, especially in public. On project teams, making a mistake and revealing it is tantamount to inviting people to accuse you of being the wrong person for the job.
For the group to value and work in a learning environment, project leadership needs to make it safe for people to make mistakes. Nothing slows down individual or group progress faster than reluctance to make mistakes. "Trial and error" is at the heart of skill building, and when it's not explicitly encouraged, people won't risk making mistakes, especially in public. On project teams, making a mistake and revealing it is tantamount to inviting people to accuse you of being the wrong person for the job.
What Are We Working Toward Anyways?
It cannot be stated enough that articulating and clarifying the core purpose of the initiative is critical to leverage internal learning. There may be effective collaboration, with the focus on organizational versus technology impact. There may even be real-time reflection that makes people feel comfortable acknowledging mistakes in the learning process. But without a clear group understanding of the intended outcomes, there will be great teamwork leading to poor results.
Ask every member of your team to describe the core purpose of the project. The greater the difference in response, the more work there is to be done in clarifying project purpose. Leaders need to chart a course to a commonly understood destination, with little ambiguity among the group.
The best laid plans with a talented team will fall flat if project managers do not look honestly at the team. With active leadership that frames the challenge in organizational terms, along with explicit permission for people to acknowledge mistakes, teams will set aside the "what should be" with "what is", helping them become a true learning unit.
Presentation Tip
Handouts either serve the live presentation or are good takeaways — not both. Too often presentation materials are designed to be used by participants after the presentation. This becomes the "takeaway" documentation that people so desperately want.
The problem with takeaway documentation is it is often written like a novel, which makes for poor presentation aids. The speaker then does the unthinkable: he reads the slides to the group!
If you want your audience to not stick pins in a voodoo doll that looks surprisingly like you, create succinct bullet points, not sentences. If you need your audience to have a fuller explanation of your slides on paper, give out a separate document at the end of your talk.
