Success is an amazingly difficult notion to objectively pin down in many projects. While we need to be flexible, I’ve noted that there is a fine line between flexibility and chaos. Often it is but a single voice that makes all the difference.

Projects are a series of negotiations. As long as changes to the original budget, timeline, and requirements have been negotiated along the way and the customer is satisfied with the outcome, then who really cares if the project completed with a different estimates from the original ones? That project should be considered successful. Let’s say “No” to groupthink and stop quoting the Chaos Report by Samad Aidane.

I loved digging through the articles and discussions on the accuracy of the “Chaos Report” on IT project success, up until I read the above article advocating “stop quoting the Chaos Report.” The problem is that when I’ve presented project performance data at many struggling organizations I got this same kind of feedback: “Don’t ever talk about that data again!” and “It is successful, if we say it is successful!”

In these organizations we persevered and we went on to produce on time projects and products with good quality, often for the first time in the recent memory of the organization. Customers consistently complemented us on “finally” giving good estimates and then following through with on time delivery. In most cases, before our successes, it was considered “not realistically possible” to ever regularly deliver IT and software projects on time and budget.

One of the simple things I do, which anyone can do, is try and match what we hear in such reports and ensuing discussions to our actual professional experiences. Now, I was once chastised at the Software Engineering Institute for excitedly talking about some project successes we had had, with the comment “Yes Bruce, but your experience may not be the definitive one!” This is now humorous in hindsight as we got our organization to successfully improve, against SEI models, where the SEI had been unsuccessful for years in a consulting capacity to do the same. This reinforced to me that a professional experience of “one career” is useful.

Think about it. We, for example, have often been a Nielsen family where our one family statistically represented thousands of other TV watching families. How can my experience and what I do be both immediately discarded as unrepresentative in one context and then we can represent thousands of people’s experience in the other? If I had been randomly selected out of the universe of all software managers then my experience would have been “significant” but because I just volunteered my experience for consideration, it was inconsequential! This made no sense to me.

What to do? As this site is called “Project Management Tools That Work” that is what I focus on. The choice of the name was because so much of what I’ve used successfully seemed at odds with accepted wisdom. It just worked, consistently, and I decided to share it. I’ve enough education and experience to understand why most of the things work, but again I decided not to try and justify everything logically, statistically, etc., but just propose the notion if things are not working for you, you may want to try something like this.

As to the Chaos Report and the notion of how many projects are successful and are not successful, I add my following experience of “one professional career.”

1. Most software and IT projects (well over 50%) don’t meet their goals as to schedule, cost and functionality. This does not mean they don’t produce successful results or products. In fact, I believe the reason why we have such decrepit project performance is because projects do often result in useful results, even if they are not as successful as initial optimism sought. Therefore bad management does not consistently result in bad results or bad products (so, is it bad management?). One senior software manager said to me “I understand software. We go along for a while and the software doesn’t work, and then one day it works.” Another senior software engineer once commented along the lines “We can’t really ever deliver a huge project like this on time. That’s just happy talk we do with every project.” Both projects delivered on time, for the first time in the memory of the respective organizations.

2. Most projects, at least in IT and software, have always had a built-in incremental nature to them. In other words, even as we tried to execute waterfall monolithic projects, they were actually incremental over the course of all projects against that functionality and so the “project” per se was a somewhat arbitrary definition. Even as a project “failed miserably” as long as something practical or something that could be built upon was produced, the incremental project continued. With time the projects refined the functionality into a reasonably polished process or product. This explains to me why the lights stay on, phone calls work and we get our paychecks every other Friday. None of these things worked well when they first started out, however.

Our own experience and judgement is always relevant and important when planning and managing a project. Beware of forces that attempt to suppress information (“don’t talk about that!”). My experience is that most project chaos could have been avoided by a brutally honest and courageous consideration of all opinions and information. Not talking about a contrary view is rarely a project management tools that works.

Have the projects you’ve worked on in your career been successful or chaotic or both?