FOXit has had a handful of projects fail over the last year and a half. Upon reflection, Anita Potgieter, chief operations officer for the company, has 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):
Incorrectly sold
There are so many over-eager sales people 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 person) told them the system can perform a whole series of functions, but these were never quoted for. Sound familiar?
The solution: a technical person needs to attend sales meetings with the sales representative in order to ensure that nothing is over-promised.
The wrong solution was sold
This one is unfortunately also due to the yes man. It is not necessarily a reason for failure, but more a case of what can go wrong before a project even materialises. The client asked for something. The sales person 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.
Bad estimation during sales cycle
Estimation should happen during the project planning phase of the project, but the first part actually happens during the sales cycle in the services industry. It is easy to sell the client a boxed solution – users can easily determine the amount of effort it will take to complete the job.
Custom development is 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.
Project commissioning gone wrong
So the project was sold either correctly and incorrectly, but no handover was done from sales to the project team during the project initiation phase.
The sales person 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, sales needs to go with the project manager 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.
Poor planning
Project managers are usually to blame here – but are they really? Should planning not be a collective effort by the project team?
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 projects that run smoothly due to the articulation of the requirements by the client and then there are 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 – as long as scope changes are properly documented and signed-off by the client, then managed and executed – everything should go well. Project teams need to be properly trained on both the project and development methodology used in the company.
Why would a normal team member need to be trained on the project management framework and the answer is that if a 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 their work cut out for them.
The team needs to know what has been defined as out of scope in the PM document.
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 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.
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, there should be no place for egos on a project.
Communication
The PM 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 PM and HODs.
Walking away from a project gone wrong
Incorrectly sold
There are so many over-eager sales people 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 person) told them the system can perform a whole series of functions, but these were never quoted for. Sound familiar?
The solution: a technical person needs to attend sales meetings with the sales representative in order to ensure that nothing is over-promised.
The wrong solution was sold
This one is unfortunately also due to the yes man. It is not necessarily a reason for failure, but more a case of what can go wrong before a project even materialises. The client asked for something. The sales person 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.
Bad estimation during sales cycle
Estimation should happen during the project planning phase of the project, but the first part actually happens during the sales cycle in the services industry. It is easy to sell the client a boxed solution – users can easily determine the amount of effort it will take to complete the job.
Custom development is 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.
Project commissioning gone wrong
So the project was sold either correctly and incorrectly, but no handover was done from sales to the project team during the project initiation phase.
The sales person 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, sales needs to go with the project manager 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.
Poor planning
Project managers are usually to blame here – but are they really? Should planning not be a collective effort by the project team?
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 projects that run smoothly due to the articulation of the requirements by the client and then there are 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 – as long as scope changes are properly documented and signed-off by the client, then managed and executed – everything should go well. Project teams need to be properly trained on both the project and development methodology used in the company.
Why would a normal team member need to be trained on the project management framework and the answer is that if a 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 their work cut out for them.
The team needs to know what has been defined as out of scope in the PM document.
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 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.
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, there should be no place for egos on a project.
Communication
The PM 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 PM and HODs.
Walking away from a project gone wrong
Calling a halt to a project that is underway is not a stress-free thing to do, but do users 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 a business.
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.
There are many more reasons why projects fail, but these are some of the key ones Potgieter has dealt with recently.
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.
There are many more reasons why projects fail, but these are some of the key ones Potgieter has dealt with recently.