Consulting Community Day - "Shaping Discovery"
Date posted
6 February 2015
Reading time
7 Minutes
Consulting Community Day - "Shaping Discovery"
One of the many great initiatives in Kainos is that we hold community days for the different capabilities. These are great events which are held to bring people from different areas of the business together to share ideas, discuss hot topics, and present workshops on things we've learned, achieved, or want to improve. As part of the Consulting Community Day, Jane Fletcher and I chose to work together to present a workshop around Discovery.
From experience, we were both aware of many of the issues projects encounter which are based upon a weak discovery process - be they spiralling cost, scope creep or teams sprinting too early before the project is ready to head into full on development.
As the saying goes.. Prior Preparation and Planning prevents Poor Performance.
To many, simply asking users for a list of features is what they consider to be user research - in fact what discovery seeks to understand is not WHAT the user wants from a new product or service but WHY.
After all, the Henry Ford quote springs to mind
The first part of the workshop, we planned 10 minutes in open discussion, recording what the participants thought discovery actually meant to them and recorded their points on a board to compare with later findings.
We then split the group into two large teams and presented them with a fictious (but nearly lifelike) scenario to challenge their thinking:
We provided them with a list of potential outputs to help steer discussion and set them the challenge of using the scenario to present a plan on how they would achieve a proper discovery.
This proved to be a lively time, both teams got immersed in the challenge and worked well together, even responding to the technical questions Davey McGlade threw into the mix acting in role as Architect.
We gave them time to present their plans, allowing for questions (and a bit of competitive banter), then came together as a group to record and agree unified way of running a discovery, by breaking the work into the following areas:
Jane and I feel like we've opened Pandora's box - we have many ideas, some rough headings and a sketched out process - but many more questions to still be answered - so watch this space on where we are going to take this next!
From experience, we were both aware of many of the issues projects encounter which are based upon a weak discovery process - be they spiralling cost, scope creep or teams sprinting too early before the project is ready to head into full on development.
As the saying goes.. Prior Preparation and Planning prevents Poor Performance.
To many, simply asking users for a list of features is what they consider to be user research - in fact what discovery seeks to understand is not WHAT the user wants from a new product or service but WHY.
After all, the Henry Ford quote springs to mind
'If I asked what people wanted - I would have given them faster horses'But discovery doesn't just focus upon user research but an entire team working together to prepare a project for the agile teams to start sprinting. On the day, we were delighted by the response; we got a great mix of people from all different areas within Consulting (Product, Agile, UX).
The first part of the workshop, we planned 10 minutes in open discussion, recording what the participants thought discovery actually meant to them and recorded their points on a board to compare with later findings.
We then split the group into two large teams and presented them with a fictious (but nearly lifelike) scenario to challenge their thinking:
Scenario The Department of Studies (DoS) are initiating a programme of work to capture information pertaining to the electronic registration of pets.There is currently an issue in the UK with too many uncontrolled 'pet' animals (cats & dogs) in the wild. Animal Control is costing the UK taxpayers £x per year. The DoS wants to put the responsibility of this back on pet owners through a scheme of electronically tagging & recording pets.Everyone was asked to choose a role that they wouldn't normally be assigned to - getting designers to think in the role of an service manager, a BA in the role of Product Manager.
We provided them with a list of potential outputs to help steer discussion and set them the challenge of using the scenario to present a plan on how they would achieve a proper discovery.
This proved to be a lively time, both teams got immersed in the challenge and worked well together, even responding to the technical questions Davey McGlade threw into the mix acting in role as Architect.
We gave them time to present their plans, allowing for questions (and a bit of competitive banter), then came together as a group to record and agree unified way of running a discovery, by breaking the work into the following areas:
- Research & Design
- Business
- Technical
Jane and I feel like we've opened Pandora's box - we have many ideas, some rough headings and a sketched out process - but many more questions to still be answered - so watch this space on where we are going to take this next!