When it comes to any project, the right tool makes all the difference.Whether in woodworking, engineering, or fashion design, having the proper tools makes things easier and more efficient. The same can be said in the world of requirements. The need for requirements tools in the world of IT product development is almost mandatory. Given Seilevel’s recent tool study, it is clear there exists a multitude of tools from which a company may choose to use. Some tools are better than others. Depending on the user, some tools offer better features or a better user experience. All of these factors help determine what is the best tool for the job.
That being said, it doesn’t matter how many tools you have in your toolbox if you don’t know how to use them.
This issue presented itself to me recently in my project work. I received an email that contained a Visio attachment. In the email, the sender presented a situation in which a model was needed for a meeting. This model needed to contain all of the user stories, their dependencies, their links to other stories, the team that was in charge of the story, and the sprint in which the story was to be delivered. All things that are common when creating a backlog for sprint.
After reading the email, I downloaded and opened the attachment. I was surprised to see a Visio document that was large, unreadable, and cluttered. My face dropped and I furrowed my brow. My initial reaction was of stunned frustration. How was I going to put together a model that contained all of these details but still make it readable to a large audience without complex explanation?
I pondered this for a few hours. I stared at the model. I thought about all the details that needed to be in the version needed for this meeting. After a while, I started to notice similarities to something I use on a daily basis. As I looked harder, it hit me.
What had been presented to me in a cluttered, unreadable, and messy model was in essence a visual representation of the requirements tool that I had been using on this project. I couldn’t help but laugh.
After that realization, I was left to wonder if anyone else had realized that the model that was being asked for already existed. The model already existed within the requirements tool we were using, but people didn’t know enough about using the tool to see that.
I don’t blame anyone for not knowing how to use the tool. But, I find it hard to understand why the people around me had not been properly trained to use a tool that is required to track such things. My frustration was with a lack of training and teaching on something that all people on the project are required to use. I’m hoping in the future further steps are taken to ensure that people are not only aware of the tools they have available, but that they are also trained properly in how to use the tools they have available.
While using a tool to accomplish a project may not always make it easier, it is very hard to accomplish anything with a tool if you don’t know how to use it at all.