Not all projects completely succeed. For a variety of factors some do not meet some or all of the original goals laid out for them.
There is a tendency to label these projects as failures, to totally write them off and be more cautious when initiating similar projects in the future.
In the web space, which is changing fast, many projects are firsts of their kind. This can make it harder for organisations to allocate appropriate resourcing, time or constraints, or to set appropriate success criteria. There may also be unanticipated side effects which can distract from the project's focus.
This can lead to failures in otherwise reasonable projects, failures which could be prevented through a better understanding of project needs.
When web projects are considered failures, organisations can become more cautious and less willing to attempt similar projects or place additional constraints on how projects are run. These can reduce the likelihood of subsequent successes and lead to dininishing returns and greater reluctance.
So how do we, as web professionals, help organisations engineer for greater success in web projects?
Firstly it's important to speak up during the initial planning stages. To provide honest views of what resourcing and time is required to achieve the project's goals. There's no point in beginning a project with inadequate resourcing - it doesn't serve the government, the agency or yourself.
Where time and resourcing isn't flexible, it is important to negotiate and clarify the criteria for success. Make sure all the stakeholders have a common understanding of what success looks like and how probable it is given the constraints.
It is also possible in some organisations to define certain non-critical projects as experimental, with an underlying goal of increasing knowledge within the organisation. In this case you can define success as identifying approaches that do not work. While this may sound like a cop-out, defining success as failure, remember how Thomas Edison invented the light bulb - he 'failed' many times, allowing him to learn what did not work in order to focus on an approach that would.
It is also important to record all the unintended impacts of a web project. Sometimes a project can be successful in areas important to the organisation but outside its defined goals. An example of this is the post-it note, which resulted from experiments by a 3M employee, Spencer Silver, to develop a strong new adhesive. The adhesive was a failure - it was super-weak - however Silver kept the formula. Four years later another 3M employee, Arthur Fry, discovered that the adhesive could be added to the back of paper notes and stuck to things and removed without causing damage. After another six years convincing 3M of the commercial value (which he eventually did by providing prototype post-it notes to the executive assistants of senior managers) it finally was released in the market as post-it notes.
Most important of all, it's important to help organisations understand that a partial success isn't necessarily a total failure.
In most projects, even those that are regarded as catastrophic failures, there are components that succeeded. These successes can sometimes be just as important as the failures for educating future projects - there's even a saying for it, "don't throw the baby out with the bathwater".
Particularly in large web project, or where web forms part of a larger project, it is important to differentiate between the parts that failed and those that succeeded - to acknowledge the successes even where the project is rated as an overall failure.
While this approach holds for all aspects of projects it is particularly important in the web space. As the internet is reasonably new for most organisations, some people can be more sensitive towards perceived failure in the area and more willing to use it as an excuse to kill or restrict future projects.
This is simply human nature - we fear the unknown and attempt to limit its impact on us through controls or avoidance. This is mirrored in project management strategies which define and minimise the potential impact of what we don't know through risk mitigation techniques and project controls.
So if you find yourself in the midst of a project hurtling towards failure, make sure that you spend time identifying what is going right as well as what is going wrong.
If the web component (or any other component) is meeting its goals - or at least providing key insights and tools that will enable future projects - make sure these are highlighted to the organisation and that these learnings are shared outside the project team.
Even where you cannot save the project, you can at least add to corporate knowledge and prevent the organisation from mistakenly throwing out that baby with the dirty water.
Read full post...
View summary...
Posts
