Teamwork

"And we'll have fun, fun, fun" - The Beach Boys

How do you get the most from a group of people?

Answer: TEAMWORK

But, the real question is ........

" how do you build a team?"

" how do you bring together a group of people and make them into a team?"

This is not what we do!

Teamwork is not something we do well. Most of the time it is not even something we do at all. Our entire culture is based on not building teams rather than building them. Even when we play team games we are constantly trying to pick out individuals rather than understanding that it may be the 'chemistry' of the team that makes them successful rather than the specific skills of individuals within the group.

The Hardest Thing

Most people can use new techniques, and can tackle major tasks .... once they have got started. The hardest part is always getting started, the fist interview, the first data flow diagram, the first objects to be defined, the first screen to be designed, the first report, the first code to be written, and so on. People seem to need helping over these psychological hurdles, recognise this from the outset and either help people get over these problems personally, or have a team work on them, or hire someone from outside to help. Nothing is more daunting than a blank piece of paper!

Will This Project Be Successful?

I am sometimes asked what it is that makes developments successful, why do some work and some not, and more specifically, 'will this one work?' The answer that people are looking for is a particular language, or methodology, or technique, or technology. Of course, the answer has nothing to do with any of these things; it can be summed up in one of those clichés I have criticised earlier;

'Nothing breeds success like success!'

The biggest predictor to a successful project is that the project teams have previously been successful. Success gives confidence; it means that the team will have gone through a number of 'pain barriers' that could stop others. They will be willing to try new things; object orientation or client server, they will have some idea what to expect, they will know that some things will go wrong, that the specification will change, that the users will be difficult, that IT management will be unreasonable, etc., etc., etc.

'Nothing breeds failure like failure!'

......and what would be a predictor to failure? Well, if an IT department or a development team had a number of attempts at developing systems, but for whatever reasons had not completed any of them, then their chances of success will be lower. They will lack the necessary confidence and experience

It's Never Too Late!

It's never too late to what?

It is never, never, NEVER too late to scrap what you have done and start again. In fact, you will almost always have to redo some parts of any major project. It is also possible to predict what you will scrap, it will be one of the very early parts. Does knowing that you will have to go back and do some of the early work again help in any way? Yes, it does? There are a number of reasons why this knowledge can be useful;

• If you are expecting it to happen you may not compound the error by trying to 'make do', or ignore it, or blame the user, programmer, language, technology, etc. The quicker you deal with the problem once it becomes apparent, the better.

• Knowing that this is normal should stop the team from feeling guilty or losing confidence. You should treat the reworking of module(s) as part of the job.