Why SharePoint Projects Fail

31st October 2016

According to a 2009 IDC report, around 25% of IT projects fail in delivering their goals, while up to 50% require major refactoring in order to meet the requirements that were set.  This can have a major impact on a business.  Typically, major projects – whether related to SharePoint or Cloud Deployment – represent a large investment, and can be critical to future success.

Finding the cause of failure “post mortem” can be straightforward.  When reviewing a project, it is normally clear where things started to go wrong.  Unfortunately,  at that point, it is too late – the investment is lost and it is necessary to apply more resource to achieving the original project goals.

Analysis of failed projects usually points to a standard root cause.  Project Management.  In fact, according to IBM, management failures account for 54% of failed projects, whereas technical challenges are responsible for just 3% of failures.  The remainder fall into a variety of categories including a lack of information in the original brief, a muddled scope, or changes to the roadmap mid project.

It is important to note that failure can be defined in a number of ways too.  For some organisations, a failure in a project might be that it is delayed by more than a pre-defined number of days; in others, the definition of failure might be more narrow – that functions or features were entirely missed out.

At igroup, a large proportion of our work is related to the successful delivery of development projects such as SharePoint Intranets or cloud deployments.  These are often part of a wider business transformation, and as such we are required to deliver to the original brief.  Our team focus on achieving our client’s goals through structured project management and regular contact with stakeholders to ensure that we meet functional briefs and thereby achieve our goals.

Below are some of the ways in which we focus on creating the right outcome.

It’s essential to have a measurable, structured way of setting and monitoring the goals of a project.

We have an internal philosophy of project management that runs from our initial consultancy work.  Before any code is written or any software is configured, we create a full roadmap of what will be delivered.  We prioritise the features that are required to ensure that we have a project that is clearly defined in terms of scope, and also in terms of what can be delivered within the allowed budget.

We use prioritsation based on MoSCoW:

  • What the application Must have
  • What the applications Should have
  • What the application Could have
  • What the application Won’t have.

The core goal of the project – the Must have – is central to the roadmap.  This means that the most important features are prioritised, so that even if the full scope cannot met within the available resource budget, the outcome will still meet the project goals.
No-one likes a nasty surprise.

In most large development projects, igroup work as an extension of an internal IT team.  We provide a means of filling a skills gap to achieve a specific goal.

In order to achieve this effectively, it is essential that there is total transparency between our team and our client.  Regular updates of the project and releases of code when available ensure that the work is understood by both parties, and also allow for approval to take place during the build.  That way, any issues can be identified and resolved before they are committed to a live environment.
In any major project with multiple stakeholders, there can be conflict about what the expectations are, and who is responsible for decision making.

While there is no place for tyranny in a successful relationship, an informed, and decisive voice of management is essential in order to avoid project creep that might undermine achieving the preferred outcome.

Having a strong project lead who is ultimately responsible for implementing any changes to the brief helps the project to run smoothly.
This might seem like a contradiction to having strong leadership, however the two are closely related.

If a project appears to be going off track, it is important to be able to bring it back into line.  Issues discovered midway through a long term development project might require a re-think.  While a clear brief and prioritised roadmap should help to avoid misunderstandings, they can still happen, and if a feature doesn’t match expectations when tested, it is essential to have the flexibilty to adapt to the changing goal and refocus in order to achieve success.
Failure helps teach us what to avoid in order to become successful.

As noted above, it can be easy to spot where things went wrong after the fact, however, it is harder when you are close to the project.  As part of our standard approach to development, igroup use close internal auditing to ensure that goals are being met, and that the work being created meets our clients goals and expectations.

By assessing work in progress and at key milestones within the overall project, we minimise miscommunication and achieve a high level of success for our clients.

If you’re having problems with a project, we can help.  Talk to a member of our team on 0207 099 0632 to find out more about how we can work with you to get a SharePoint development project back on track and help you avoid failure.

 

Call now on 0207 099 0632 to speak to a member of our team

Call Us Now