Sunday, 27 December 2009 00:00

Name Just One Thing... A Team Building Unexercise

Rate this item
(0 votes)

I have always enjoyed being part of team building exercises. The one where you close your eyes and fall backwards hoping that your team members catch you is my favorite. It reminds me of an amusement park ride. There is always the thought in the back of my mind that some trickster will let my head crack on the floor. I think it adds more excitement. However, team building exercises only go so far and normally fail to reach their objective. They are too transient. The event happens, the manager checks off the list to show the task is done and he or she goes back to managing the team with status reports, task assignments by email and visiting people only when something goes wrong.

Case Study: Name One Thing

A project had completely stalled and was showing no outward signs of progress. The Recovery Manager assembled the team and asked them to answer one question "What is the one thing that the customer would look at and say ‘Wow, I wish I had that today'?" After multiple meetings, the team came up with the answer—the ability to print a customer record. The print feature was elevated to the hottest item to develop. It was unimportant if it met the full set of customer requirements, they just needed to see a prototype.

The prototype was shown to a select set of customers with the explanation that it was a prototype and still needed significant work. The result was as anticipated, word spread like wildfire that the team had made tangible progress.

At this point, the customer was unaware that the project, a big bang deployment, was going to have to be phased. This demonstration helped in the negotiations since it would be difficult for the customer to deny the value of releasing the feature early.

In contrast, there is the group of people that have been on that project from hell. They are a team. They wear that project with pride, like the multi-colored, burnished decorations on the chest of a four-star General. These people give each other hugs, buy coffee and talk about the time that Joe slept in the crawlspace between network pulls and Jill cranked out hundreds of lines of code while QC was testing until the wee hours of deployment eve. "Man, those were the good old days," you hear them say, talking like Viet Nam vets gathered around the campfire.

In one case, the team building lasts few hours; in the other, it lasts forever. The difference is the former had a completed mission the latter was only talk. Even if the mission had a dubious success, the team lived through it and created a bond that is nearly impossible to break. That is the team-building event—delivering something that provides value, vision or velocity.

Defining The One Thing

The best item to deliver is something the customer can sink their teeth into. This brings the team pride. It creates confidence between the team members and builds the customer's trust in them. This in turn builds even more pride inside the team. It is a wonderful snowball effect that yields great returns. The trick is finding that one thing early enough in the project to get that early win. The inset case study gives an example of what was done on one red project recovery. There are many others.

My favorite is when maintenance is included in the project. Maintenance is an easy target since it should never be in a project. Getting it out of the project makes everyone happy—almost everyone. Customers and end users detest waiting until the end of a nine-month project for bug fixes and engineers hate having to wade through bugs while they are trying to add new pieces to a system.

The solution is easy. While part of the team is dealing with the planning and the design functions, have a small subset of the team do the maintenance tasks and, if feasible, deploy them; otherwise, simply build a clean tested system ready for the rest of the team. Either way, the customer sees progress and is happy to know the team is making tangible progress.

Yes, there are people frustrated by multiple updates and the associated cost. Customer satisfaction, though, usually outweighs these concerns.

If All Else Fails

If success cannot be shown by building simple prototype or deliverable, identify something to streamline the project. There is always an overhead process or ongoing task that is waiting to be removed. Maybe it is a redundant status report or an unneeded meeting. Excess processes hang around, because... well... that is the way it has always been done. Process improvement makes people happier, they work more efficiently and will save the organization and project money. The customer will be pleased, too. If a process truly cannot be found, determine whether the team has been overlooked for a computer refresh or tool upgrades. Although these actions are usually done to build trust in the Project Manager, they go a long way to building the team.


Success in a project needs to start early. Success requires a team. Early wins instill success in the team. The cycle feeds upon itself and grows. Teams dreaming of success are far less apt to be successful than team that start with little successes. Give them a win and they will perform beyond your wildest dreams.

Read 3758 times

Related items

  • Success vs Culture

    The other day a Latvian student contacted me for my views the connection between culture and success criteria—an important and intriguing topic. After working in Taiwan, Singapore, Korea, Japan, Israel, United States, and Canada, I wear many scars of both blatant and subtle cultural violations. I also know that within a culture one person's success is often another person's failure. So, after dispelling concerns about clicking on some random email link, I completed her survey (please feel free to take it yourself). In the process, I struck up a friendship with the student, Kristine Briežkalne, who is studying at Riga International School of Economics and Business Administration . She has some interesting views and presented me with a Venn diagram showing four frames to a project (business, client, project management, and growth perspectives) and how they intersected. As the diagram is part of her Master's thesis, I will let you ponder the how to label the overlapping areas (an eye-opening exercise).

  • Kill The White Knight

    There is a reason we do not teach classes on fixing failing projects. Many a cynic feels that we simply do not want to teach our trade, however, our reason is far nobler—we should be teaching prevention rather trying to create white knights to save the day. It is the same philosophy as building a fence at the cliff's edge rather than an emergency room at its base. Our language is replete with idioms telling us to look past the symptom and address problems at their root cause. 'An ounce of prevention versus a pound of cure' or 'a stitch in time saves nine.' Please, feel free to supply your own in the comments. Unfortunately, most of our businesses loathe this philosophy, waiting to address an issue until it is irrefutably broken.

  • Tales of an Expert Witness: Sex, Lies, and Video Tape (Part II)

    Trust relationships, certifications, and standards sound like such a safe harbor. These sound like such great words in a proposal or statement of work. How could you possibly go wrong building a trusted relationship with a customer by committing to follow a standard? In fact, this can burn you… in court.

    No one ever starts a project with the goal of ending up in court. In fact, litigation may never cross your mind; after all, you have built a trusted partner relationship. Taking a few cautionary steps, however, will make your life easier if you end up in that ill-fated litigious position. Your best chances for success come long before you enter the courtroom—even before the project starts.

  • Comparing Organizational Change Management Models

    A few weeks ago, I set out to write a post on the comparison of various organizational change management (OCM) methodologies and realized that would be a disservice to my readers. It would simply drag you down the path of implementation while failing to focus you on building the foundation. The pressure was too much and I have relented to numerous requests on making that comparison. The caveat is that juxtaposing these models is not comparing different varieties of oranges or even apples and oranges; we are surely comparing the peel to the fruit they contain. Hence, comparing methodologies like Kotter's model (the peel), Prosci's ADKAR (the core), and General Electric's Change Acceleration Process (the whole fruit) need a different approach.

  • The Executive-Project Manager Gap

    It was such an innocuous question, "Working on an article; what is the biggest problem you see with project governance at orgs? Can you comment?" Can I comment? Really? That is like cheese to a mouse. Where could I start—bureaucracy, draconian process, poor executive sponsorship, disengaged leaders? Plenty of fodder, because they all lead to project failure. I fired off, "Creating an over bureaucratic morass stifling innovation & implementing process instead of cultivating leaders." Then the maelstrom started and it went directly to the gap between the executives and projects managers. Naomi Caietti, Robert Kelly and I had a great conversation. Most of the thread is below.

Leave a comment

More Info on Project Recovery

Tell me More!

Please send me more information
on fixing a failing project.

Rescue The Problem Project

Internationally acclaimed

Image of RPP

For a signed and personalized copy in the US visit the our eCommerce website.

Amazon logo
Buy it in the United States Buy it in Canada Buy it in the United Kingdom
Buy it in Ireland Buy it in Germany Buy it in France
Buy it in Italy Buy it in the PRC
Buy it in Japan
Book sellers worldwide.

Upcoming Events

Other's References