With all the news about IT projects that go bad, you would think that we’d hear more news about projects that go well. Then we could just copy down the “best practices” that led to the success and – voilà – our projects would come out perfectly every time.
But life is not so simple. While we can enumerate key problems that led to failure by analyzing projects, it is much harder to point to one factor and say “this is what made this project successful.” Success depends not only on avoiding the pitfalls, but also on bringing together all of the essential project elements. Sometimes those elements are not so easy to identify.
Example 1: I once struggled for 7 months with a project team that couldn’t seem to get all the right pieces together. In fact, what was needed was to remove two members of the team. One of them was in a key contributor position, but was just not disciplined enough to produce his part of the code (this was a firmware team). The other was simply not contributing to the team because he didn’t understand his role and was not capable of fulfilling it. While I had recommended the removal of these two on my 3rd day on the project, I had not insisted, and the result was a long slog.
What happens when you remove non-contributors from the team? First of all, someone else on the team steps up to do what needs to be done. Second of all, the whole team becomes more productive (and happy) because they are no longer saddled with the unproductive members.
Example 2: A client company launched a transition to Agile development methods in the development of a major sales-support package. They hired an experienced team of software people and an Agile coach. The program went well. I was asked to assess the team and the project during its first year. My assessment: this team will do well no matter what methodology they use – because they are experienced people who know how to work in a team.
There was also an invisible success factor, invisible to the remote business people who chartered my assessment. Within the ranks of IT management was an individual Director-level manager who secretly supported the Agile transition. I say “secretly,” because the CIO turned out to be opposed to any special treatment of software developers (compared with, say, treatment of call-center operators), let alone “Agile” teams. This manager quietly encouraged the Agile team and provided me with insight into all of the IT department politics that could affect the team’s performance.
If you manage to identify and engage the key success factors in real projects, you’ll be regarded as a genius. But don’t let it go to your head, because a lot of it is luck. Luck that is aided by keeping your eyes and your mind open.
If you’re managing a major project, it’s best to call upon resources (not just people, but information or equipment or software) that help compensate for any shortfall. So it’s a good idea to continually build up your network of contacts, your access to information, and your knowledge of available equipment and software. Then, when you run into a roadblock, you can call on your network to help find what you need. And of course, it doesn’t hurt to have a secret ally in the management ranks.
About John Levy