It’s the little things that count
Managing communication in
multidisciplinary teams
Graham Oakes Ltd
14 July 2004 1 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.
Graham Oakes Ltd
14 July 2004 2 www.fairknowledge.com
Questions in system & device development
Why should we build this system?
Business drivers, processes and ROI
Will people use it once we’ve built it?
User drivers and models
User interface design
How will it interact with other systems?
Technical standards and interfaces
How will we build it?
Fast moving technology, business context, etc
Specialist applications and tools
How will we (or the user) maintain and operate it?
Graham Oakes Ltd
14 July 2004 3 www.fairknowledge.com
For complex systems, we need many skills Sponsors
Project managers Business analysis
Ergonomics Graphic design
User interface
Operations & maintenance Information
Architecture
Interfaces to other systems
Change mgt
Technical Programmer
System Tech Specialists
Users
Tools specialists
Architects Ethnographers
Operations
specialists
Graham Oakes Ltd
14 July 2004 4 www.fairknowledge.com
Each with its own language Sponsors Business analysis
Project managers
User Requirements?
What information or
Ergonomics Graphic design
User interface functions will fill the
gaps?
User Requirements? What
Operations & maintenance Information
rules need to be applied to Architecture
create the information?
Interfaces to other systems
Change mgt
Technical Programmer
System Tech Specialists
Users
Tools specialists
Architects Ethnographers
Operations
specialists
User Requirements?
What gaps need to
be filled?
Graham Oakes Ltd
14 July 2004 5 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…
Graham Oakes Ltd
14 July 2004 6 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…
Graham Oakes Ltd
14 July 2004 7 www.fairknowledge.com
Solutions?
Define a standard process and methodology
Whose?
Will they all use it?
Can they all use it and still deliver their speciality?
Create a standard culture & train (clone?) everyone
Is that really possible across multi-party projects?
Will we keep all the diversity we wanted?
Use simple communication tools
Graham Oakes Ltd
14 July 2004 8 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.
Graham Oakes Ltd
14 July 2004 9 www.fairknowledge.com
Keeping in touch with reality
Build a clear picture and common language
to describe things at the outset
Project Initiation
Project Planning
Build a framework so we won’t delude
ourselves later
Project Tracking
Keep in touch with everyone’s view
Run effective meetings
Do periodic structured reviews
Graham Oakes Ltd
14 July 2004 10 www.fairknowledge.com
Initiation
Vision
Why as well as what
(Project teams make many ad hoc decisions)
Roles and responsibilities
Common practices
Etiquette
Day-to-day activities
Project norms
Graham Oakes Ltd
14 July 2004 11 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
Graham Oakes Ltd
14 July 2004 12 www.fairknowledge.com
Virtual control centre
Graham Oakes Ltd
14 July 2004 13 www.fairknowledge.com
Virtual control centre
Graham Oakes Ltd
14 July 2004 14 www.fairknowledge.com
Virtual control centre
Graham Oakes Ltd
14 July 2004 15 www.fairknowledge.com
Virtual control centre
Graham Oakes Ltd
14 July 2004 16 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:
What have I done?
What do I plan to do?
What’s blocking progress?
Graham Oakes Ltd
14 July 2004 17 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
What happened? (Objective history)
What was significant? (Subjective history)
Learn from significant events and gaps.
Graham Oakes Ltd
14 July 2004 18 www.fairknowledge.com
Review structure
“Fit for CRITERIA
Purpose”
REFERENCE MODELS
BASELINE Correct
“Best
ITIL
Business Architecture Complete
CMM Practice”
Currently Business Transition Consistent
Reference Architectures
Assumed Clear
Feedback
Loop
Business INPUTS
Programme Brief
Programme plans & budgets
and supporting detail REVIEW
Go or
No Go
Technical INPUTS Analysis
Technical Architecture Framework
Loop
Technology Strategy
and supporting detail
Recommendations
Graham Oakes Ltd
14 July 2004 19 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
Graham Oakes Ltd
14 July 2004 20 www.fairknowledge.com
Thank you
Graham Oakes Ltd
14 July 2004 21 www.fairknowledge.com