There are of course instances where it's the vendors' fault. Some common problems that come to mind are:
- Poor programming practices and architecture design
- Inability to understand the requirements
- Inability of the vendors to translate the requirements to application functions and conveying this to the customer.
However, there are also possibilities where the customers' actions caused the project to fail. Some of the common problems are:
- Not knowing what they want, and thinking that IT can do anything
- Changing their minds frequently that results in frequent changes to the system design
- No support from higher management
Building an application is no different from building any physical device. Just imagine that you're renovating your house and you requested your contractor to build a customised study table cum bed. You agree on the blueprint and materials(translated: requirements, functional and design specifications) but halfway through, you find that it is not what you expect. You request the contractor to change the specifications and for some reason, the cycle continues. Do you think such a table will turn out nicely designed, useful and sturdy? I think not. Building an application is similar.
On the vendors' side, you'll need people who are able to gather and translate requirements to an application function and on the customers' side, you'll need people who are able to understand the IT side of things and explain that systems cannot do anything and everything. Business operations and processes always drive the IT, not the other way around.
Therefore, I personally think that in a project failure, both sides need to take responsibility. Remember the 3 constraints of any project: Scope, Cost and Schedule = Quality. The 3 points, Scope, Cost and Schedule forms a triangle. Any changes to any sides of the triangle will cause the quality to change.
This will never change for any project, regardless of how important or how insignificant your project is.
No comments:
Post a Comment