HEPCIT 29 th August 2003 Successes and Failures

The purpose of innovations Increase revenue Avoid costs Improve educational outcomes Prove and/or test capabilities

A short history of a failed project Perspectives on failure Did everything fail? Early warning signs Responses to failure

Defining Success and Failure Success –Satisfying agreed stakeholder objectives in accordance with agreed priorities Failure –Perceived or actual failure to achieve objectives –Achieving objectives not agreed or valued by key stakeholders

Key Determinants Personnel Objectives Priorities Project Process Communication

The invitation to apply Selecting units or courses – how not to do it

The role of the sponsor There may be multiple sponsors with multiple objectives

The stakeholders Identifying stakeholders Defining success by understanding stakeholder expectations Establishing stakeholder priorities

Defining Management Roles

The project team Using expertise appropriately The role of the steering committee

Scoping the project Defining deliverables Agreeing duration Agreeing cost Defining quality

Scope change Understand the difference between scope creep and recognising changing specifications Establish a process for accepting or rejecting changes to scope Ensure that rejected changes to scope are addressed

Time and cost estimates Avoid allowing single person to do the time estimates for each of the activities Refer to similar projects for cost estimates

Quality Define and monitor quality at team level Ensure common understanding of expectations from the outset

Setting realistic workloads Understanding workload models and assumptions Self perception of abilities – skill acquisition Understanding responsibility for workload decisions Perception of the work involved and skills required

Multi-skilling – a productivity issue Understand what skills are required Don’t underestimate the importance of soft skills – the ability to work as a team Where possible keep ‘successful’ teams intact or use as ‘mentor teams’/steering committee members

Monitoring and communication Planning and review alone are insufficient Regular contact between team members Regular reference to objectives, priorities Regular checking of workload, skills, costs, time, scope

Resolving problems Sponsor responsibilities Project team responsibilities Management responsibilities

Organisational Culture Tolerance of risk Tolerance of chaos Flexibility Respect for expertise of all team members Working on ‘the edge’ Playing games Political objectives Stated versus actual values and objectives

Long term benefits versus short term successes Long term benefits versus short term failures Knowing the difference

Quantifying Success The cost of success Maintenance Ease of migration Impact on academic workload Lifespan of project output Use beyond original developers

What we have learnt for next time Analyse the history of previous innovation developments and learn from the experience Document the process and store the documents centrally Develop a culture of learning from projects Be realistic about objectives and the will to achieve them