It’s the little things that count Managing communication in multidisciplinary teams 14 July 2004 1 Graham Oakes Ltd www.fairknowledge.com Objectives Discuss experience derived from working with multidisciplinary teams to deliver complex systems in government, industry and games development. Address questions such as Why use multidisciplinary teams? What problems do they experience? How can these problems be reduced? No silver bullets – just practical tools for the toolbox. 14 July 2004 2 Graham Oakes Ltd www.fairknowledge.com Questions in system & device development Why should we build this system? Will people use it once we’ve built it? Technical standards and interfaces How will we build it? User drivers and models User interface design How will it interact with other systems? Business drivers, processes and ROI Fast moving technology, business context, etc Specialist applications and tools How will we (or the user) maintain and operate it? 14 July 2004 3 Graham Oakes Ltd www.fairknowledge.com For complex systems, we need many skills Sponsors Business analysis Project managers Ergonomics Graphic design User interface Information Architecture Operations & maintenance Interfaces to other systems Change mgt Programmer Tech Specialists Technical System Users Tools specialists Architects Ethnographers Operations specialists 14 July 2004 4 Graham Oakes Ltd www.fairknowledge.com Each with its own language Sponsors Project managers Business analysis User Requirements? What information or Ergonomics Graphic design functions will fill the gaps? User interface User Requirements? What & maintenance rules needOperations to be applied to create the information? Information Architecture Interfaces to other systems Change mgt Programmer Tech Specialists Technical System Users Tools specialists Architects Ethnographers Operations specialists User Requirements? What gaps need to be filled? 14 July 2004 5 Graham Oakes Ltd www.fairknowledge.com And its own mindset What is the right trade-off of time versus “quality”? What is “quality” anyway? What needs to be done first? Tolerance for risk & ambiguity Recognition of what is ambiguous Preferred style of working (e.g. in a group or alone?) If the team can’t talk to each other & understand what each other is saying, you don’t have a team… 14 July 2004 6 Graham Oakes Ltd www.fairknowledge.com And its own methods to solve problems Eliciting requirements Observation Structured investigation Keep trying stuff until something works Reducing uncertainty Designing solutions Managing time, schedules & budgets The team may be each individually doing great stuff, but if these methods don’t work together, it can all add up to much less than an integrated whole… 14 July 2004 7 Graham Oakes Ltd www.fairknowledge.com Solutions? Define a standard process and methodology Create a standard culture & train (clone?) everyone Whose? Will they all use it? Can they all use it and still deliver their speciality? Is that really possible across multi-party projects? Will we keep all the diversity we wanted? Use simple communication tools 14 July 2004 8 Graham Oakes Ltd www.fairknowledge.com Two principles of project management Projects fail because they lose touch with reality In most project teams, someone knows what’s really going on So we just want to make it safe & possible to spread that view of reality. 14 July 2004 9 Graham Oakes Ltd www.fairknowledge.com Keeping in touch with reality Build a clear picture and common language to describe things at the outset Build a framework so we won’t delude ourselves later Project Initiation Project Planning Project Tracking Keep in touch with everyone’s view 14 July 2004 Run effective meetings Do periodic structured reviews 10 Graham Oakes Ltd www.fairknowledge.com Initiation Vision Why as well as what (Project teams make many ad hoc decisions) Roles and responsibilities Common practices 14 July 2004 Etiquette Day-to-day activities Project norms 11 Graham Oakes Ltd www.fairknowledge.com Planning and tracking High level and detailed plans Inch pebbles with clear criteria Communications plan Risks and issues Actions are performed by people, by a time (Virtual) Control Centre Framework 14 July 2004 12 Graham Oakes Ltd www.fairknowledge.com Virtual control centre 14 July 2004 13 Graham Oakes Ltd www.fairknowledge.com Virtual control centre 14 July 2004 14 Graham Oakes Ltd www.fairknowledge.com Virtual control centre 14 July 2004 15 Graham Oakes Ltd www.fairknowledge.com Virtual control centre 14 July 2004 16 Graham Oakes Ltd www.fairknowledge.com Meetings have Purpose Agenda Result (actions) And the best ones are small and frequent E.g. daily stand-up with the 3 questions: 14 July 2004 What have I done? What do I plan to do? What’s blocking progress? 17 Graham Oakes Ltd www.fairknowledge.com Reviews Projects fail because they lose touch with reality It’s very easy to delude ourselves: external views of reality are essential Multidisciplinary team Experienced practitioners Preparation & structure Capture lessons in a structured retrospective 14 July 2004 What happened? (Objective history) What was significant? (Subjective history) Learn from significant events and gaps. 18 Graham Oakes Ltd www.fairknowledge.com Review structure “Fit for Purpose” Currently Assumed CRITERIA BASELINE Business Architecture Business Transition REFERENCE MODELS Correct Complete Consistent Clear “Best ITIL Practice” CMM Reference Architectures Feedback Loop Business INPUTS Programme Brief Programme plans & budgets and supporting detail Technical INPUTS Technical Architecture Framework Technology Strategy REVIEW Go or No Go Analysis Loop and supporting detail Recommendations 14 July 2004 19 Graham Oakes Ltd www.fairknowledge.com Summary We need diversity to succeed If we don’t manage diversity, we’ll fail anyway Plan to communicate Communicate Check that the communication worked And ask someone else to check for you too 14 July 2004 20 Graham Oakes Ltd www.fairknowledge.com Thank you 14 July 2004 21 Graham Oakes Ltd www.fairknowledge.com