Posted by Special Guest Contributor – Ginger Nedblake
A few months ago, I started a strength training class with a trainer, Mandy. Twice a week I submit myself to her will in the hopes of achieving my fitness goals. And from my very first meeting with her, I realized that my job of requirements analyst and her job of banishing flab have many similarities and that she has some skills I can use in my job.
Here is what I have learned from her:
Keep the Goals in Mind
At our initial meeting, Mandy asked me to fill out a list of goals – the why of what I was doing. Being a responsible requirements analyst, I knew my goal couldn’t be to “get in shape.” My goal, or high-level functional requirement, had to be measurable.
There ended up being six goals for my fresh attempt at fitness. I printed copies of my goals and look at them whenever I don’t feel motivated, such as when I am about to choose working late or going to dinner with a friend over going to Mandy’s class.
I have seen too many projects where we come up with our high-level scope requirements for a project and then dutifully archive them and never look at them again. It would be much more useful to review those goals before every project review or discussion. In addition to helping with focusing attention or determining if a project change is scope creep, reviewing the goals can remind us of why we are doing the hard work.
(And with a nod to the project managers out there, when looking at my goals doesn’t motivate me to go to class, I look at how much money I would be wasting if I didn’t go – the per class price. And then I go.)
Be Tough and Be Kind
I simultaneously adore and loathe Mandy. I loathe her for all the obvious reasons. She is cute and blonde and she makes me do 50 standing lunges with 12-pound dumbbells. That is to say, she is evil.
But the reasons I adore her are much more numerous, and I have learned a lot from her when it comes to interpersonal communication as motivation.
- “ Yes, I need you to do that.” When someone asks “Do I have to…?”, Mandy says yes. She always says yes. If it is written on our exercise sheet for the day, we have to do it. She knows the reason the exercise is there. Many requirements analysts would benefit from the same quiet confidence. If a requirement has been elicited, written, reviewed, and approved, it needs to be done even if it is hard, even if the technical team has sore muscles or didn’t get enough sleep, or even if it pushes the system limitations.
- “You can use bigger weights.” When Mandy sees that someone isn’t pushing hard enough, she makes her switch weights. She wants us to get the most out of our repetitions, and quickly determines when we can do more. Many requirements projects would benefit from that same time-benefit analysis. Reviewing the requirements and goals of a project to ensure that when we touch the code, we are making the most strategic, beneficial changes and that we are pushing ourselves.
- “Good work.” Mandy always compliments us on the work we have achieved. She notices the small improvements as well as the big changes. The small kudos are very motivating to me. Acknowledgement that what I have done is tough, even if it is a small task, pushes me to do more. Technical teams and customers are motivated by the same feedback. Even the most hardened software engineer appreciates positive feedback. Whenever a developer has shown me something he or she has done, I always find something positive to say, even if they are just doing what the requirements told them to do:
- “Thanks for showing me that. This is really going to make the customer love it.”
- “I know adding that field was tough, but it looks great.”
- “It is so cool to see that requirement come to life. Thank you!”
It seems cheesy, but I honestly think those daily affirmations make for a better relationship with the technical team. And, I have seen evidence for this hypothesis with my experience with Mandy. Even as I roll my eyes, I appreciate her recognizing the effort.
Remember the Safety Requirements…First!
When helping teams with their requirements process, I often am asked to explain the goal or use of a hazard analysis. Requirements analysts do not always understand the purpose of declaring the safety requirements up front and tagging or storing them in such a way that they easily can be identified as the safety requirements. This is seen as just another administrative task.
The software we develop is tightly regulated; we are required to identify our safety requirements, but in addition to meeting the regulatory standards, the practice helps to draw attention to your critical requirements, ensuring that you don not design or code software that could cause injury, death, or financial loss to the client. And these safety requirements need to be defined early in a project and reviewed often.
Mandy never forgets the safety requirements. In a room full of ten women doing ten different exercises, she can quickly point and say, “Cindy! On this one you are going to want to use lighter weights so you don’t hurt your elbow.” She seems to have some sort of sixth sense about preventing injury, and she keeps in her mind the past or potential injuries of all the women in all of her classes. It is quite something to behold. I would love to see requirements analysts storing all of the safety requirements for a project or product in their mind and recalling them immediately to ensure that there is no harm.
