by Anita Potgieter, COO at FOXit.
We’ve had a handful of projects fail 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 & Control):
My # 1 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.
Solution: In my opinion a technical person needs to attend sales meetings with the sales representative in order to ensure that nothing is over-promised.
# 2: 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 is not suitable. What happens here? Developers and consultants need to slap a poorly designed system together.
# 3: Bad Estimation during the Sales Cycle
Now I know you’d think 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 – you can easily determine the 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.
#4: Project Commissioning Gone Wrong
So the project was sold either correctly and 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.
#5: 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?
#6: 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. You get those projects that run smoothly due to the articulation of the requirements by the client and then you can sometimes get the out of control ones.
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.
You might ask why a normal team member needs to be trained on the Project Management Framework and the answer is this: If your 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 it 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.
# 7: Project Staff Turnover
If a project team member resigns knowledge is removed from the project. This will put the project at risk 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 your staff.
Solution: Have 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.
#8: 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) that 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.
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 HOD’s.
Walking Away from a Project Gone Bad
Calling a halt to a project that is underway is not a stress-free thing to do, but do you really want to continue working on a project that will not be bringing 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 internal project sponsor (when working in the consulting industry) and review the costs-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.
FOXit (Pty) LTD. is a South African established International provider of solutions, service and support focused on Project and Portfolio Management (PPM) in business.