All too often, business analysts and product managers find themselves in the roll of glorified scribe. We use elicitation techniques to get our business partners and customers tell us what they think the system needs to do and then we diligently write high quality requirements to describe that for development and testing. This is certainly being extreme, but I have definitely seen it more often than I should – which is never!
One of the things we can do to combat that is think about how to make our customers’ applications better. In fact, part of why people should get excited about being a business analyst or product manager is that they get to use creativity to design new software products! But reality sets in and we often don’t think we are that creative (we are just analysts right?) or don’t know how to be creative within the constraints of the customer’s project. Given this, I was intrigued to hear Neil Maiden’s keynote at RE’13, “Requirements Engineering as Information Search and Idea Discovery.” Neil is the Head of the Centre for HCI Design and co-founder of the Centre for Creativity in Professional Practice at City University London. He’s certainly done a lot more *creative* thinking on this topic than I have so I was happy to borrow his ideas!
Here are a few of Neil’s talking points that I think are most relevant:
- Requirements work is inherently creative
- Creativity is about finding the novel (original and unexpected) and appropriate (useful) concepts.
- Stakeholders are thinking about the future whether we like it or not – they are being creative
Given all of that, he suggests that we can re-frame requirements work as “creative information search and idea discovery” where we explore and expand the boundaries of our thinking. Neil referenced a technique in the keynote and has since graciously been able to give me guidance on how to use it with our teams. The technique is a constraint removal workshop. We have done a few internally already. The premise behind the technique is:
- Constraints impose creative blocks during the problem solving stages.
- Stakeholders typically know what the constraints are (customers and analysts alike love to say “but”, such as: “but that idea just won’t work because….”).
- Using them can be a great launching point for creative thinking! If life gives you lemons….make lemonade!
The gist of the constraint removal technique is to:
- Decide what problem you are solving
- Brainstorm the constraints involved in solving that problem
- For each constraint, imagine an alternative version of space where the constraint isn’t true and brainstorm new possibilities without the constraint.
- Come back into reality with those new possibilities. Think about whether you can actually remove the constraint, reduce it, or just interpret it differently to find a way to use any of the new ideas or variations on them to solve the problem.
Step 3 is the crux of it – where the magic can happen. You are truly asking people to change a boundary and expand their thinking, in hopes you will discover something new that might actually work in the original problem space. One point Neil suggested to me is that you want to encourage the team to keep working with the ideas generated. The first ideas, as Neil says, might seem “daft, but over time, incubation and learning takes place and the ideas take on more value.”
Neil shares great examples of using this technique (see his keynote slides), but I’ll share mine here. Our first attempt at trying the technique was primarily to introduce our teams to the concept. I gave the team a lot of background on the technique and then thought we’d try it. I opted to try to solve the problem “how can we be more creative on our customer projects” – though a bit of looping on itself, it seemed appropriate to teach the point! Initially I had heard grumbles about “I can’t be creative on my project, I have to knock out requirements for what they want and there is no time for more” and “I’m not creative.”
In the workshop, we started with a use case diagram that shows a wide range of the activities we do today as product managers on customer projects. We looked for missing actors, missing use cases, and for tasks that we thought we could be creative with today. Then we brainstormed a list of constraints that were in the way of us being creative on projects. We time-boxed that discussion but still got 10-15 unique constraints once we grouped them.
For example, we came up with fixed budgets, deadlines, and lacking knowledge. Then we divided up into groups of 3-4 people and assigned a constraint to each group. Each group was tasked with envisioning a world in which their constraint was removed to come up with new ideas for how to be creative on projects. For example, if money was not a constraint, how could you be creative on your projects? The only guidance given was that they could think about new actors, new use cases, or changing how they performed activities currently. Then we could talk about some of the most promising ideas generated to see if they inspired something we could actually do differently on our projects.
The group that removed the “money” constraint was able to come up with a lot of ideas, such as: “Fly domain experts in from any part of the world to learn about their cutting edge ideas for the domain”, or “On a search engine project, bring in a world renowned search expert.” This was one of many ideas but in particular, I saw an immediate link here to something useful. Usually we won’t be able to actually fly someone in (money is actually a constraint), but I thought maybe we could mimic the same thing without putting them on a plane! What if we reached out to an expert to ask them to do a one-hour call with us to teach us? Experts often love to share their ideas. Or what if we just researched their work on the internet and read relevant papers? Might we get new ideas that way?
For example, with this new technique, I can’t afford to fly Neil in to run creativity workshops for me every week. However, he’s certainly willing to send me information or chat with me on Skype about roadblocks and ideas. Why couldn’t we do that in any domain we are working in? In fact, one specific team is working on requirements for an analytics engine, so out of this we suggested that they meet with experts and read a few papers out there just to get up to speed on what the possibilities are with an analytics solution. That space is full of information and new ideas, so we can bring them back to our customers for their projects. This is a simple example of us bringing creative ideas to the customer instead of just writing down any requirement they think of. And guess what? Money isn’t needed to do this.
In the end, even if the constraint cannot be removed, maybe we can reduce the effect of it on the project. We can use it to look for new ideas, expanding the set of ideas we come up with otherwise. I think this is such a great technique we can use in elicitation workshops. We’ve tried it internally, and are going to again in another internal forum. This time, we are going to solve the problem “How should we resource our projects?” Next time, I hope we can use it on a customer project to see how that goes for identifying new features.
