Before we dive into the detail of why projects fail, let’s talk about project success, which can be defined on a basic level as ‘the project did what it was supposed to do.’
This means it’s extremely important to have clarity and alignment on what the ‘supposed to do’ part (i.e. the success measures) is actually made up of.
Success can mean many different things to different people. Organisations often focus on the two metrics of time and budget, and consider that if a project has been delivered on time and to budget then it’s been delivered successfully (even if quality has suffered or scope has been cut).
Other project owners may be less concerned with time and budget variance so long as the project delivers the business gains they were aiming for, and will consider the project a success principally due to its results and benefits.
The Project Jungle
Regardless of how a project’s success measures are defined, every project still needs to get safely from initiation to closure, which is rarely a smooth journey.
Matters aren’t helped by the fact most project teams won’t have any experience delivering the product in question (otherwise it would be ‘business as usual’). They may be experienced adventurers, and they may have a high-level map to their destination, but this particular trek is brand new and might be full of unknown dangers.
So, the purpose of this three-part guide is to highlight and discuss some of the (metaphoric) snakes, sharks and poisonous plants that might delay or prevent project teams from reaching their goals.
Lions and Tigers and Bears
In order to examine some of the ways a project might go wrong, let’s outline a simple example project – in the jungle.
RemoteGreen Co. (RGC) wants to set up some communication devices in an isolated part of the jungle. To accomplish this project, RGC has hired Dr Granite and his team of intrepid adventurers to follow a brief Statement of Work:
“Begin your journey at Point A, travel to points 1, 2, and 3 on your maps, set up a communication device at each of these points, and then make your way to Point B where you will set up a final device, check they’re all working and communicating with one another, and then we’ll air lift you out of there.”
What could possibly go wrong?
Project Set-Up and Success Conditions
Unclear success conditions
As mentioned in the introduction of this article, fuzzy success conditions are a recipe for disaster. At the end of a project, the project manager might believe that their project was a great success, only to find out that they haven’t delivered the client’s expectations.
In the jungle: Dr Granite has safely brought his team to Point B. They believe they’ve completed all of their high-level tasks, that they’ve done it on time and on budget, and now it’s time to go home and take a well-deserved shower.
Unfortunately, the key deliverable RGC wanted from the project was the ability to stream a live video feed from Point 2 at 3:00 in the morning, which they still can’t do, so RGC considers the project a failure.
The assumptions the project was built on haven’t been validated
A project could be started with the assumption that it will increase the company’s potential market by 20%. Unfortunately, if that assumption hasn’t been interrogated and tested to confirm its validity, the project owner could be given a finished project with no return on investment.
In the jungle: RGC begins their communication project believing it will boost interest in their company and thus increase their client opportunities by 25%. Unfortunately, they didn’t validate this assumption and are now $150,000 out of pocket (the project’s cost) with only a 2% increase in client opportunities.
If they had properly understood the likely result before beginning the project, they would have never initiated it.
All of the stories weren’t mapped out in advance
A ‘story’ in project management refers to a feature or piece of functionality, and is generally made up of several smaller tasks which, when combined, accomplish that whole piece.
While it’s usually unnecessary to have the finer details of each story written out far in advance, it is ideal to know the complete list of stories before you begin a project. Imagine a project as a house, and the stories are rooms in that house – work becomes more chaotic if your team is simultaneously building a hall and trying to add extra rooms to the blueprints.
In addition to adding potentially unexpected scope to the project, this can also waste time and resources – for instance, needing to demolish part of a finished hall to extend it in order to accommodate extra rooms.
This is subtly different to the dreaded ‘scope creep’ (where extra stories are pushed into the project backlog or sprint because someone – usually the project owner – wants extra work accomplished within the original plan).
This issue (#3) is caused specifically by a failure to break the project down into enough stories before beginning, or alternately missing a key story – like writing that the house needs ‘tiled rooms’ and then realising halfway through the project that you’d forgotten to add a bathroom. It’s a failure of identifying fundamental project pieces rather than trying to insert bonus work.
In the jungle: Although Dr Granite understands the general route that his team will be taking through the jungle, he would have liked to send a drone through the the forest before they started. This drone wouldn’t have picked up on every aspect of their upcoming journey, but it would have let him know about the raging river halfway through the trek in advance, so that he could adequately plan for it.
Now that his team have come across it by surprise, they’ll have to re-evaluate their next steps and use considerable time and resources either building something to carry them across the river or by walking far enough around that it’s no longer a barrier.
Project dependencies haven’t been mapped properly
Failing to properly map and track project dependencies can, unsurprisingly, lead to blocked project activities and significant delays. If X needs to be done before Y, but you’re due to start actioning Y and X hasn’t been completed (or even started) then you’re in trouble.
Project Managers need to be diligent about uncovering any dependencies, and where dependencies exist they need to ensure that work is performed in an appropriate order and begun at an appropriate time.
In the jungle: Dr Granite has sent one of his team members, Karan, ahead to Point 2 to start installing a communication device there. Unfortunately, when Karan arrives, she realises that her device hasn’t been fully built, and Alexa – her teammate who can finish building it – is far away across the jungle with Dr Granite.
Now Karan’s work is blocked until Alexis can arrive and finish the device, all because the team’s dependencies weren’t mapped and managed properly.
While planning, project work will always be a case of estimations – there’s no way to definitively know how long a piece of work will take until it’s done. Sometimes estimates miss the mark so much that they put the project in jeopardy.
Various estimation methods can assist with this, like soliciting estimates from multiple team members and interrogating the longest and shortest estimates for the same piece of work to make sure the team isn’t missing (or exaggerating) any complications.
Working in an Agile way can also mitigate the risk of inaccurate estimates, as even if a project runs out of time the team will still have delivered pieces of independent value (they don’t have to have completed the whole scope for their output to be valuable).
In the jungle: Based on their knowledge of the jungle, RGC has given Dr Granite and his team a timeframe of two weeks to complete their project. When he signed up for this mission, Dr Granite thought that two weeks was a tight but achievable timeframe.
Unfortunately, navigating through this particular stretch of jungle has proved much more complicated and hazardous than anticipated, and completing the project actually takes Dr Granite’s team a whole month.
There’s no fat in the schedule
A similar issue to #5, but this problem is less to do with estimations and is more about contingency.
Estimations are supposed to provide an idea of time and effort that’s as realistic as possible, but they deal with the foreseeable. The contingency, or fat, in the schedule, is there to buffer against the unforeseeable and protect the project from failure if and when things go wrong.
Building fat into the schedule means that the project can still run into a degree of trouble and recover. A schedule with no fat requires every element of the project delivery to run perfectly, which is usually unrealistic for all but the smallest and most basic of projects.
In the jungle: The rain is torrential for a few days of Dr Granite’s team’s journey, which limits both the team’s technological and cross-country progress on those dates.
Unfortunately, as the schedule was tight already, the project never recovers from this delay.
The acceptance criteria is wrong or unclear
It’s ideal to have clear acceptance criteria attached to a story before it starts to be built, but it’s essential to have this acceptance criteria finished by the time a story is tested.
Correct, unambiguous acceptance criteria lets the team know the exact specifications of what they’re supposed to create, and lets Quality Assurance know precisely what they’re testing for – it’s the success criteria for a particular element of the project rather than the project overall.
A lack of proper acceptance criteria makes it easy for the project team to deliver the wrong thing.
In the jungle: Dr Granite’s team has been equipped with some diagrams of how the communications devices should look once they’ve been built, installed and activated properly. Unfortunately, these diagrams are confusing and unhelpful, like some of the ones that come with self-assemble furniture.
Dr Granite’s team pushes through and finishes the communication devices, only to discover at the end of the project that the devices were intended to be set up differently.
Team members are expected to work on the project 100%
If a team member is assigned on a project ‘full time’ there is often the expectation that 100% of their days will be spent, without fail, on project delivery.
This is usually an unrealistic expectation – team members will have admin to perform, meetings to attend, and other miscellaneous activities they need to complete as part of their job which are not directly related to the project.
It is usually safer to estimate that 80% of a full-time resource’s hours will be spent on project work. This 20% time gap can mean the difference between project success and failure.
In the jungle: RGC is expecting Dr Granite and his team to spend 100% of their daylight hours on project work. Unfortunately, the team still has to make and pack up camp, cook and eat meals, pause for bathroom breaks and perform other non-project activities to keep them going.
This difference in time utilisation prevents the team from making their expected progress.
The project is inflexible
Some projects are set up so that they cannot be changed once they’ve begun, even if the project owner’s priorities change during that time. If, half-way through delivery, the original project no longer exactly suits the project owner’s needs, they should be able to work with the delivery team to adapt the project to better hit their revised goal.
This doesn’t mean throwing out the original Statement of Work – rather, equivalent pieces of work should be able to be substituted for one another, or a piece that was planned for the last third of the project should be able to be shifted earlier in the plan (provided there are no incomplete dependencies).
In the jungle: After Dr Granite’s team has installed the first communication device at Point 1, RGC realises that circumstances have changed; they no longer need a device at Point 2, and now want the team to proceed straight to Point 3 followed by a newly-identified Point 4.
Because this does not match the original Statement of Work, Dr Granite and his team refuse, and RGC ends up with a finished product that no longer meets their needs.
The project owner doesn’t check in regularly on product progress
This issue isn’t about checking in on the team itself – it’s about checking on the product they’ve been creating.
If a project owner never checks on the evolution of their product, the team will work independently but may give the finished product to an unsatisfied product owner: what’s been built may not be functionally right, or it may not be up to the project owner’s quality expectations.
Wherever possible, it is best practice for project owners to review and approve (or reject) any completed stories on a regular basis.
In the jungle: As a RGC representative can’t join Dr Granite’s team in the forest and communications are too fragile for them to send video, the next best thing would be to send regular pictures and text reports of of the team’s status and the progress of the devices.
Dr Granite wants confirmation that RGC is happy with their work as it’s completed, but RGC says it’s too busy for these regular reviews. Finally, when Dr Granite’s team finishes their work at Point B, RGC checks everything and says that it doesn’t meet their standards.
The team has difficulty getting answers from the project owner
When a project delivery team has client questions or needs a decision from the project owner to proceed, they require assurance that the project owner will provide answers in a reasonable timeframe. If the project owner is very difficult to reach or takes a long time to reply, this can significantly delay the project until those answers are received.
In the jungle: Dr Granite and his team arrive at Point 1, but the site where they were supposed to install the communications device is now a bed of quicksand surrounded by wasp nests.
Dr Granite tries to reach RGC to see what the next best installation site would be, but RGC takes days to provide an answer, blocking much project progress and thus stretching the expected project time-frame.
There’s a single person dependency
If there’s only one person on the team who can perform certain work, that creates two concerns for the success of the project.
The first is that this person creates a bottleneck for the specific variety of work that no-one else can do: if a task of X type takes longer than anticipated, no other tasks of X type can be worked on simultaneously, and if this person falls ill for a week, then no X type work will progress. The second concern is that if this person resigns or otherwise leaves the team, they create a critical skills gap (and/or information gap) for the project.
In the jungle: Alexa is the only team member who can build the communication devices, but she gets eaten by a bear. Now the devices cannot be built and the project fails.
Team members don’t understand their roles and responsibilities
A team member who doesn’t understand the expectations others have for them is unlikely to meet those expectations. Often, someone will be allocated a project role without being fully informed of what that role entails.
A ‘developer’ role on one project might come with several tasks that they didn’t need to complete on a previous project, like making sure their physical story cards (a common way of tracking story progress) are up-to-date every day. If project success hinges on team members doing something that they don’t realise they need to do (or they were told a month ago and have now forgotten), danger is imminent.
In the jungle: Karan hasn’t worked with Dr Granite on this kind of project before. Dr Granite expects her to be checking the statuses of all the activated communications devices every morning before they leave camp, but he never explicitly told her this and Karan was unaware that she needed to do so.
Now they’re at Point B with no time to go back and fix the malfunctioning devices.
The team is run into the ground
Although the project delivery team can expect some reasonable stress and overtime in order to get their projects over the line, some projects drive their teams to exhaustion by trying to meet unreasonable goals.
The health of these exhausted teams suffers and the quality of their work drops alongside it. Exhausted project teams make many more mistakes, work slower, call in sick more frequently, and resign more often than peers with manageable hours and workloads.
The team might pull some all-nighters in order to get the project finished and launched, but then 200 bugs are logged the following day because the product was completed under such poor conditions.
In the jungle: RGC keeps pushing Dr Granite and his team to work faster. They rush through the work as fast as they can, spraining ankles, growing blisters and losing sleep.
They struggle to the end of the project and meet their helicopter on time, but then RGC discovers that the communication devices only work between the hours of 7:00pm and 1:00am.
Technical people are asked to be team managers
For a variety of reasons, technical staff are sometimes asked to lead project delivery teams, or to lead smaller teams within a large project. This is not inherently a problem, but it quickly becomes one if these people are skilled in their technical roles but not at management roles.
Often, they may not have the ability or the inclination to act as a manager, and thus the project’s success becomes much more difficult to achieve.
In the jungle: Dr Granite has brought a larger team into the jungle with the aim of completing the work faster, and puts Alexa in charge of the smaller ‘Build’ team within the larger project group.
Although Alexa is excellent at building communications devices, she has limited management experience and a lack of people skills. Her team is soon confused, working inefficiently, and struggling with morale. Dr Granite has difficulty getting an accurate picture of the Build team’s progress or the issues within that team, although it’s clear that some exist.
Technically the project team has more build resources, but they’re not working much faster than if he had just taken Alexa, and the overall project is harder to manage and get over the line.
Team members don’t have the necessary skills / expecting wizardry
These are two different flavours of ‘that person can’t do what you’re asking’. Appointing a team member to a role that they simply don’t have the skills to perform is obviously problematic, yet still happens more often than one would expect. It’s perfectly reasonable to ask someone to upskill a little or acquire a bit more knowledge to prepare for a role, but thrusting a team member into a position that they are obviously unqualified for is unfair to that team member and counter-productive to project success.
The second flavour of this is what I call ‘expecting wizardry,’ which is when something will fail regardless of the skill of the person asked to work on it. If a printer prints one report every minute and you ask for 15 reports printed in five minutes, whoever is assigned to that task will always fail because the success conditions are impossible.
In the jungle: When Karan finds herself alone at an installation site with a half-built communication device, Dr Granite asks her to finish building it even though she has never been trained in that specialised skill.
Karan builds some of it as best she can, but she knows it’s bad work and she can’t get the device to look or work the way it should. Karan sits down in the jungle and cries.
Failing to get stakeholder buy-in on a decision
A project’s stakeholders include any person or group who could be affected by the project or its outcomes. Although it might not be necessary or even desirable to consult all of these stakeholders on every project, failing to discuss a critical decision with the group sponsoring the project or the product’s end users is usually asking for trouble.
If the project delivery team makes a hard-to-change decision that hasn’t been agreed upon by their client, or one that results in a product the end user group immediately dislikes, the project may be considered a failure by the project owner before it’s even had the opportunity to launch.
In the jungle: Upon finding Point 1’s installation site was a quicksand bog surrounded by bees nests, Dr Granite tried to reach RGC to see what they considered the next best installation site. When RGC didn’t respond within 24 hours, Dr Granite decided to proceed with installing the communications device one kilometre to the west. Later, they discovered that the chosen location was considered worthless by RGC, and that the project was therefore viewed as a failure.
Low team morale
Although low team morale can have many possible causes, some common ones include: poor team dynamics that aren’t acknowledged or fixed by the project manager; management ignoring the obvious underperformance of a team member; management ignoring the team’s suggestions for improvement or the issues that they’ve raised; expecting the team to work until exhaustion or when they’re sick; good/hard work going unappreciated; and absent management or micromanagement.
Thankfully, while it may not be fast or easy, all of these issues can be fixed or at least significantly improved by good management practices: the project manager or their superiors should have the power to influence them. Fixing a team’s low morale is definitely worthwhile: similar to teams who have been worked to exhaustion, teams with low morale will work slower, create more risks and issues for the project, call in sick more often, and have a higher rate of staff turnover.
In the jungle: Dr Granite knows his team are having problems. They always seem to be arguing about their work, and because trust has broken down they’re not communicating properly, which makes the work take longer and means the overall quality has suffered. Everyone seems to be blaming each other.
The mood is low and Dr Granite feels like he’s dragging them through the jungle towards the project’s end. He doesn’t know how to fix his team’s problems so he’s been hoping they’ll resolve by themselves, but he’s increasingly worried that the project will fail on several different measures, including scope, time and quality.
Most projects will have limits on either their time, budget, or both, so it’s important to prioritise the project work accordingly. If the project delivery team does run out of time or money, the project owner should still be able to walk away with the best possible value. This way, the project might still be considered a success even if the entire scope is not completed.
Prioritisation issues generally fall into one of two categories: the work was prioritised in the wrong order, or the work was prioritised with the wrong method. If project stories have been completed in the wrong order, when time runs out a project owner could be left with a working car radio but no car engine – if the order had been switched, the project owner could have received a working car. It wouldn’t have been equipped with the bonus of the radio, but it would have been a working product that met the project’s basic needs.
A less-than-ideal prioritisation method could be as simple as marking 50 stories as ‘high’ priority and another 50 as ‘medium.’ Sure, the team will complete the high-priority stories before they start on the medium, but if they aren’t further prioritised then the team might pick up the least-important high-priority item first. The backlog should still be prioritised on a story-by-story or task-by-task basis so that everyone is in alignment about what to pick up next.
In the jungle: One of the tasks given to Dr Granite and his team was to clear a path through the jungle so that others could more easily follow in their footsteps. Unfortunately, RGC neglected to mention that this was much less important that the rest of their mission, so the team spent a lot of time clearing a path and didn’t finish setting up the communication devices on time.
The team isn’t dedicated to the project
Team members are often expected to perform their project roles whilst also working on other projects or performing their ‘day job’. While this isn’t a problem if the split is reasonable and allows them enough time to do everything well, it becomes a serious issue if their workload becomes too heavy, their split focus leads to decreased productivity, or they are regularly pulled away from the project to ‘fight fires’ for their employer.
In the jungle: When they’re not actively adventuring, Dr Granite and his team sometimes pay their bills by acting as consultants for adventuring supply stores. Throughout their project in the jungle, these supply stores keep SMSing the team and demanding emergency consulting sessions, causing major delays for the project.
Project scope creep
As mentioned earlier, project scope creep occurs when anyone tries to add extra work into a project’s established backlog without taking an equivalent-sized piece of work out again. The project was planned around a certain amount of work, and the larger that amount becomes without also adding extra time and resources, the more likely that the scope will not be able to be accomplished and the project will fail.
In the jungle: RGC contacts Dr Granite and his team once the project is underway, informing the team that RGC now wants an extra communication device set up at new installation site, Point 4. The project team is expected to complete this additional work within the same timeframe as the original project. Dr Granite and his team try valiantly to meet this goal, but they just can’t get all five communication devices active in time.
The amount of coordination provided does not match the project
Different levels of project coordination are required for projects of different sizes and complexity. A project can fall into dangerous territory if it is over-coordinated: the team could be pulled into too many meetings (infringing on their hands-on work time), feel micromanaged and shackled because their work is too bureaucratic and gated, or there is simply too much administration to perform.
Equally, if the project is under-coordinated this will usually lead to team alignment problems, not only with the speed of the team’s progression and issue resolution, but also with the quality of the work produced.
In the jungle: Dr Granite has a lot of his own work to complete and considerable confidence in his team, so he decides to cut back on his usual coordination activities. Unfortunately, this means that his team loses track of what everyone is working on, of the progress of each piece of work, and of what bits of information need to be shared between which team members.
Progress slows and defects slip through the cracks. Dr Granite later tries to rectify this situation, but the situation is too far gone and the project fails.
Confusion over terms
Unless the terms they’re working with are specifically defined, it’s easy for a team to run into trouble because two people interpret a word in different ways. A classic example of this is the term ‘done.’ Is a piece of work done when it’s finished development, when it’s been tested, or when it’s been released?
As long as the team agrees on a definition, it doesn’t really matter what that definition is. Trouble starts when one person asks if something is ‘done,’ meaning the testing, and another person says ‘yes’ even though testing has not begun (as they are thinking of the completed development). Across a project these misunderstandings can cause a lot of confusion and delay, lead to misrepresentations of the project’s progress and status, and result in work which is missed out of testing or the release pipeline.
In the jungle: Dr Granite asks Karan if the communication device at Point 1 is ‘done.’ Thinking he means the installation (which she has recently completed), Karan says yes. Dr Granite thinks that this ‘yes’ means that the device has also been activated, so they leave the installation site with unfinished work.
Project risks are overcompensated for
While risk mitigation is usually a good thing, occasionally it can lead to time and budgeting problems which throw a project off course. If the cost of the risk happening would be worth $10,000 to a company, but ensuring it won’t be a problem will cost $20,000, then it would usually be inadvisable to pay the $20,000 – better to simply risk the $10,000.
In this instance, it costs less for the risk to happen than to eliminate it. Sometimes projects can spend a great deal of their budgets on mitigating risks which are not worth this costly prevention.
In the jungle: Dr Granite becomes fixated on mosquitoes – there are quite a few in the jungle, and although he’s not concerned about them as disease vectors, he is concerned about how their bites irritate and distract the team while they’re trying to work. He directs his team to stop and spend three days of their journey weaving mosquito nets, losing much more time on this activity than they would have lost scratching mosquito bites.
Issues and risks are recorded and then forgotten about
Proper project risk and issue management includes recording these risks and issues in some sort of log and reviewing them regularly. Too often, a risk or issue is recorded and then forgotten about, meaning that it isn’t actioned or monitored appropriately and was thus pointlessly recorded in the first place. These risks and issues, especially unmanaged, can seriously threaten a project’s success.
In the jungle: 10 days ago, Alexa told Dr Granite that she identified some bear dung and is concerned about bears in the area. Dr Granite noted this in his log and then promptly forgot about it. This morning Alexa was eaten by a bear.
Mixed client messages
If the project team is working for an organisation rather than an individual (which is almost always the case), it’s easy for them to receive mixed messages from multiple people at that organisation. As a minor example, person A might want a screen to be blue while another has requested for it to be red. This confusion can lead to re-work and delays for the project team, and can lead to an unsatisfied project owner if the team has also been taking instructions from one of their colleagues.
For this reason, it is important to establish with the project owner as to who in their organisation has authority to direct the project, and to maintain open lines of communication about all direction that has been given to the team.
In the jungle: The project owner agreed on the project specifications with Dr Granite before the project began, but later the project owner’s colleague contacted Dr Granite and asked him to install the communications devices facing south instead of north. Dr Granite installed them facing south because those were the latest instructions from RGC, but the project owner was later furious because Dr Granite had changed things without consulting her.
Not including change management or training activities throughout the project
The products created for many organisations will then need to be used by those organisations after project delivery has finished and the product has gone live. If the staff within those organisations need to change their processes because of the new product, it’s important to conduct change management and training activities while the project is still in delivery. Once the product has launched to the public, it will be too late.
Unfortunately, many organisations still forget about change management and/or training and then try to squeeze it in at the last minute. If the users of a product don’t know how to navigate it properly then the project will not deliver its return on investment (and will likely cause a lot of issues and confusion for the user organisation in the meantime).
In the jungle: RGC wants a certain group of its staff to use the outputs of the communication devices once those devices been successfully activated. Unfortunately, they realise too late that they haven’t actually trained these staff to use the device outputs. The project finishes but their staff don’t understand how to do what RGC wants from them.
Only the ‘happy path’ was designed for
In the context of project management, the ‘happy path’ is the default or usual path that most users will take through the product. While it often makes sense to focus on the happy path (if, for example, 80% of your users will go through this process), the issue with designing solely for this happy path is that the product is not built to accommodate exceptions or errors. Users with needs that do not align with the majority are not catered for, and this can generate a multitude of poor user experiences, bad publicity, and occasionally legal issues.
While a product designed only for the ‘happy path’ does not necessarily result in project failure, it can often mean a great deal of additional time and effort expended following project ‘completion’ in order to address the needs of users who were not considered in the original design.
In the jungle: As part of their latest project, RGC have decided to sell online subscription packages to their customers who want the benefit of using the latest in jungle communication. Their project goal is 1000 subscriptions purchased within the month following the devices’ activation.
Knowing that most of their customers are in the USA, RGC decides not to spend any extra time making their online sign-up form internationally friendly. Hundreds of international customers start to fill in the subscription form but run into major issues that mean they are unable to complete it. RGC do not meet their aim of 1000 subscriptions; the project is considered a failure.
Individual components are built without a view for integration
Components of a product are rarely intended to function in isolation. Just like in the human body, certain pieces are attached to one another and other pieces may need to ‘talk’ to each other, such as a leg receiving a signal from the brain that directs it to stretch forward. Creating different parts of a product without a view to how these parts will later fit together is an easy way to guarantee a project failure.
In the jungle: Dr Granite has hired a new team to complete their project for RGC. Each new team member is multi-skilled and can build, install, activate and test the communication devices on their own. Dr Granite sends each of these team members to each of the different installation points and asks them to complete the set-up of a communication device.
The team does so successfully, but each of the devices is set up a slightly different way and cannot integrate with one another. The project fails.
Ignoring non-functional requirements
It’s easy to concentrate on the functional requirements of a project (e.g. X happens when I press the Y button) and forget about non-functional concerns, but these are often critical for project success. A few examples of non-functional requirements include product availability, disaster recovery, maintainability, response time, and safety or security.
The Y button might still make X happen, but if it’s only accessible on Mondays, can’t be maintained, takes 4 hours to process your request, and might blow up at any time, you probably wouldn’t consider it a successful product.
In the jungle: Dr Granite and his team have successfully delivered the functional requirements provided to them by RGC. Unfortunately, RGC forgot to discuss non-functional requirements, so information from the communication devices takes an hour to reach their offices, rendering the project essentially useless.
Ignoring legal/compliance requirements
Projects always operate within some sort of legal or compliance framework. Ignoring these legal or compliance requirements means inviting fines and bad publicity (ranging from ‘minor’ to ‘company destroying’), but could also easily mean that the relevant authorities prevent the project from launching in the first place. Even if the project does launch, it could be suspended or shut down soon after, resulting in clear project failure.
In the jungle: The government in charge of the jungle area where Dr Granite and his team are installing the communication devices require any sort of recording equipment (which is part of devices’ functionality) to be clearly fenced off and to display a sign notifying the public of this recording within 2 metres of the equipment.
Dr Granite and his team were not aware of these requirements and have not delivered them. Thus, soon after project completion the government suspends the activity of all of the communication devices.
Not enough (quality) quality assurance
Because quality assurance (also known as QA, or testing) is one of the last things to happen to a story or a product before it can be considered complete, project delivery teams may rush through the quality assurance process or overlook it entirely in their hurry for completion. Skipping or truncating the quality assurance process, or testing without a dedicated quality assurance resource (e.g. relying only on developers to test their code) greatly increases the chance of a project going live with significant or critical issues.
In the worst-case scenario, a product is released to the public only to find that many or all of its users cannot access it properly, and/or that it clearly does not deliver what it supposed to do.
In the jungle: Anxious about their tight timelines, Dr Granite asks his team member Dylan to cut his usual testing time in half. Dylan does his best to test as much as possible in the time allocated, but he certainly cannot test everything. When Dr Granite and his team reach Point B, they discover that some of the communication devices are not working properly after all, and the project fails.
The plan for project success stopped at ‘go-live’ / trying to ‘set and forget’ a product
A project itself might finish at its launch to the public, but it would be a mistake for the project owner’s plan for success to reach no further than the launch date. After its launch, a product that has been weeks, months or even years in the making will still require activities such as publicity, customer service, additional staff training, version updates and maintenance.
Ignoring a product once the associated project has finished can mean the desired success outcomes or returns on investment are not achieved, and thus even though the project launched well it could ultimately fail its goals.
In the jungle: Dr Granite and his team successfully deliver the project and the project owner from RGC rejoices. In fact, the project owner is so relieved that they take 3 weeks’ holiday and then come back to work to commence ‘business as usual’. The product that was so carefully brought to life is left alone without any extra publicity, maintenance or effort in general, and the project benefits are not realised for RGC after all.
Leaving The Jungle
There’s certainly a lot to keep in mind when planning and managing a new project. This article isn’t intended to be a comprehensive list of why every project has historically failed, but nevertheless, aiming to avoid these issues in your next project will vastly increase that project’s chance of success.
And if you’re looking for an experienced team to guide your digital project to safe and glorious completion, please come and say hello to us at Transpire – we’d love to play our part in making your next project a resounding success.