How to effectively engage users andmanagers in IT projects                  Richard Collings             Independent IT Co...
Agenda•   Introductions•   Why involving users and managers is    important•   Some general observations, principles    an...
INTRODUCTIONS
Your background1.   Executive team/Trustee?2.   IT Management?3.   Project manager?4.   IT Practitioner?5.   Business mana...
Your approach1. Traditional/plan driven/PRINCE 2 (and   not going to change)2. As for 1 but interested in agile3. Hybrid4....
My background•   Practitioner consultant (with some sales)•   20 years as an independent working in    not for profit sect...
Example projects                                               Project size                            Rural Payments Agen...
Sources/Influences
WHY INVOLVEMENT ISIMPORTANT
Some evidenceBut not a lot! Good „clinical‟ evidence ishard to come by:„…we need considerably more empirical studies of pr...
Why IT Projects are difficult„Human and social factors have a very strong impact on the   success of software development ...
Factors affecting success           Success factor                                    Influence           User involvement...
Why involve senior managers?•   Generate or „buy into‟ the vision•   Getting the right decisions made•   Deliver the „some...
Case study: RPA“There has been a lack of senior  management ownership of the scheme in  the Agency and DEFRA” NAO 2009• Po...
Why involve middle/team             managers?•   Understand existing systems (but ….)•   May have the vision how the new s...
Why involve front line users•   Often have best understanding of    existing system/ways of working•   Have a lot of knowl...
Why involve Service usersCase 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 ...
Choosing the right techniques   Cynefin: what type of problem is it:© Dave Snowden used under a Creative Commons Attributi...
One approach: „Outside-in‟ Software Development:Outside-in Software Development A Practical Approach toBuilding Successful...
People:•   Learn as the project proceeds    •   Managers/Business Users    •   Implementers    ie: your current project is...
Influencing peopleUseful tool from Roberta Chatham. People:• Respond to style (97-98%) not facts (2-3%)• Respond different...
People: conclusions•   Need to understand each key    stakeholder•   „Test the water‟•   One to one sessions/chats are a k...
Other bits and pieces•   Managers often don‟t have a full picture•   People tell you what they think they    should tell y...
Health warningsThe following can be bad for your projecthealth:• Sign offs• Methodologies• Shared service• Product owner/s...
Why this project failed       • Culture clash       • Communication         failure
SPECIFIC TECHNIQUES
Governance•   PRINCE2 is sound base provided    •   Procedure does not supplant common sense•   Supplemented by    •   Inf...
Planning/budgeting•   Budget to backfill key managers/front    line staff•   Allow for travel/face to face work/    colloc...
Involving managers/users•   Set up working group•   „Diagonal slice‟ through organisation•   Meets 2-3 times/week plus hom...
Requirements stageAim  • Build requirements  • Build understanding of other stakeholders  • Build understanding of require...
Procurement•   Early demos of different options•   Site visits by suppliers•   Managing „love affairs‟•   Get suppliers to...
Implementation/testing•   „Mockups‟ do work – particularly with    scenarios•   Aim for early and frequent release of    s...
Rollout•   Use your Design/Working Group as    trainers•   Start small – early releases are a    learning opportunity•   R...
WRAP UP
End result•   Happy users and managers•   Slow „post live‟ rate of change•   Low cost of ownership•   Adaptable systems•  ...
Downsides•   Initial timetable looks longer (but overall    project is often shorter)•   Additional cost (but saves money ...
The final word
ResourcesEmail: rc@rcollings.co.ukLinked in:  http://uk.linkedin.com/in/richardcollings/Links to articles and papers:  htt...
Questions
Upcoming SlideShare
Loading in …5
×

3B - How to effectively engage users and managers in IT projects - Richard Collings

426 views
346 views

Published on

Published in: Economy & Finance
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
426
On SlideShare
0
From Embeds
0
Number of Embeds
120
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

3B - How to effectively engage users and managers in IT projects - Richard Collings

  1. 1. How to effectively engage users andmanagers in IT projects Richard Collings Independent IT Consultant “Helping people, technology and organisations work together”
  2. 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. 3. INTRODUCTIONS
  4. 4. Your background1. 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. 5. Your approach1. 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
  6. 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. 7. Example projects Project size Rural Payments Agency Grant management C&C systemSupporters/ Service Multiple Multiple Departmental Single Public Users/ partners/ departments/ stakeholder Members mergers regions Refugee Councils Case Management Web site Web site
  8. 8. Sources/Influences
  9. 9. WHY INVOLVEMENT ISIMPORTANT
  10. 10. Some evidenceBut not a lot! Good „clinical‟ evidence ishard 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. 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. 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 pointsStandish Group CHAOS report (1998). Survey of 23,000 firms
  13. 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. 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. 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. 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. 17. Why involve Service usersCase study: Stockport SEN TransportUsing Vanguard „Check‟ Method (not from my own practice)
  18. 18. GENERAL OBSERVATIONS,PRINCIPLES & TOOLS
  19. 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. 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. 21. One approach: „Outside-in‟ Software Development:Outside-in Software Development A Practical Approach toBuilding Successful Stakeholder-Based Products Carl Kessler& John Sweitzer
  22. 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. 23. Influencing peopleUseful 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. 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. 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. 26. Health warningsThe following can be bad for your projecthealth:• Sign offs• Methodologies• Shared service• Product owner/single business user• People who want things to be simple
  27. 27. Why this project failed • Culture clash • Communication failure
  28. 28. SPECIFIC TECHNIQUES
  29. 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. 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. 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. 32. Requirements stageAim • Build requirements • Build understanding of other stakeholders • Build understanding of requirementsTechniques • „Ethnographic‟ investigation • Follow the work • Use Cases (vs User Stories vs BPM) • Generic models • Help stakeholders build understanding
  33. 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. 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. 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. 36. WRAP UP
  37. 37. End result• Happy users and managers• Slow „post live‟ rate of change• Low cost of ownership• Adaptable systems• Delivery of business benefit
  38. 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. 39. The final word
  40. 40. ResourcesEmail: rc@rcollings.co.ukLinked in: http://uk.linkedin.com/in/richardcollings/Links to articles and papers: https://delicious.com/#richardcollingsBooklist: http://www.shelfari.com/o1514895178Twitter: @richard_colling
  41. 41. Questions

×