Cover Page »
Contents
Editorial
Editorial
ALT news
Chief Executive’s Report
In my opinion
Why some 'successful' projects 'fail'
Smartphone studying: the technology universities try to ignore?
Project updates
Glow: the world’s first national intranet and online community for education
Case studies
The role of embodiment in student success in virtual worlds
Going Mobile: our approach
The National College’s online network
Book reviews
Mahara 1.2 ePortfolios: Beginner's Guide
Events
Events
A week in the life of
A week in the life of...
What to do when you get Google Apps for your school
Epigeum 'University and College Teaching'
Sections
Subscribe/Remove
Past Issues
Issue 21 31 Oct 10
Issue 20 11 Aug 10
Issue 19 12 May 10
Issue 18 15 Jan 10
Issue 17 19 Oct 09
Older issues »
Why some 'successful' projects 'fail'
by Tom Franklin


Introduction

One of the interesting phenomena that I have observed over the years is the number of projects which report that they have been successful, but where if you look for traces even a short time after the end of the project few (if any) of the claimed results can be found in use. This is especially true of projects with a significant amount of development.

Typically, a project team will bid for some money, undertake the work and deliver whatever it is that they have promised, but the results simply sit on a server somewhere not being used; this despite the promise of commitment from users and management when the bid was being written. The project may have had the full backing of some of the senior management within the institution, who may have found the funding or supported the bid and sat on the project board or steering group, but still the results sit on the server not being used (or not beyond the initial group that it was developed with).

In short, these are projects that have delivered what they promised to, as a project, but still fail to go on to become used, even within the environment for which they were created.

I am going to suggest that in many cases this could have been predicted right from the start, so I want to look at some of the indicators that suggest a project will make a successful transition from development to production, and ways in which they can be addressed to increase the chances that a successful project becomes a successful system or service after the end of the project funding.

Not core to the 'business'

Sometimes projects appear to have the support of management, yet they are not really seen as core to business. This may be because the manager needs to be seen to be doing something whether or not they think it is important, or because they know they need to do something, but don't really know what it is that they need to do. A case in point was a recent e-mail to the ALT-members’ list:

"If you were to be allocated £250K with the aim of reducing the number of students required to attend classes whilst retaining or increasing student numbers and maintaining quality (as measured by retention and progression figures) then what would you spend the money on?"

Now, while this is clearly related to core business –student retention and cutting costs– it is unlikely that the project would be able to demonstrate that it is able to fulfil the brief in the time that project exists. Assuming that some sensible project could be undertaken in that time, and assuming that there was a reduction in costs (how would you demonstrate that?) and that retention was improved, how would you be able to demonstrate that the project had played a significant part?

In addition, by the time the project was completed the chances are that the manager’s focus would be elsewhere and the project would die unless the staff who were using the results chose to keep it going. 

Note also, there appears to be funding for the initial project but no funding to continue to support the work after the end of that funding.  The brief that has been provided is also vague and dependent on being able to demonstrate strong benefits. 

If I was asked this question by my manager I would start by asking what will happen once the project has completed, explaining that during the life of the project itself I would be unlikely to be able to demonstrate the benefits as they are likely to occur once the results were up and running and in use. I would also point out that money to support the continued use needs to be allocated alongside the project development allocation: otherwise it will not be available when it is needed, or at the very least there would be a hiatus.  Indeed, I would at least be tempted to suggest that without the allocation of funding to continue to support the work after the end of the project there would be a very high probability that the money would be wasted.

To address this it is necessary to ensure that the work is not only core to the institution (in terms of furthering the strategy) but is also aligned with the thinking of the managers who will have to continue to support it once it has been implemented.

Fit to strategy

Almost all project bids claim to align to some part of the institutional strategy. Strategies are often broad so there are usually many things that one can ‘hang’ the bid on: improving efficiency, enhancing the student experience etc. However, although the project may be able to demonstrate that it is aligned with the strategy, this does not mean that it is necessarily central to that strategy. Therefore, the ability to demonstrate alignment with strategy is not sufficient to demonstrate that a project has the support that will carry it through after the end of the project funding.  Strategies require implementation plans (or similar) in order to be put into effect, and so for a project to succeed it must be included as part of the implementation plan, as well as aligned to the strategy. This relates closely to the lack of funding discussed below.

Change management issues not addressed

There is a risk that the development and roll out of a project are separated: i.e., the development team work hard at developing some tool, customising an application (such as a virtual learning environment), but there are is no parallel work to support the users in changing their working practices to make use of the new tool. 

Change management requires considerably more than providing training for users. It requires leadership and teamwork, it requires working with the existing culture and it requires adapting processes. It is not easy and there are no shortcuts that work. It also requires different skills and usually different people from those involved in development. A good place to start to understand the issues involved is the JISCInfokit on change management.

To put it another way, there is little point in undertaking a project unless it is intended to effect some sort of change (there are rare exceptions). If the real purpose of a project is to enable or support some change in practice, then the focus needs to be on the change, not on the development. However, too often the focus is on the development and it is assumed that the changes will happen by default.

If the project is to succeed in delivering both the product and the changes that are required to make the results of the project useful then ensure that the change is being managed and supported right from the start of the project including the planning and approval processes.  Change management is not something that can be done at the end or grafted on. It can form part of the development process, as getting "buy in" from users is an important part of change management, and contributing to the changes, for instance through agile development methods can form part of this.

If change management is not addressed then the take up and use of any development will at best be ad hoc and it is likely that the results of the project will sink without trace. Where projects are successful resources are available to support change management as well as the development, and there is support for change processes from management. 

No funding for roll out or support

Is funding for the roll out and support of the initiative promised?  I have seen many projects where the funding was 'definitely available' or 'promised' for the roll out of the project once the development was complete. Yet in many cases the money failed to materialise at the end of the project. This is especially true for externally funded projects, but not uncommon with internally funded projects that are not seen as core to the business.

One indicator of whether the promised funding is likely to be available is whether, or not, it has been written into the budgets. Money that is written into budgets takes a conscious decision to remove again. Conversely, money that has not yet been allocated will have to be "found" at a later date. This too takes a conscious decision, and is therefore a barrier to effective delivery. When the project comes to an end there is then likely to be a pause whilst money is sought from elsewhere in the budget to be allocated to this, or more likely it will not be seen as a priority and the funding will never become available.

Confusion between 'user needs' and 'user likes'

I have seen a number of so-called user needs analysis which are no such thing. They take the form of asking the users if they would like to see certain features implemented in the development. In a slightly better form this may mean asking the user to rank the features that they would like to see.

I believe that there are huge problems with this approach. Firstly, it is unlikely that people will say that they do not want a feature, so that I have seen conclusions from this type of work that all the proposed features address user needs.  It fails to distinguish between features that would be "nice to have" and features which are essential to the processes.

Secondly, and more importantly, it does not address the underlying issues. It is looking at the features, not the underlying processes. Presumably the point of the project is to improve the overall process. Therefore it is necessary to look at the process, and ways in which it could be improved, and from there select or design the appropriate affordances, and hence the features that need to be developed. It is quite possible that users of the current systems will not think of these as they often think about how to improve the current process rather than reconceptualising it.

Again, this may stem from not considering change management issues from the outset.  User requirements exist within the context of the process, and a change in the process will change (at least some of) the requirements. It is therefore important to understand the current and new processes and design affordances that support new processes. If the design of the new processes is undertaken with the users then this can be an important part of the change management and help to gain "buy in" from the users by improving both the processes and the developments that will support them.

Conclusion

This article has discussed some of the reasons why projects that successfully deliver what they promised, and had the support of senior management still failed to deliver useful results that were taken up and implemented and continue to be used after the end of the project funding.

While there is no easy way to guarantee that the results of a project will be taken up and used there are things that can be done to at least increase the likelihood that they will be used.

I call this planning backwards. By this I mean you need to ask the question if the project (development and roll out) are successful what needs to have happened? What processes will change? Who owns those processes? Who works on those processes? What will the new processes look like? What are the drivers and barriers? Who do I need to involve? What resources do I need? Who should the project champions be? Note that little of this concerns the development itself. It is concerned with getting appropriate levels of backing and support for the project and putting in place the support, personnel development, training and change management needed to deliver the change required.

This poses significant problems as one often has to put project proposals together quickly in response to requests (whether internal requests or calls for bids / invitation to tenders / project calls that are externally funded), whilst building the support that is needed to make real change  happen takes time. This poses a dilemma - on the one hand some money is available which will enable you to undertake a development that you would like to, and possibly help to keep some of your staff employed as well. On the other hand there is a very high chance that the project will be a dead end with no tangible benefits to your organisation.

I hope that this will help you to plan projects with a greater probability of long term success.

Tom Franklin
Franklin Consulting
tom@franklin-consulting.co.uk

Share
Created with Newsweaver