- SAP Managed Tags:
As like most of my blogs, this one is going to be about the goings on at Barnsley MBC where I work. We are currently going through a large digital transformation at Barnsley, with the intention of cutting costs, improving efficiency and improving data quality to name a few benefits.
We've recently initiated a new project and we are currently gathering requirements, without giving too much detail away we intend to implement a new mobile app for out fleet team, who maintain the vehicles and buildings used by BMBC. However, the main thing I wanted to talk about was the design thinking approach we have taken, in order to gather those requirements.
Design Thinking
Now if you've not heard the term design thinking, then where have you been! Particularly in SAP world anyway. However, if you genuinely haven't here is a great definition I found.
There are also some great resources on Open SAP, like the ones below
Our experience
Anyway a little bit about our experience in this project...
It all started off with an idea, which lead to a workshop. This workshop was essentially a design thinking work shop, and included key stakeholders in the project, including myself as a developer, future users (in design thinking it's key you have users involved in this process), data experts, some managers involved in the project and of course the project manager.
This project is being worked on with one of our partners, who are leading on the project management and development so they lead the workshop.
The room
The first thing we did was set up the room before people arrived, this involved taking out the table and removing a lot of the chairs. This way people didn't get comfortable in the same positions, we wanted people to get involved and stand up and share ideas.
The workshop
Once people arrived some ground rules were laid about trying not to have more than one conversation at time, but also no idea is a bad idea. Also what the aims of the day were, ideally to have a collection of use cases that we could turn in to viable requirements.
Stage one - Aims and objective
We started off by collecting everyone aims and objects for the final solution, things people would want and like in the application.
These were then broken down in to areas they fit in to like, technology, process, people.
You can't beat a good variety of post-it notes!
Stage 2 - Actors/Personas
Then we established actors. An actor being someone who would have direct interaction with the final product. These are the people we can create persona journeys for, which will lead to the final use case and requirements.
Not all of the ones on the image below are actors, this was the initial capture of all possibilities.
Point to note: The system should be an actor, it will have requirements of it's own
Stage 3 - Journeys / Use cases
Then we moved on to creating use cases, and persona journeys. I don't have a photo of the journeys sorry!
It's important to note that these use cases were lead by the future users we invited, as they are experts in the area and have the most knowledge about the process flow.
But below is a photo of collected use cases for one of our actors. Use cases should follow a certain pattern in order to establish feasibility and importance. It's here where dependencies started to show themselves more clearly.
Once our use cases were collected they were taken away by our partners, who collated them in to a document with time scales and priorities.
Conclusion
Personally I find this to be a much better way to gather requirements, as it give the eventual users some ownership of the final product. Not only this but it means less assumptions are made by stakeholders who don't fully understand the processes for work.
Certainly on this project it saved a lot of potential development time, as out user experts pointed a vital flaw in one potential module of the system.. It has now been decided not to develop it, which will cut costs on the final product and reduce time to deliver.
Thanks for reading. Hope you found it interesting 🙂
We've recently initiated a new project and we are currently gathering requirements, without giving too much detail away we intend to implement a new mobile app for out fleet team, who maintain the vehicles and buildings used by BMBC. However, the main thing I wanted to talk about was the design thinking approach we have taken, in order to gather those requirements.
Design Thinking
Now if you've not heard the term design thinking, then where have you been! Particularly in SAP world anyway. However, if you genuinely haven't here is a great definition I found.
"Design Thinking is a methodology used by designers to solve complex problems, and find desirable solutions for clients. A design mindset is not problem-focused, it's solution focused and action oriented towards creating a preferred future" (www.CreativityAtWork.com 2016)
There are also some great resources on Open SAP, like the ones below
Our experience
Anyway a little bit about our experience in this project...
It all started off with an idea, which lead to a workshop. This workshop was essentially a design thinking work shop, and included key stakeholders in the project, including myself as a developer, future users (in design thinking it's key you have users involved in this process), data experts, some managers involved in the project and of course the project manager.
This project is being worked on with one of our partners, who are leading on the project management and development so they lead the workshop.
The room
The first thing we did was set up the room before people arrived, this involved taking out the table and removing a lot of the chairs. This way people didn't get comfortable in the same positions, we wanted people to get involved and stand up and share ideas.
The workshop
Once people arrived some ground rules were laid about trying not to have more than one conversation at time, but also no idea is a bad idea. Also what the aims of the day were, ideally to have a collection of use cases that we could turn in to viable requirements.
Stage one - Aims and objective
We started off by collecting everyone aims and objects for the final solution, things people would want and like in the application.
These were then broken down in to areas they fit in to like, technology, process, people.
You can't beat a good variety of post-it notes!
Stage 2 - Actors/Personas
Then we established actors. An actor being someone who would have direct interaction with the final product. These are the people we can create persona journeys for, which will lead to the final use case and requirements.
Not all of the ones on the image below are actors, this was the initial capture of all possibilities.
Point to note: The system should be an actor, it will have requirements of it's own
Stage 3 - Journeys / Use cases
Then we moved on to creating use cases, and persona journeys. I don't have a photo of the journeys sorry!
It's important to note that these use cases were lead by the future users we invited, as they are experts in the area and have the most knowledge about the process flow.
But below is a photo of collected use cases for one of our actors. Use cases should follow a certain pattern in order to establish feasibility and importance. It's here where dependencies started to show themselves more clearly.
Once our use cases were collected they were taken away by our partners, who collated them in to a document with time scales and priorities.
Conclusion
Personally I find this to be a much better way to gather requirements, as it give the eventual users some ownership of the final product. Not only this but it means less assumptions are made by stakeholders who don't fully understand the processes for work.
Certainly on this project it saved a lot of potential development time, as out user experts pointed a vital flaw in one potential module of the system.. It has now been decided not to develop it, which will cut costs on the final product and reduce time to deliver.
Thanks for reading. Hope you found it interesting 🙂
2 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
