Top Ten Team Building Tips

(With a Difference?)

1. Give the team a name, nothing cheesy, be descriptive e.g. the name of the project + the word team (not "Project 76543 Team"). This gives the team a sense of being - they can now say "I am on the XX Team" instead of "I am working on that project we sold to er, you know about last April something to do with er, you know......"

(Hint 1b - If your project does not have a name then think of something relevant e.g. a project to change a robot arm in an assembly system "Hokikoki", packaging line for a new contraceptive "Bang on Time", a system for a company in Stockholm "Turnip" (it is swede-ish)). (If you are struggling send me a paragraph describing your project and I will send you some suggestions).

2. Set out a clear mission or purpose, and find out if everyone is "signed up" for it - if not then find out why and do something about it. Watch out for people who are signed up for something that is nearly the same as well as those that are aiming somewhere entirely different - the latter are often easier to deal with. E.g. a team engineer could be more interested in making the machine as accurate/fast/powerful as possible than in making something that meets the customers expectations.

3. Create a "plain English" schedule that complements the heinously fiendish Gantt chart / PERT chart that you have used to get the project done. Most people just glaze over at any Gantt chart with more than about 20 tasks (which let's face it is most Gantt charts). A month-by-month headline level view in spreadsheet or table can be understood by pretty much anyone, even the Project Manager (and the Project Director / CEO / Customer etc....). A real benefit of relating the schedule to real time months is people can see where the milestones of the project are in relation to their real-life milestones - like Christmas, Easter, Summer Holidays etc.

4. Celebrate the Milestones in an appropriate way, assuming your milestones are not too far apart (monthly-ish is nice c.f. point 3). If your milestones are 18 months apart you really ought to think about bringing some more in somehow, or if you can't do that consider monthly get-togethers. By "appropriate" I mean something that is relevant to what has been achieved and also reflects that value of the achievement to the project / company. Of course it is also reasonable for it to be scaled to how well the milestone has been reached. Some examples:

• Give everyone a USB stick to mark the start of system integration (it will help some of the team in passing files about etc. s.t. system security of course).
• Hold a celebration breakfast / pizza party to thank everyone for getting in early / staying late to get the job done.
• Give everyone the afternoon off (on the project code not holiday) as a thank you for working through the weekend etc.
• Plant some trees in the local country park to mark the end of the project and offset the carbon footprint of the project a little. Go to the pub afterwards (s.t. satisfactory driving arrangements !)

5. Be as honest as you can and ask your team to do the same for you.   Don't worry if you can't tell the team why something is like it is, be firm and stick to your lines, if you can't divulge some information stick to "I can't tell you that" don't produce a long excuse as it just gives rise to rumours etc. If you must add something to close the discussion then consider agreeing to let people know as soon as you can – but be sure you mean it.

6. Be prepared to admit when you are wrong.  Project managers have to take risks and make decisions based on incomplete information, it is their job. Sometimes they get it wrong, so be brave and admit it, then ask the team to fix it with you - it takes guts but it works. As with the honesty thing, don't give a long winded explanation, just say "I am sorry I got this wrong". Adding "because I had a headache and my car got a puncture and the director told me not to tell you but....."

7. Remember it is nearly always a longer game than just the one project.  Chances are you will be asked to do another project and chances are some of the team will be the same. How good the chances are depends on a number of factors, how good the project outcome is, what size the next project is, how many projects does you organization run. Keep the "long game" in mind when dealing with your team – don't burn bridges with team members if you fall out when the project gets tough, be reasonable (as reasonable as possible – not soft though!) about allowing team members to attend courses and help on other projects, be wary of holding back information especially if it will be obvious you held back (e.g. that the installation is in a nasty part of the world).

8. Ask for and pass on feedback from key stakeholders (Hint 8b if you don't know who your stakeholders are you had better find out soon!) Be honest, specific and to the point about this, if the customer is worried say why, if the CEO is pleased then say what he is pleased about.

9. Deal with poor performance, privately:  If team members are not performing then the team may well know, but this is no reason to humiliate people in front of the team as it creates the wrong behaviours in others – for example they may cover their errors in order to prevent receiving the same treatment. Don't ignore poor performance though as it really is like the rotten apple turning the rest rotten, and it may give the wrong impression about your feelings or abilities. Confront poor performance fairly and squarely, state your case and what needs to be done to put things right, be supportive but firm, be clear that you will not hold a grudge. If you are not comfortable with this then speak to your HR department or your line manager, probably also the individuals line manager – but be wary of handing the problem over as it will dilute the message and can create a barrier between you and the team member.

10. Remember it is all your fault!  The Project manager must always remember that they have overall responsibility, so be wary of finger pointing (a great mentor of mine used to drive me nuts by saying look how many fingers on your hand are pointing back at you when you hold your index finger out – the ratio of blame is probably the same). This is not to say you can't get help, but it certainly means that when it all goes pear-shaped you can't turn around and say "it was the team's fault".

Do you love these points or loathe them ? – Let us know what works for you and what makes you see red – not all project management is the same and not all project managers like the same methods, there are certainly plenty of different ideas and ways of doing things. If it works for you it is probably right for you, so let me know it may be right for others too!

May the force of the JFDI be with you ! (Just Flippin Do It!)

Camtion is headed up by Dr Alan Crooks. He has a PhD in robotics and M.Eng Mechanical Engineering from Bristol University where he worked for 5 years on EC funded automation projects. Alan then spent 10 years as an engineer, consultant, project manager and service manager at The Automation Partnership (Cambridge) Ltd. producing successful solutions for Cell Culture and Compound Storage. In 2005 Alan joined Merck Sharp and Dohme as Head of Instrumentation for UK R&D sites. Alan started Camtion in 2006.