08 February 2012 ~ 0 Comments

Push vs Pull Requirements

Push vs Pull Requirements

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?

Push vs. Pull

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

08 July 2011 ~ 1 Comment

Economist Inspiration

Economist Inspiration

Coffee Cup

Today I had the great fortune of talking to many people passionate about the BA role. It was a mentally satisfying sort of day in that regard, and for that I am appreciative.

In one of the conversations someone referenced my blog, and thanked me for the writing I had been doing. It was at that moment I shrieked inside thinking, “Oh goodness, I don’t write as much as I should.” After politely acknolwleding their praise I was asked, “How are you inspired to write what you do?” It was an easy answer, “Nearly everything.” So, perhaps that brief moment within a lovely day was enough to get me back on the wagon. I have probably 20 posts fleshed out with bullet points within the drafts of my content management system, and pink flags throughout my trusty notebook marking where I jotted down blog post ideas. It just might be the time to start writing again.

So here I am at the moment, sitting in a Starbucks in Mooresville, NC watching the rain pour (litterally) and listening to the thunder roar (very nasty). After logging on to the free Wifi I was directed to the Starbucks Digital Network and was quickly attracted towards a call-to-action for an article from The Economist titled “Back to the Coffee House” and it was within the second paragrah I found the most random inspiration…

…The news industry is returning to something closer to the coffee house. The internet is making news more participatory, social, diverse and partisan, reviving the discursive ethos of the era before mass media. That will have profound effects on society and politics.

I’m not entirely sure why my brain took that and contorted into a business analysis related concept, but it did – and here it goes. :-)

Technology projects started somewhere, right? Like back in the early days of IBM (wow, 100 yrs ago!) when companies started exploring technology projects and how they could change their enterprise…  As The Economist article stated, “THREE hundred years ago news travelled by word of mouth or letter, and circulated in taverns and coffee houses in the form of pamphlets, newsletters and broadsides. ‘The Coffee houses particularly are very commodious for a free Conversation.’” You have to think that back then it was much more ad-hoc, almost like a coffee house. Project needs travelled by word of mouth, there were no guiding tenants for project management (PMI), IEEE standards for operational exellence or SixSigma signs of efficiency and quality. There certainly were not professional authorities driving requirements analysis (IIBA).

Perhaps the advents of these governing bodies, massive PMOs, and never ending cumbersom processes some of us face within our IT organizations are a little bit like what mass media has done to the spreading of news. And this brings me to ask, what are you doing as a BA to keep your work personal and relative to your stakeholders and your organization?

Are you allowing your analysis activities to become bogged down with the feeling that you just have to put a check in a box? Or are you creating a coffee house of conversation that encourages differing opinions and offers the opportunity for the ah-ha moment of true innovation and inspiration where bright minds come together to solve the world’s (or your organization’s) problems?

Please don’t take this to mean that I am not in favor of the process that allow us to have consistency and standardization. Those qualities are very important. I simply challenge you to allow yourself to be free when doing requirements analysis. Take the time to develop quality relationships with your stakeholders (both business and IT (as “The Business Analyst’s ‘Other Customer’” on PracticalAnalyst.com so well stated)), and avoid being quick to judge. Proper solutions analysis will set the stage for solution optioning with divergent thoughts before you determine the best way to proceed and in the end you will add true value “That will have profound effects on (your organization).”

So here’s to you BAs – embrace your role, keep and open mind, be results oriented, and enjoy a cup of joe. Who know’s what inspiration you’ll find along the way.

Continue Reading