3b - how to effectively engage users and managers in it projects - richard collings
DESCRIPTION
TRANSCRIPT
How to effectively engage users and managers in IT projects
Richard CollingsIndependent 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. Executive team/Trustee?2. IT Management?3. Project manager?4. IT Practitioner?5. Business manager/user?6. Some or all of the above?7. Other?
Your approach
1. Traditional/plan driven/PRINCE 2 (and not going to change)
2. As for 1 but interested in agile3. Hybrid4. 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, multi-stakeholder projects• Mainly large (multi-year) but some
small
• Work at interface between business and IT
• Use multiple methodologies• Sceptic
Example projects
Single stakehold
er
Departmental
Multiple departments/ regions
Multiple partners/ mergers
Service Users/
Members
Supporters/ Public
Refugee Councils Case Management
C&C system
Grant management
Rural Payments Agency
Web site Web site
Project size
Sources/Influences
Traditional business analysis
PRINCE2Scrum
(Schwaber et al)
Evo (Tom Gilb)
xP(Kent Beck)
Systems Thinking
(John Seddon)
Peopleware(DeMarco &
Lister)
Lean Software Development
(Mary and Tom Poppendieck)
Outside InKeisler & Sweitzer
Corporate Politics for IT Managers
Patching & Chatham
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.
<IT Projects> are conducted today in complex environments. <They> 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’
Why involve Service users
Case study: Stockport SEN TransportUsing 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:
© 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 Roberta Chatham. People:
• Respond to style (97-98%) not facts (2-3%)
• Respond differently according to type:Pragmatic typesEg IT specialists and accountants• Practical and matter of fact• Structure and lists• Proof and evidence
Theoretical typesEg CEOs and Lawyers• Logical and ingenious• Theory and models• Big picture and big ideas
Sociable typesEg Nurses and receptionists• Sympathetic & friendly• Personal touch• Truth and respect
Idealistic typesEg Journalists and psychologists• Enthusiastic & insightful• Analogies & metaphors• 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• Communicatio
n 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] 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