Why you need a great team to deliver an IT project

“None of us is as smart as all of us.” –Ken Blanchard

We are judged on our individual contribution but most of the time we are contributing in a team, working on a shared goal such as delivering a project. To make your work life more enjoyable and more successful its worth helping recruit the best people to the team and improve others.

IT Projects are a team game, involving developers, testers, BA’s, business experts (customers), project managers and other roles. Individually we can go fast but if you to create something substantial, you need a team. Teams bring scale and momentum but are the source of problems, most projects fail because of people not technology.

Get good people on your team

Don’t accept poor performance in a team, don’t accept average people, work with the best people you can. The speed of a team is dictated by it’s slowest performing member, if you put B players on your team then it causes bottlenecks and slows the team. Average team members have low standards, they don’t take responsibility and don’t work hard.

Average team members slow down better team members and can frustrate them enough for them to leave the project or the company, life is too short to work with people who don’t care. Its frustrating to team members who work hard and have to compensate for those who aren’t.

Average members set the benchmark of satisfactory performance. Your star performers see average performance is acceptable and this leads to everyone coming down to that level. The minimum requirement for a team member is they work hard, improve and learn from their mistakes.

People who are working hard and improving get better, these people rise to the level of their talented team members. The difference between average and great is attitude.

I was a scrum master of a team and one developer was not doing a good job. The developer wasn’t working hard; they didn’t understand the business requirements and would frequently skip steps in the development process. The developer didn’t integrate with the team or take ownership of tasks.

The developers code often had bugs and would take two or three attempts to fix a bug. The…