3 Lessons From Scalac PM On Gathering Requirements
Gathering requirements… there’s a topic! Many books and even more courses teach you how to gather requirements. The good news is – this article will not be talking about those things … not too much, anyway. Instead, we would like to share our experiences and mention one trap. That’s it, let’s go.
Story #1 Gathering requirements in the waterfall project
Once upon a time, I was a project manager on a project that, from the business side, had at least 10 departments and around 30 people involved. It was a project on core system replacement… including introducing a new web-based frontend to support the business processes of the entities mentioned above. Just to grab more context – the application being replaced had been developed and used for at least 15 years already (yeah, the frontend was based on the terminal…). Users could work with the app without using a mouse or touchpad with their eyes closed and do it faster than any modern web application I’ve seen.
Just to remind you – it was a waterfall project… there were no short, agile cycles of work delivering value. All requirements were to be gathered by a defined point in time in a single document. Having that document allowed us to get through the business analysis process, and get the technical design to the development teams.
That’s all about the background; precisely what we did and how it went will now follow.
What did we do?
- Asked the business users about their requirements
- Observed some users while they were working on the old app (and noted any actual flaws and issues)
- Prepared mockups
- Noted business specifications
- Spent tons of time discussing with all the departments involved and their specifications
- Gathered a sign-off
We started by asking users about their requirements – of course, not in general – we knew what the system was capable of (or what features it had). The first iteration of questions was about which features are still used (just to confirm what we had in the logs) and what was expected to be needed in the future. Having that information, we asked the business to show us (especially UI/UX + Business analysts) the actual use cases done in the old applications. Besides seeing how users were doing their work, we noted any usability issues in the current app.
Based on those reviews + some technical investigations, we got the list of fields (including the type of data and dictionaries). The UI/UX experts prepared clickable mockups to handle multiple use cases on a limited number of screens. After about 2 months of discussions, we finalized the mockups, ensuring all business participants fulfilled their needs. The application’s mockups and all of the technical information about data structures and use cases were merged and became a base to prepare the business specifications. The specifications were discussed a lot, really a lot, but were finally signed off.
How did it go?
+ The specifications that had mockups included were quite full and easy to understand
+ The business participants were able to use the specifications document and comment on it simultaneously, which reduced the time spent quite well
+ Workshops with the different business units were very focused, thanks to the written documentation
– The single module documentation was 1000 pages long – in the end, it was hard as hell to get to know the entire matter
– Almost every module required a business analyst just to maintain the documentation
One week after the sign-off, before even starting the service design with Solution Architects, business started coming in and changing the requirements…
And for real. The specifications that included the mockups turned out to be complete and much easier to understand than the plain text specifications. The business participants could use the specifications document and comment on it simultaneously, significantly reducing the time spent. This also allowed us to avoid some discussions taking place in the workshops and meetings, as they had already been dealt with in the comments. Anyway, we needed to have a lot of workshops completed with the different business units. However, these were well-focused, thanks to the written documentation and the mockups.
The above obviously was nice, but at the same time, there were also some drawbacks. For example, the single module documentation was around a few hundred pages long – in the end, it was also hard as hell to get to know the entire matter and to be able to answer any questions quickly. In addition, almost every module required a business analyst just to maintain the documentation.
What have we learned from this experience?
- For a complex scope that includes multiple participants, (having different expectations) -> written specifications are a must.
- If it’s about any business flow, and most definitely if the scope includes a frontend part -> mockups will help you save a lot of time
- .That waterfall projects for applications are well described by the following meme, created by Jonathan Hall:
Story #2 Gathering requirements in an agile project #1 (and the trap)
Well, this one, yes, this one was different. It was shiny and fabulous because it was agile – right, right? Agile does this better, as we can see in the image above. And honestly – yes, it did quite a good job here.
What did we do?
The project was about building a platform to sell exclusive goods wholesale. We went with the “classic” agile approach; we had a development team and a very dedicated Product Owner. There was “business” as well – as usual… 😱 The Product Owner was doing an excellent job with the product development, gathering requirements – with standard interviews + watching users doing their daily work. Afterward, the Product Owner converted those requirements into either only a story, if the feature was minor, or first into mockups (including the process flow) and a story. Later, the dev team developed and tested the solution, which was deployed. Sounds normal, yeah, it was kind of standard.
How did it go?
+ The stories did a good job
+ There were some bugs and misunderstandings (standard)
+ Business was interviewed and provided some data
– Business was interviewed, but because of time shortages or the agile approach, or maybe a lack of business standards – they did not share all cases, especially the hard/edge cases
– The above resulted in a lack of satisfaction from the business side, while doing the initial UAT and finding that some cases were not covered
So as I said – all went as expected in the agile process – by which I meant we were working on small parts of features that the business required, and we could help the company do its job. So it turned out that even an agile process is not good protection from processes that are not stable yet and are being rapidly developed. In such cases, changing the requirements often frustrates both the business and the developers.
But, yeah,… there was also a trap – something I would call a “common sense” trap. Some of the stories were missing minor details (mainly about UI and some structural things). After the development was finished, there were some issues between the Product Owner and the development team. The Product Owner raised issues about the developers not following “common sense” when filling gaps in stories and developing features. Honestly – it’s important to remember that it’s risky to trust in “common sense” in software development and that the Product Owner should ensure that stories will not have gaps.
What have we learned from this experience?
- Agile requirement gathering helps to deliver features required by businesses ;)
- Having a Product Owner with their idea of how to do things helps to avoid issues with business ideas,
- Having a Product Owner that is only a proxy (just throwing business ideas onto the development team without first checking – more on PO type here) – will bring issues, sooner or later,
- Agile requirement gathering, if not done well, will not help if the business is changing its requirements rapidly (and sees no way of changing part of a feature, instead insisting on replacing the entire solution),
- There’s no common “common sense” in software development 😉… everyone has their own, always the best, common sense.
Story #3 Gathering requirements in an “agile” project #2
Case number 3… I wanted to write something mean about this … but well, it has already been done well 😀 Boooooring… right?
What did we do?
This project was about building a non-standard application to connect those that offer a service with those that request it. Simple in theory. The approach was; mock everything up, have a great design, and then code. I would not say it was done in a purely agile way, but because the goal was to build an MVP in under 3 months – that it was not a long-term waterfall case either.
How did it go?
+ The mockups were done quickly and with excellent quality,
+ The client was responsive and ready to discuss ideas,
– The client changed his mind from time to time or revealed something that changed previous agreements,
+ The team was happy seeing the visualization of the future app,
+ Having designs ready, it was much easier to talk about user flow,
-/+ MVP took longer than 3 months to build – worth mentioning, but not because of the requirements.
The requirement-gathering process in the agreed form (that is, to build mockups) went well. All was agreed with the client, and most of it went smoothly through consultations with the team. The development of the application’s UI went smoothly and was easy to check. The backend followed quite nicely as well.
Seems boring again – right? Why am I discussing this case here?
It’s mainly because the development took longer. Mockups are great but are not enough… sad but true. From time to time, you need to have some kind of documentation that says in writing what needs to be done and what goal those given features fulfill. It turned out that some elements on the mockups were more …well, for a better look, not as a crucial feature. However, because it was not written down that those elements were out – The client assumed that “whatever is on the mockups will be in the scope.” The additional effect was that those “good-looking” features had not been thought about deeply enough and required other rounds of discussion/clarification while the development process was already in progress.
What have we learned from this experience?
- Mockups are great and do a great job,
- Putting them in the form of flow allows everyone to imagine what the process will look like,
- Scope definition cannot be done by mockups only,
- There was something else – on the border between client management and requirement gathering. Sometimes the most meaningful thing you can do for your client is to deliver precisely what he wants …. even if you know it will not end well. But that’s another story.
Summary
If you’ve read this far and are not a proofreader, robot, or my boss… I bow to you with respect…
Thanks for reading. If you would like to talk or ask any questions about requirement gathering, please ping me ([email protected]). If you have any requirements and you’re looking for someone who will know how to work with them successfully… please let me know. As I would like to meet that person as well 😂. That was a joke, of course (sorry, boss) – but we will be happy to help you gather and analyze your requirements during an on-site workshop or through remote sessions.
And as a result, you will get the following:
- A chance to meet me and my colleagues 😉
- A draft project scope document
- Draft mockups if you decide to work with them.
Ok, that’s all. Have a great day!
After reading the article on How To Gather Requirements For A Software Project, you might also like to check out these articles. Enjoy!
Authors
I am an experienced Project Manager (10+ years) who likes to organize the work, set up Jira/Trello/etc. or run meetings and engage in technical topics. I have been doing waterfall, agile, and wanna-be agile projects, probably some mutations. My goal is not to become Software Architect or CTO - I aim to understand technical details on the level that will allow me to say if those fit business needs. And that applies to all projects.
