Five Ways For Projects to Fail

I just read a great article from Inc.com on why software development projects fail, or as the front page of their web site says “What can a walrus teach you about business?” The article gives five common mistakes that will doom any development project. It’s a relatively short article that definitely holds true for eLearning development. For those of you who haven’t realized it yet, eLearning development is software development. We may not all program in C++ or Java, but our development has a lot in common with traditional software development. If you are a project manager you owe it to your team to read the article.

I think my favorite mistake is number 3 in the article, negotiating a deadline. This is where the walrus teaches us a lesson. No, I’m not going to steal the author’s thunder, you’ll have to read the article to find out about the walrus. I’ll just say, I am the walrus. (OK, that really isn’t funny, but how could I resist?) The reason I like this mistake is because it is absolutely true. I hate giving solid dates for development projects because they are never accurate. Good estimates are possible, but only after detailed requirements and specifications have been drawn up and an experienced developer spends a lot of time mapping out the development effort. That process in and of itself will take time. Even then, stuff always happens that derails development.

In a past job I was asked why a development project would take months. I said because it takes months. Even if your deadline is next week, people can only work so fast. The only way to speed up the process is to hire more people. If your deadline is a few weeks and you only have one developer, I can tell you now the deadline will slip. My theory is that unless you have done development (a lot of development), you cannot estimate development time. Even basing your estimates on past projects probably won’t get you in the ballpark. Maybe the same zip code as the ballpark, or the parking lot, but not in the ballpark.

My favorite training related scenario goes something like this. A new course has been thought up by someone who is not a training developer, let’s say it’s a product manager. That PM says we need a training course so customers can learn how to use the new iWidget. The course needs to be a two-day course. It needs to be done next month because a customer will be testing the iWidget and we need to train them as part of the test. Said PM then asks me if I can get the course done. I say “of course”. The next time I’m asked I’ll tell the PM about the walrus.