Failure to launch

There have been a handful of projects that have failed over the last year-and-a-half. Upon reflection on these projects, I have come up with a number of potential reasons that could be behind the failure - from the sales cycle through to project close-out (excluding monitoring and control).

My number one reason: Incorrectly sold
There are so many over-eager sales guys out there. They promise a potential client the world to get the deal in. What is wrong with this? Months down the line - the service provider is still stuck with the same project because the 'yes man'/sales guy told them the system can perform a whole series of functions, but these were never quoted for.

Sound familiar?

Solution: In my opinion, a technical person needs to attend sales meetings with the sales representative in order to ensure nothing is over-promised.

Number two: The wrong solution was sold
This one is unfortunately also due to the 'yes man' (or sales executive). It is not necessarily my second reason for failure, but more a case of what can go wrong before a project even materialises. The client asked for X. The sales man manipulated the client's high-level requirements to a solution that was not suitable. What happens here? Developers and consultants need to slap a poorly designed system together.

Number three: Bad estimation during the sales cycle
Now I know that estimation should happen during the project planning phase of the project, but the first part happens during the sales cycle in the services industry. It is easy to sell the client a boxed solution - it can be easily determined what amount of effort it will take to complete the job.

Custom development - now there's a beast of a different nature. How long is a piece of string? The developers that need to assist the sales representative are normally too busy on projects that were incorrectly sold and cannot focus properly on providing estimates that needs to go into the sales proposal. So, even before it becomes a project, it is doomed for failure.

Number four: Project commissioning gone wrong
So the project was sold either correctly or incorrectly, but no handover was done from the sales guy to the project team during the project initiation phase.

Solution: The sales guy needs to schedule a sales handover meeting with the project team to bring them up to speed on what was sold. After the meeting is conducted, the sales guy needs to go with the project manager/team to the client for the kick-off meeting. During this kick-off meeting, the sales solution needs to be discussed with the client, and high-level deliverables (if not added to the sales proposal) needs to be defined.

Number five: Poor planning
I know project managers are usually to blame here - but are they really? Should planning not be a collective effort by the project team?

Number six: Scope creep
There are two possible reasons here: either the scope of the project was not clearly established during initiation and planning, or the project manager failed to manage scope change requests effectively. There are those projects that run smoothly due to the articulation of the requirements by the client, and then there are sometimes the 'out of control' ones.

Custom development - now there's a beast of a different nature.

Scope changes, even though sometimes painful, are not necessarily a bad thing for the services industry, as it means more money coming in to the company.

Solution: now this is just logical (to me at least) - as long as scope changes are properly documented and signed off by the client, then managed and executed, everything should go well. In my opinion (and I've mentioned it in previous blogs), project teams need to be properly trained on both the project and development methodology used in the company.

The question might arise as to why a normal team member needs to be trained on the project management framework, and the answer is this: if the team does not know what the scope of the project is (especially young, fresh, out-of-varsity guys), and they do not know how scope creep will affect the project, the PM has got his work cut out for him. More importantly - the team needs to know what has been defined as out of scope in the project management plan/scope document.

Number seven: Project staff turnover
If a project team member resigns, knowledge is removed from the project. This will put the project atrisk as the new team member may need to revisit/investigate requirements, designs as well as past decisions made. Even if a team member doesn't leave the company, but is allocated to a new project, this poses risk. Another risk here is placing an employee for too long at a client site, as the client might end up poaching staff.

Solution: Have a planned rotation of employees in place for contract placements. Ensure that project decisions are well documented and readily available. Ensure all client communications are stored on the project site/document repository.

Number eight: Team bullies
This isn't about someone physically or emotionally bullying someone else. This has more to do with self-images and titles getting in the way of work happening. The employee attitude of "I'm too important to be doing menial tasks" could have a huge impact on project deliverables, not to mention the influence of this individual over junior team members.

Nirvana: highly evolved individuals/project teams should have no problem reporting to someone (the PM) who is not on their salary bracket/level in the company. If the team members are committed to the end goal and know that a project is only a temporary endeavour, it is a good starting point. Most importantly, in my opinion, there should be no place for egos on a project.

Number nine: Communication
I'm not talking here about communication to the client. I'm also not talking about the communications plan. The project manager can only communicate progress to the client if there is adequate communication within the project team. If the team does not play well together or prefer to work in silos, problems could easily emerge.

Solution: Ideally, a profile matrix should be drawn up of all company employees, and personalities that complement each other should be matched up on project teams. It might sound a bit ridiculous and far-fetched, but it will alleviate a lot of stress for the project manager and HODs.

Calling a halt to a project that is under way is not a stress-free thing to do, but do you really want to continue working on a project that will not bring in any money? It is extremely important to maintain neutral and stay clear from the disillusionment related to sunken project costs that may overcome you.

Before the project can be cancelled, it is important to meet with the internal project sponsor (when working in the consulting industry) and review the cost-benefit analysis of the project, and additional opportunity costs that will be lost should the project continue.

I know there are many more reasons why projects fail, but these are some of the key ones I've had to deal with recently.