Back to Papers and Articles

Why projects are not as successful as they can be

Copyright Paragon Corporation   ( January 05, 2005)

Why are projects not as successful as they can be?

There are several reasons why projects are not as successful as they can be. The key factors we have come across in our consulting practice are listed below.

  • Lack of User Involvement
  • Too much user involvement
  • Too much forward planning
  • Use of obsolete technology
  • Misuse of technology
  • Hiring the wrong consultants
In the following sections we go into greater detail on these topics

Lack of User Involvement

When users are not involved in the development process or not considered, you end up with an application that management may think is good but is not usable. It has complex features that nobody using the application knows what to do with and don't use.

It is important to remember that the reason for applications is to make the work of employees a little easier. An application should strive to fit the users of it like a well designed glove and custom tailored for their needs.

Case in Point: We were rewriting an application for one customer and noticed that their was an intricate part of the application that didn't seem to be used at all. Rather than redo this piece, we asked one of the lead users what it was for and how come it seemed no one is using it.

He replied "Yes no one ever told us what it was for and we never asked for it, so we don't use it. Just scrap it."

With all fairness though, rewriting an application does give you a lot of hindsight. You can easily tell from the current data what people are using and what functions people are not using. You also have a working model that users can easily relate to and say "I don't like this because it's awkward to navigate".

Too much user involvement

While it is a good thing to involve users in the development process, there is a point at which this can become counter-productive.

For example some users are just distracting and get caught up in minutia that distort the project scope. These users should be avoided for input or at least should not be taken at face-value and be asked for their opinions later on. You can detect some of these people easily because when you have a meeting -- they monopolize the whole meeting. When you think back at what they have said, then it could be summed up in two sentences.

Also some users can not see the repercussions of their decisions. They are very graphically oriented. They know what they want or don't want when it is put in front of their face. If you leave too many decisions up to users like these, you end up with some very expensive development cycle iterations.

Too much forward planning

Many people will argue with this point, but from experience, we have discovered that too much planning early on is more detrimental than too little. There are of course exceptions, but for small to midsize projects this tends to be the case.

Too much planning early on is like plotting a course for a road that you have no map for. Too many assumptions, and you end up driving yourself into a ditch.

I remember reading an article - can't remember where about why Japanese car makers were so successful and the gist of the article was because they made their most irreversible decisions at the end. This also holds true with software development, in that you want to make your most irreversible decisions when you've got the most information available to you -- at the end of the game. The two main reasons for this are -- 1) People are visual and need to see something before they can see the next step. 2) The more complex a plan you have, the harder it is to execute because there are more variables involved at the beginning. By planning in steps you reduce the number of variables you have to worry about at each step.

If this were a perfect world, we wouldn’t have to make any decisions until we had all the information to do so, but of course then the project would never get started without some amount of decision (e.g. deciding to do the project). So the most important decision to make is to decide which decisions need to be made first and which ones can be put in the back burner.

This point while easy to make is actually an art and science in and of itself and is beyond the scope of this section. Perhaps in a later section we will cover this important point and go over the decisions that are important to make early on as far as software development is concerned.

Use of Obsolete Technology

This doesn't need too much explanation. Just try to avoid it at all costs. It is always much harder to maintain obsolete technology than newer technology. So while it might be a savings in the short-run, it is guaranteed to kill you in the long run.

Misuse of Technology

It is often tempting to use a new technology when you first hear about it just because its cool. For example there are lots of misuses of XML technology in this world. For example many people have been tempted to use XML format to pass around data even in cases where alternative technologies were better supported and just made more sense. If you are going to be passing a flat file structure of data back and forth - it may not make sense to wrap this in an XML layer for a couple of reasons - the other side doesn't have the middleware to deal with it, it is much more bulky, and it takes longer to produce and parse.

Similarly it doesn't make too much sense to connect all your apps together with Web Services when they use the same core libraries. It's like building a pretty small pipe bridge when you've already got a big sturdy bridge.

This is changing though as new development tools are coming on the market to automate this process and network speed is improving.

Hiring the wrong consultants

It's hard to define what makes a consultant wrong for you so we'll try to outline some key factors here
  • Don't hire a big consulting firm for a small project or if you are a small company. They will either neglect you or try to solve your simple drill problem with a machine gun.
  • Don't hire a consultant that belittles you. They will just scare you into thinking you are stupid and they are Gods that should not be questioned.
  • Hire a consultant that you can like as a person. E.g. Don't hire a consultant that you wouldn't want to have coffee with or just doesn't seem to understand what you are asking for.

Back to Home