In a small business, people often wear a lot of hats. The same thing can happen on small- to medium-sized projects. One person may end up filling multiple roles – product owner, business analyst, tester, and sometimes even developer.
On our recent CRM conversion project, I ended up playing several of these roles. I frequently hear from students who are asked to be both the product owner and the analyst on their projects. That has its challenges, so I wanted to share some of my experiences and recommendations.
Let’s start off by reviewing common responsibilities for the product owner and analyst roles.
Figure Out Who Does What
I want to preface this by pointing out that role definitions will vary from organization to organization, and even from team to team.
The key point here is to make sure you have a handle on exactly what is expected of you. For more on defining roles and setting expectations, check out our blog Don’t Drop the Ball! Define Your Team’s Collaboration Model.
Plan Ahead to Address Gaps
Even though you’ve been assigned to both roles, it’s unrealistic to expect that you will be able to handle all that work with no outside input. Once you’ve identified what you’re responsible for, you will undoubtedly discover that there are areas where you lack knowledge or expertise.
I’ve worked at B2T for over 20 years now. It would be easy to assume that I’m knowledgeable about everything in the business. And to a certain degree, I am. But I didn’t know enough about every aspect of the business to develop all the CRM requirements myself. A case in point here is our certification program.
I understand the fundamentals of how it works. You need two badges to reach BA Associate. Four badges are required for BA Certified. Each badge requires two or more classes. Easy, right? Sure, on the surface. I understand “what” the system does. It’s described very succinctly on our website:
Unfortunately, I didn’t understand “how” it worked and I needed to get to that level in order to support the data conversion effort. In reality, under the covers, the data model is pretty complex.
Spend time at the beginning of your project work to identify areas where you have knowledge gaps. Then find a way a way to address each knowledge gap you’ve identified. The sooner you begin asking for additional resources, the more likely you are to have them available when you need them. The key is to be focused and specific. Don’t ask for help with everything or with the things you can do on your own. Only ask for help with the areas where you really have a gap. In my case, I didn’t want to say, “I need someone who knows the old CRM”; I wanted to say “I need someone who can walk me through the custom data structures in the old CRM”.
What if you have a gap and don’t have a good way to address it? Then that becomes a risk that needs to be raised with the team.
Remember Your Audience
When you’re acting as both the product owner and the analyst, it’s easy to fall into the trap of writing requirements that make sense to you…but that may not be clear to others. Some keys:
Check Your Level of Detail
Remember that a requirement is a “usable representation of a need”. The challenge is that “usable” is very dependent upon your audience.
If you think about it, a grocery list is a list of requirements. Depending upon who in my family is going to the store, the list would take one of these forms:
Me: Half & half
My husband: A pint of half & half
One of the kids: A pint of store-brand half & half; make sure it’s not fat free and doesn’t expire for at least two weeks
Think about anyone else who will need to use your requirements – developers, testers, etc. – and make sure that you’re providing enough detail for everyone in your audience. And remember that a usable representation doesn’t have to be words. Sometimes a diagram or a picture is ideal. Admit it: you’ve texted someone a picture of what you want from the store instead of trying to write it all in words, haven’t you?
Clarify Terminology
Yes, I really am going to bring up the glossary. If you’ve been in class with me, you know how important I think a glossary is. I really do hand out gold stars to students who remember to define key terms.
We spent an inordinate amount of time on our project correcting usage for two terms. There is a difference between what we call a “certificate” (proof that a course has been successfully completed by a student) and a “certification” (achievement of a specific designation in our BA certification program). Those of us who’ve worked at B2T already know this. The consultants we brought on board? Totally confused.
Remember that if you use terms like these in your requirements, and people don’t have the correct definition for the term, then they don’t have a true shared understanding of the requirement.
Reviews are Critical
Another easy trap to fall into: being your own (and only) reviewer. I’ll admit that I fell into this trap. We had a limited amount of time and so I started passing “finished” requirements over to the developers without running them past other folks on the team.
We ended up doing some rework because of this. In one area I made the cardinal mistake of basing our “to-be” state on our “as-is” state without checking for pain points and opportunities. This goes back to identifying your knowledge gaps. I didn’t identify and address my knowledge gap around billing and invoicing, and I initially didn’t ask our business manager to review my requirements in those areas. We had to go back and modify some customizations because I was unaware of some “edge cases” that complicated our invoicing.
You can bet I learned my lesson. This is a particularly important reminder for people who are developing requirements in an area where they used to work. Things change…and what you know about the business from your time working there may no longer be complete and/or correct.
The Silver Lining
It’s not easy to wear a lot of hats at once. Sometimes I felt a little overwhelmed and nervous because it seemed like everything depended on me.
On a positive note, this was an opportunity to stretch myself a little. It’s been quite some time since I’ve done development work. It was fun to dip my toes back into that, particularly using some newer technology. It also helped me learn more about areas of the business where I wasn’t an expert. Just remember the keys: know what you’re responsible for, identify your gaps, and proactively look for ways to address them.
Best,
–K.
Kathy Claycomb
Managing Partner, Lead Expert
Kathy Claycomb brings over 35 years of experience to the classroom. She has participated in all phases of solution development using everything from agile to waterfall methodologies (and quite a few in between). Before joining B2T, her career spanned roles from application developer to Senior Director of Services at various organizations. Kathy has broad industry background including transportation, manufacturing, insurance, energy, healthcare, and banking.
Kathy’s first love is teaching, and throughout her career she has always managed to spend a portion of her time instructing. She has an engaging, highly interactive teaching style that ensures students leave the course with a thorough grasp of the material. Her students consistently praise her teaching abilities and her talent for drawing on her personal experience to enhance their learning.
Kathy served as the Technical Editor for Business Analysis for Dummies, 2nd Edition.
