LeslieJ.net :: Leslie J. Morse

Today I read, “How digital will impact the next generation of in-store shopping.” It’s articles like this that make me miss working in #eCommerce and #Retail. Although I truly enjoy the #agile and #businessanalysis coaching & training I’m doing.

The blog referenced the change of marketing from “push” to “pull” tactics and it made me wonder…

Are BA’s conditioned to be in a “Push Requirements” mode or a “Pull Requirements” mode?

Sadly, I tend to think that many BAs just do the job they are told, take requirements at face value and operate in a “Push” mentality where stakeholders spout out directives for the solutions they want. Even worse, the BAs just write it down and “push” it along to the development team before turning their back and moving onto the next project.

“Pulling” requirements is a lot harder. You have to push for the ‘Why’ and understand the true need of the business. What problem are they trying to solve? Even more importantly, what problem can you solve that they don’t even realize they have?!? Figure out that, and you’re a super-star! The “pulling” can’t stop there though. Requirements are not one-sided. The IT stakeholders are equally as important.

So, here are three tips for operating in a “Pull Requirements” mode.

• Force Divergent Thinking: Pushing stakeholders, both business and IT, to look at the requirements from different angles and discuss options and variations then opens the door for a convergent conversation. While narrowing to a set of selected requirements and preferred solution you’ll uncover hidden priorities and objectives the stakeholders have and end with a more accurate set of requirements that meet the true business needs.

• Write Requirements from the Customer’s PoV: The system shall this, the system shall that doesn’t really mean much. Whether you’re in a waterfall or agile project methodology, try out User Stories. They convey the requirements from the customers point of view and force you to identify the benefit for developing the feature the customer is requesting.

• Create Requirements Visuals: Stakeholders rarely read lengthy requirements and you never want to create a situation where the way requirements are presented shut stakeholders down. When possible create visuals that represent the requirements. Its an ideal way to facilitate the conversation and collaboration needed in order to get to input and verification.

Happy “pulling.”

Continue Reading

TechRepublic posted an article today titled, “How to find out what you don’t know.” I’m a huge fan of not only looking inward to find out, but also during requirements analysis trying to categorize information in 1 of 4 ways…

1. I Know I Know
2. I Don’t Know I Know
3. I Know I Don’t Know
4. I Don’t Know I Don’t Know

I find lots of parallels between #leadership and #businessanalysis and think BAs should purposely set aside time to study leadership principles in order to better lead from within a project team as well as leverage leadership techniques to influence organizational change.

It can be a challenge to identify what we don’t know though. It takes time, and often time is not a luxury we have. Our personality is typical confident and we’re able to present information and facts clearly in a way our stakeholders understand, but I feel it – so I am sure you feel it to…that looming fear of what you don’t know. What is the area of the scope that I didn’t even know I should explore?

Three of the main points Patrick Gray (@patgrayjr) makes in the article are perfect for Business Analysis interpretation.

Look around
Take the time to get complete stakeholder coverage. Don’t take the easy way out by working with the stakeholders at hand. Get direct input from end users if you can and try to work with individuals from different roles at different levels at the organization independently. I mentioned that as BAs we often have dominate personalities, but some of our stakeholder can take over the room and you run the risk of ending up with “groupthink“. Put yourself in the project’s shoes…if you were doing an 360° evaluation of yourself who would you talk to? This complete representation will help identify things you didn’t know and hadn’t even begun to think about.

Know the business, buy the tech knowledge
Ok, “buy” might not be the best word but…Trust your architecture and development counterparts to know the technology, your a business analysis professional. Know the business first, know the technology second. In fact, know the business first, and know your technology stakeholders even better. Those personal relationships, contacts, and connections will be invaluable. When you walk in cadence with your customer and have open and honest relationships with your IT counterparts then they will trust you to represent them fairly and the business accurately. Don’t feel like you have to be able to answer all the technical questions. Determine what is “just enough” technical knowledge and kill-it with your business acumen.

Get outside insight
At periodic intervals get someone from outside the core project team to review the work. Just like when we try to edit our own papers we read in to the text words that aren’t really present, or skim over words that are technically spelled correctly but are the wring one for the sentence. The second set of eyes will assist in identifying gaps, inconsistencies, and clarity issues. That feedback is invaluable!

To conclude I guess I will say its OK to know there are things you don’t know. Its a fact of life, it will always happen. We’re incapable of knowing everything. So hopefully a few of these ideas interpreted from Patrick Gray via TechRepublic will open your eyes and take away any fear you have of the ever looming “Don’t Know.”

Continue Reading