Why do projects FAIL?

MOST THINGS ARE JUST TO COMPLICATED!!

As I look back at my own career I have tried to be honest about how I got a reputation for getting things done quickly, on budget and accurately. This reputation served me well and it allowed me to work on some of the biggest and most expensive projects. It also allowed me to gain access to most of the newest projects.

First I come from a small midwest town and worked on farm. Up before dawn and working hours before breakfast. Working all day and going to bed by nine o'clock. The work itself was consistent and fell into a daily pattern, You knew what you were going to do morning, noon and evening. That's not to say that there were no surprises but those surprises were within the realm of what you were doing. Milking cows was something to be done multiple times during the day but sometimes cows had to be prodded into the barn, sometimes they didn't, sometimes cows were not to happy with the milking process, sometimes they were but everyone knew that regardless of these surprises cows needed to be milked. It was a great learning environment for me. It was not complicated you knew what needed to be done and you did it.

When I got into computers, in those early days, I was lucky enough to really understand how one "talks" to a computer and how you "ell it" what to do. There was the process of getting information into the computer and getting it out. Obviously there is a quite significant process in the middle. Once the information has entered the computer you need to do something to create information on the way out. When I started with computers it was actually before many of the "computer languages" were invented. In those "old days" you needed to tell a computer, in binary code, when to "read" the input, and you needed to keep asking the computer if it bad finished reading the input, if not "stay in the loop", if complete tell the computer what to do next, and next, and next, etc. Also don't forget to keep telling the computer to continue reading the next input.

IBM came up with a method of creating flow charts broken down into 3 major segments. Input, Process, and Output, this chart was organized into boxes which represented a specific processes and triangles or diamond shaped boxes which represented decision points.

I don't care what you are trying to do, or what computer language you are using this is really the same old process. Yes there are many more avenues for input into the computer, and depending on your computer language of choice, just how you get the required processes completed is determined by the language itself. Do you use processes already coded and string them together or do you code into a specific language. There are so many options for how to get something done that sometimes these gets in the way of getting it done. But the process of what you need to actually do does not really require a solution to these complex decisions. Its like getting from A to Z. Everybody knows how to get from A to Z, to do that you don't need to know all of those complex It decisions about how to do it. If you want to build a payroll systems or a inventory system or and medical billing or anything else what you need to do is sit down with a piece of paper and obviously people who know how to get from A to Z and document this in simple terms that anyone can understand. At the same time you can get you IT group (of one or many) to start figuring out what are the technical ingredients required, and there are a number of different reasons why people pick one option over another. In some cases it is a question of how much you want to depend on another company or how fast you can get to market. The bottom line however is that most projects fail because there is no clear outline of how to get from A to Z. Millions of dollars and lots time is wasted trying to figure out the technical aspects of the the project while truly not understanding how to get from A to Z. While I taught people how to program a computer in a least 6 different languages when it came to projects I made sure I knew how to get from A to Z. Knowing this it allowed me to have a better idea of how many people were required, what skills were necessary, how much time to build it and what else was required, such as documentation or training for those people what were going to use the finished product.

I'm not trying to say that everything is simple for it is not, however, if you can't make it simple you will have a very difficult time getting any project done on time and within budget. I did not have a perfect score on every projects, however in over 40 years I can count (and you can check) that I had far more successes than misses because I was able to make it simple and understandable to everyone.

I'm not sure how many people will read this, but whether you are the CEO or the CFO or the COO or the VP assigned to oversea a project you need to make sure that people assigned to your most important projects know how to get from A to Z, if they don't you have a risky project that will most likely be late, costly and at worse simply fail.