Success always looks easy

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.

Like this post? Share it!
    About John Levy

    John Levy works with senior managers in mid-sized organizations who are responsible for development and delivery of major software or hardware/software products. He helps them gain confidence that their projects will succeed.

    Development projects can fail in many ways. You need a guide who speaks the language of business and is knowledgeable about technology. John aligns Development with the organization's strategy so it will contribute efficiently to the success of the enterprise.

    John has been consulting for over 20 years. His book on managing high-tech teams, Get Out of the Way, was published in 2010.

    For more information, email him at, or call 415 663-1818.
    And check out John's profiles on LinkedIn and Twitter!