1. How to effectively engage users and
managers in IT projects
Richard Collings
Independent IT Consultant
“Helping people, technology and organisations work together”

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

3. INTRODUCTIONS

4. 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?

5. 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

6. 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

7. Example projects
Project size
Rural Payments Agency
Grant
management
C&C
system
Supporters/ Service Multiple Multiple Departmental Single
Public Users/ partners/ departments/ stakeholder
Members mergers regions
Refugee Councils Case
Management
Web site Web site

8. Sources/Influences

9. WHY INVOLVEMENT IS
IMPORTANT

10. 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

11. 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)

12. 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

13. 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

14. 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)

15. 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)

16. 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‟

17. Why involve Service users
Case study: Stockport SEN Transport
Using Vanguard „Check‟ Method (not from my own practice)

18. GENERAL OBSERVATIONS,
PRINCIPLES & TOOLS

19. 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

20. Choosing the right techniques
Cynefin: what type of problem is it:
© Dave Snowden used under a Creative Commons Attribution 3.0 Unported licence

21. One approach:
„Outside-in‟ Software Development:
Outside-in Software Development A Practical Approach to
Building Successful Stakeholder-Based Products Carl Kessler
& John Sweitzer

22. 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

23. Influencing people
Useful tool from Roberta Chatham. People:
• Respond to style (97-98%) not facts (2-3%)
• Respond differently according to type:
Pragmatic types Theoretical types
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
Sociable types Idealistic types
Eg Nurses and receptionists Eg Journalists and psychologists
•Sympathetic & friendly •Enthusiastic & insightful
•Personal touch •Analogies & metaphors
•Truth and respect •Passion and enthusiasm
© Corporate politics for IT Managers. How to get streetwise. Keith Patching & Robina
Chatham

24. People: conclusions
• Need to understand each key
stakeholder
• „Test the water‟
• One to one sessions/chats are a key
part of the process

25. 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)

26. 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

27. Why this project failed
• Culture clash
• Communication
failure

28. SPECIFIC TECHNIQUES

29. 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

30. 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

31. 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‟)

32. 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

33. Procurement
• Early demos of different options
• Site visits by suppliers
• Managing „love affairs‟
• Get suppliers to work with you to build
your scenarios

34. 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)

35. 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

36. WRAP UP

37. End result
• Happy users and managers
• Slow „post live‟ rate of change
• Low cost of ownership
• Adaptable systems
• Delivery of business benefit

38. 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

39. The final word

40. Resources
Email: rc@rcollings.co.uk
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

41. Questions