Mistake 2: Talking Without Communicating
Marco, a network administrator, was working with a team trying to design a new database application for the company. The application was supposed to provide internal and external access, with both desktop and web interfaces.
The team did many things correctly. Marco's role was to provide insights about the server. Several users were included on the team to provide usage insightsinformation about what they needed from the application in order to do their jobs. In fact, just about everyone was represented somewhere.
Unfortunately, representation didn't mean recognition. The various parties would talk, but they really didn't communicate their needs to the development group. As a result, the application started to look like some hideous example of "development by committee." The application not only didn't work, but users couldn't interact with it properly, it lacked many features, and everyone was generally dissatisfied. Eventually, the company ended up hiring an outside consulting firm to get the project going.
The moral of this story is that a team can't just talk. Someone must listen, sum up the ideas that are presented, consider any potential pitfalls, and then organize a single train of thought for the development team to follow. Generally, the team leader performs this task, but if the team leader isn't up to it, someone on the team must be responsible. Communication between various group members is essential.