People routinely ask me why I focus on recovery instead of prevention. Its true, projects would be far better off avoiding me and my services. That said, the sun will rise tomorrow and projects will falter and fail. Knowing that I will always have customers I will share a few things that any project can do to ensure success. With a sincere apology to Dave Letterman, I present for your amusement Stephen Cohen's top 10 things for avoiding project failure;
10: It's not engineering... yet. No matter know much we want to believe in it, software is rarely an engineering effort. Engineering requires repeatable process and if there is one universal truth it is that software, completely functional running software, need not be a reproducible success. This is strongly supported by the corollary that people build things not "resources". Individuals that are unique artists find a way, their own way based on skill, personal history, and current context, to build a customer acceptable solution. Exchanging one person for another, removing one resource for another will change the likelihood, approach, and quality of a solution in ways that are, on a good day, difficult to predict.
9: Follow your intuition. If you have been on a handful of projects, or better yet, if you have been on more than one successful project, your instincts are better than any number of metrics. Individually metrics try to convert chaos into cold hard fact. It does the same way vitamins and supplements reduce a meal into a handful of pills. Sounds good, seems simpler, but clearly trades beauty for simplicity. You know right from wrong, when the team is clicking, and when the books don't look right. Trust that and leave the math for analysis and verification.
8: Live in the moment. Sure it's a bit Zen for such a logic based activity as software but being in the bubble, completely focused, highly productive, and unaffected by the natural turmoil around you reduces problems and increases quality. It's not enough for you to be focused but the team must be allowed and enabled to be focused.
7: Just say no. There are a few really good arguments for making this number 1, but this is my list and here it is at number 7. Sometimes you just need to say no to some projects, some features, and some team members. I would go one step further and say that it's even ok to go back and say no to something after you have said yes. If you can't avoid becoming responsible for the wrong things you can at least act responsibly and, after the appropriate review and analysis, flee to safer, better, successful activities.
6: Make progress, everyday. It amazes me when I find a project that admits they are in trouble and decide to address that trouble by convening "tiger teams", refining schedules, and seeking consensus. I'm not completely against these things, but a sure fire way to ensure a project slips or fails is to stop making progress. Even progress on the wrong things or in the wrong direction, unless allowed to run unchecked, eventually net progress by eliminating a bad idea or allowing the team to train through trying.
5: Don't improve measures, Improve the product. Even the most bureaucratic customers don't want to pay for measures. Sure measures are an exceptionally valuable tool for managing the project but they are not the deliverable. Measure will drive behavior and, I believe their are several notable sources to support this, the first behavioral change will be a focus on meeting the measures. If the level of effort to achieve a measure or the result of a measure don't get you closer to a high quality deliverable or match your intuition, seriously reconsider the cost and value of the measure. In the end, changes in the product are reflected in your measures not the other way around.
4: Quality is not schedule driven. The triple constraint, the iron triangle, the three legged stool, these are all references to Schedule, Scope, and Resources. Getting a solution out on time and within budget requires close monitoring of these three things. Unfortunately none of these handy metaphors pay the proper homage to Quality. Cutting testing to meet schedule is a asking the Samurai to unsheathe his sword. It might not be today or tomorrow, but sooner or later blood will be drawn.
3: Be honest with yourself and everyone else. Software projects, particularly large complex software systems, are exceptionally painful things to breathe life into. Unexpected things happen to the product and the team. Be watchful. See what's really happening and try to get behind the illusions cast by everyone, including you, to obscure if not hide the truth. I rarely find a malicious liar (but it has happened). Instead I find any number of people deluding themselves with all kinds of evidence that success is inevitable when the truth runs contrary to that ideal.
2: Be inclusive, but Lead. Yes that's Lead with a capital L. Of the many failed or failing programs I have seen and worked over the years I have never seen a problem who's root cause didn't fall squarely at the feet of leadership. Failing to provide clear guidance, using the opinions of subordinates to replace actually knowing, and abdicating decisions to consensus are all critical failures of leadership. If you have the privilege to Lead you must Lead. Provide guidance and drive the team to work within it. Accept expectations when required but know your goals, advertise them, and stay the course. Listen to subordinates, honor they ideas, but apply you knowledge and choose when you are inevitably confronted with multiple correct choices.
1: Talk to each other. The hands down number 1 action that can prevent a project from becoming a failure is the free and open exchange of ideas. While technology has provided us a variety to ways to interact when face-to-face meetings are not possible it hasn't removed the need to talk to each other. The internal turmoil caused by failures in communication are so destructive that it requires super human, statistically unlikely levels of progress to offset the costs.
There you have it. The secrets reveled.