Aug 2013
There are lots of different reasons why projects fail. Some situations are more likely than others, but what you need to is identify some of the possible reasons why your project may end up failing.
There has been the case in some projects where the manager didn’t assess all the members of his team correctly, and they ended up not having the correct skills for the role that they have been assigned. This affects the project greatly.
Sometimes the manager will have to overspend by hiring another member or train the current member whilst on the project. In extreme cases, stakeholders may decide to delay the project until the correct team has been assembled. In other cases, there has been the situation where a team member has shown he doesn’t have sufficient skills way into the late stages of the project.
In small projects one member of the team can cover two roles efficiently, but projects that are needed for large organizations require at least one team member for one role or more. If the manager doesn’t hire enough people before the project begins, in some sense it has already started to fail. In order not to burden other people with unassigned tasks the project manager does well to assemble his team way in advance, this includes testing their skills and abilities. A project may fail because of the pressure being put onto multi-role team members.
If team members do not come to briefings or read their emails then they may not be informed of the current stage of the project. Again this can be blamed on the project manager because it is his job to oversee the project. Although he cannot literally make sure everybody reads there emails there are some things he can do to take control of the situation:
• Contact stakeholders
• Ring direct
• Hold meetings
The success and failure of a project is varied throughout the duration of the project. You cannot always say that a project has fully failed until the project is coming to an end. Lazy team members can affect the project a lot even if the project manager is doing his best to fulfil his role.
If the stakeholders are not gathered together to discuss the user’s needs then when the project is near completion, the stakeholder may have noticed that the user’s needs have not been met accurately. If there are problems with the project then the stakeholders will want to know so they understand what’s happening and when they can expect completion.
Sometimes the clients’ user requirements are vague and to avoid embarrassment the team decide to just work on what they have. Instead the user requirements should be cleared up as soon as possible because when the project is close to finishing the client may decide that what you have produced is not what he needs. There are lots of clients that won’t even know their user requirements themselves and this is the part where you have to discuss them with them what it is that they really want. You can ask them:
• What is the software for?
• Will it be run on a network?
• How many people will be using it?
• What tasks are being performed manually?
• Will any accounting functionalities will be necessary?
(The questions above are based on user requirements for bespoke software for a client)
Announcing initiative before considering the full delivery implications is not wise as these expectations may not be met and lead to disappointment. This is why the project manager ensures the correct steps are taken to make a realistic prototype or release a beta if it is software. The steps are:
• Making the project feasible
• Analysing
• Designing (at this stage prototypes should be made)
In I.T. projects, changes in policies and laws could have a dramatic effect. This may make initial requirements for a project obsolete. Legislations may not pass through parliament until just before the implementation so there is the possibility that last change requirements may be made, though highly unlikely it has happened before.