How to effectively engage users and managers in IT projects

How to effectively engage users and managers in IT projects Richard Collings Independent IT Consultant “Helping people, technology and organisations w...
Author: Lisa McDaniel
3 downloads 0 Views 856KB Size
How to effectively engage users and managers in IT projects Richard Collings Independent IT Consultant “Helping people, technology and organisations work together”

Agenda • • • •

Introductions Why involving users and managers is important Some general observations, principles and tools Some specific techniques for each stage of a project

INTRODUCTIONS

Your background 1. 2. 3. 4. 5. 6. 7.

Executive team/Trustee? IT Management? Project manager? IT Practitioner? Business manager/user? Some or all of the above? Other?

Your approach 1. Traditional/plan driven/PRINCE 2 (and not going to change) 2. As for 1 but interested in agile 3. Hybrid 4. Wholly agile (Scrum, DSDM, etc) 5. Other/not sure

My background • • •

Practitioner consultant (with some sales) 20 years as an independent working in not for profit sector ‘Soup to nuts’, complex, multistakeholder projects •

• • •

Mainly large (multi-year) but some small

Work at interface between business and IT Use multiple methodologies Sceptic

Example projects Project size Rural Payments Agency Grant management RSPCA C&C system Supporters/ Public

Service Users/ Members

Multiple partners/ mergers

Multiple departments/ regions

Refugee Councils Case Management Web site

Web site

Departmental

Single stakeholder

Sources/Influences

WHY INVOLVEMENT IS IMPORTANT

Some evidence But not a lot! Good ‘clinical’ evidence is hard to come by: ‘…we need considerably more empirical studies of practice. We simply don’t have enough information about the actuality of practice to be certain that our research efforts are addressing the significant problems of a practice oriented discipline’ Robinson, H. (2001). "Reflecting on research and practice." IEEE Software, Jan/Feb 2001, 18(1): 112-111

Why IT Projects are difficult ‘Human and social factors have a very strong impact on the success of software development endeavours and the resulting system. Surprisingly, much of software engineering research in the last decade is technical, quantitative and deemphasizes the people aspect’ John, M., Maurer, F. and Bjomar, T. (2005). Human and Social Factors of Software Engineering - Workshop Summary. Proceedings of the International Conference of Software Engineering, St Louis, Missouri, USA.

are conducted today in complex environments. occur in a fragile matrix of applications, users, business demands, laws, internal politics, budgets and organisational dependencies that change constantly‘ Standish Group CHAOS report (1998)

Factors affecting success Success factor

Influence

User involvement

20 points

Executive Support

15 points

Clear Business Objectives

15 points

Experienced Project Manager

15 points

Small milestones

15 points

Firm basic requirements

5 points

Competent staff

5 points

Ownership

5 points

Other

5 points

Standish Group CHAOS report (1998). Survey of 23,000 firms

Why involve senior managers? • • • • • •

Generate or ‘buy into’ the vision Getting the right decisions made Deliver the ‘something magic’ Commit the resources Knock heads together Ask the difficult questions; solve the difficult problems

Case study: RPA “There has been a lack of senior management ownership of the scheme in the Agency and DEFRA” NAO 2009

• Poor senior decision making • Total cost: £350m (cf original est: £75.8m) • 100 contractors @ £200k pa to maintain • Avg cost per grant: £1743 (cf Scotland £285)

Why involve middle/team managers? • • • • • • •

Understand existing systems (but ….) May have the vision how the new system will deliver improvements Responsible for delivering the changes needed Their attitude will affect the attitude of the teams Monitor/QA use of system by their teams Use data from the system Can steer senior management (sometimes)

Why involve front line users • • • • • •

Often have best understanding of existing system/ways of working Have a lot of knowledge in their heads Understand the variations that can occur Will be the main users of the new system Their attitude will have a dramatic effect on success or failure ‘Word travels fast’

What happens if you don’t Social workers report spending between 60% and 80% of their time at the computer screen and this was borne out by our observations. The details required by ICS are often repetitive and rarely read by others. They do not promote good decision-making. Many versions of the system are unstable and work is routinely lost We have encountered not one social worker or team manager who is happy with ICS and all report vastly increased bureaucratic and administrative loads, lamenting that this takes them away from the 'real work' – and it does.

‘Repeating the same mistakes’ Professor Sue White et al. The Guardian 19/11/2008

Why involve Service users Case study: Stockport SEN Transport Using Vanguard ‘Check’ Method (not from my own practice)

GENERAL OBSERVATIONS, PRINCIPLES & TOOLS

Introduction • • • •

Implementing IT systems that work and that users like is not easy There is no silver bullet Need to choose the right tools for the particular situation Going to look at •

A couple of different views



What I found works



A useful resource



Some health warnings

Choosing the right techniques Cynefin: what type of problem is it:

Where is your comfort zone? © Dave Snowden used under a Creative Commons Attribution 3.0 Unported licence

One approach: ‘Outside-in’ Software Development:

Outside-in Software Development A Practical Approach to Building Successful Stakeholder-Based Products Carl Kessler & John Sweitzer

People: •

Learn as the project proceeds •

Managers/Business Users



Implementers

ie: your current project is the best source of learning



Are more flexible if they feel that they have been understood •



Things become easier if people trust you

Are not always right •

How to deal with this

Influencing people Useful tool from Robina Chatham. People: • Respond to style (97-98%) not facts (2-3%) • Respond differently according to type: Task Pragmatic types Theoretical types focused Eg IT specialists and accountants Eg CEOs and Lawyers •Practical and matter of fact •Logical and ingenious •Structure and lists •Theory and models •Proof and evidence •Big picture and big ideas Detailed Sociable types Eg Nurses and receptionists •Sympathetic & friendly •Personal touch •Truth and respect

Big picture Idealistic types Eg Journalists and psychologists •Enthusiastic & insightful People •Analogies & metaphors focused •Passion and enthusiasm

© Corporate politics for IT Managers. How to get streetwise. Keith Patching & Robina Chatham

People: conclusions • • •

Need to understand each key stakeholder ‘Test the water’ One to one sessions/chats are a key part of the process

Other bits and pieces • • • • • •

Managers often don’t have a full picture People tell you what they think they should tell you It’s the variations that cause the problems ‘Backs of envelopes’ are useful Make decisions ‘at the last responsible moment’ High bandwidth/informal communication is critical (Grant management project)

Health warnings The following can be bad for your project health: • Sign offs • Methodologies • Shared service • Product owner/single business user • People who want things to be simple

Why this project failed • Culture clash • Communication failure

SPECIFIC TECHNIQUES

Governance •

PRINCE2 is sound base provided •



Procedure does not supplant common sense

Supplemented by •

Informal one to ones



A culture which encourages early surfacing of issues

Planning/budgeting • •



Budget to backfill key managers/front line staff Allow for travel/face to face work/ collocation/embedding project in operational areas Provide for piloting and refactoring

Involving managers/users • • • •



Set up working group ‘Diagonal slice’ through organisation Meets 2-3 times/week plus homework and on-site work Choose managers/users: •

Reasonably structured thinkers



Understand the work



Good people skills

Plus Reference Group (for the ‘challenging’)

Requirements stage Aim • Build requirements • Build understanding of other stakeholders • Build understanding of requirements

Techniques •

‘Ethnographic’ investigation



Follow the work



Use Cases (vs User Stories vs BPM)



Generic models



Help stakeholders build understanding

Procurement • • • •

Early demos of different options Site visits by suppliers Managing ‘love affairs’ Get suppliers to work with you to build your scenarios

Implementation/testing • •



‘Mockups’ do work – particularly with scenarios Aim for early and frequent release of software (don’t be too scared) Hands on testing by users and observe use (not ‘Show & Tell’) •



‘Rocket Surgery Made Easy’ (Steve Krug)

Manage expectations (there will be problems)

Rollout • •

• • •

Use your Design/Working Group as trainers Start small – early releases are a learning opportunity Release the ‘Minimum Viable Product’ Allow a learning/evolution period and then stabilise Focus training on managers

WRAP UP

End result • • • • •

Happy users and managers Slow ‘post live’ rate of change Low cost of ownership Adaptable systems Delivery of business benefit

Downsides • •



Initial timetable looks longer (but overall project is often shorter) Additional cost (but saves money in longer term) Need to find staff who can backfill

The final word

Resources Email: [email protected] Linked in: http://uk.linkedin.com/in/richardcollings/ Links to articles and papers: https://delicious.com/#richardcollings Booklist: http://www.shelfari.com/o1514895178 Twitter: @richard_colling

Questions