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.”

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.”

Upcoming Speaking Engagements Include:

• Project Summit & Business Analyst World Philadelphia
  BA Social Analyst: A Constant Student of the Art of Business Analysis
  April 2012

Previous Speaking Engagements Include:

• Charlotte User Experience 
  Lovely Creative Ladies in Tech – Panel Discussion
  January 2012 
  
• Charlotte Metro Chapter IIBA® 
  The Social Analyst: A Constant Student of the Art of Business Analysis
  October 2011
• Charlotte Metro Chapter IIBA®
  Panel Discussion
  May 2011

In the post Dorie elaborates on 5 key points in a general way, here I have borrowed her 5 key headlines for things to avoid in 2012, and elaborated in relation to the Business Analyst role.

“1. Responding Like a Trained Monkey” The take-away from the original article is about focusing on work and avoiding the triggers within society that force us to multitask (i.e. e-mail, instant messages, text messages, Twitter mentions, Facebook notifications, Words With Friends reminders, etc.). In order to do true requirements analysis (and many other key BA activities) its important to have truly focused time and attention on the task at hand. Taking time to tune-out of icons, buzzes, and chimes that plead and beg for our attention will allow us to complete higher quality work in shorter periods of time.

“2. Mindless Traditions” Regardless of the SDLC methodology your organization follows I feel confident that there are tasks you complete, documents you produce, or meetings you attend that truly add zero value. In fact, they may have a negative impact on productivity and morale. So, be a thought leader and a proactive advocate for optimizing the effectiveness not only of your BA processes and procedures, but of the overall SOPs for your organization. (Side note: I think the reference to sending Holiday Cards is a good one. This was the first year I had sent them out in MANY years and it was sort of stressful – and likely did not make much impact on the recipients of the cards.)

“3. Reading Annoying Things” My BA twist on this is really related to focusing on reading the right things. If you’re going to take the time to improve yourself, this year focus on increasing your BA Toolkit and expanding your knowledge of the many techniques a BA can use and the right situations when you should employ the techniques. This will immensely increase your effectiveness as an analyst and your street-value on the job market.

“4. Work That’s Not Worth It” Produce just enough requirements documentation that has the right level of detail at the right time and with the highest quality you can. The most important aspect of this is focusing on the true business value and benefit case of the requirements. Don’t let your project team waste time implementing requirements that are not really needed by the business and are more the wants, desires, and requests of the moments. Leverage the Enterprise Analysis skills from the BABOK® and make your IT team one that is a strategic partner for the business that only does the work that is “worth it.”

“5. Making Things More Complicated Than They Should Be” Stop the hallway conversations, skip the politics, be a transparent and candid BA that escalates risks, identifies impacts and dependencies and produces requirements that are concise, readable, testable, and unambiguous. This will avoid unnecessary complication on your projects and make everyone more productive.

Towards the end of the piece when elaborating on #5 above, Dorie references Eric Ries new book The Lean Startup and states, “developing the best code or building the best product in the world is meaningless if your customers don’t end up wanting it. Instead, test early and often to ensure you’re not wasting your time. What ideas should you test before you’ve gone too far?” I think this is important because it ties into the notion of Agile Development practices and honestly relates to more than #5 on the list of things to stop doing.

• Prototyping early and producing working software that your stakeholders can review in an iterative fashion leveraging Agile Principles helps you…
  • Avoid Work That’s Not Worth It
  • Stop Producing Annoying Things (aka Requirements) that other people have to Read
  • Escape Mindless Traditions of deliverables and documentation that do not add value to the SDLC
  • Cease Responding Like a Trained Monkey and working on all the features the business requests and starts forcing collaboration and partnership to add value to your organization

May 2012 bring you a great year of increased productivity and focus in your role!

Upcoming Training Engagements Include:

• Agile Bootcamp (learn about the Agile Bootcamp Course)
  Davisbase Consulting
  May 2012
• Building a Requirements Package
  Central Piedmont Community College
  August 2012
• Building a Requirements Package
  Central Piedmont Community College
  November 2012

Previous Training Engagements Include:

• Building a Requirements Package
  Central Piedmont Community College
  March 2012 
  
• Agile Project Management
  ASPE SDLC Training / Davisbase Consulting
  February 2012
• Agile Requirements (learn about the Agile Requirements Class)
  ASPE SDLC Training / Davisbase Consulting
  December 2011

I’m out on my own now. I left the giant Fortune® 50 company I worked for. I’m talking to small companies about potentially joining them full time and I am loving the freedom. Beyond that I am immensely optimistic about the opportunities. So for many reasons you are seeing updates to the site, and for many reasons this post from Entrepreneur Magazine was engaging and relevant for me.

Relevant in what ways you ask?

• I have to be able to clearly articulate why I left a very intriguing and growing Fortune® 50 eCommerce team.
• I have to be able to articulate what I am doing now to add value to new clients (i.e. people that can give me money so I can pay my bills).
• I can always improve the way I approach business analysis (have you noticed I derive inspiration and ideas from many verticals and disciplines?).

After reading this article, I modified Carmine’s list of four questions into what a BA (whether Agile or Waterfall) should be asking of their stakeholders.

1. What do you do? –> What should it do?
2. What problem do you solve? –> What problem does it solve?
3. How is your product or service different? –> How is it different from what is done today?
4. Why should I care? –> What business value does it add?

Please note, I did make “stakeholders” generic above. I did this intentionally. I originally wrote “business stakeholders” but I realized in fact, that the IT stakeholders are almost more important because of questions #2, #3, & #4. As a BA we know all too well that our IT stakeholders are phenomenal at telling us “how it should do it” – but are historically horrid at telling us the answers to those remaining questions (why it should do it, the problem solved by doing it that way, how we can differentiate by doing it like that). Getting the true problem statement, differentiator, and value proposition out of the IT constituents will help us as BAs convey the importance and value of more technical requirements.

The Gist of the Article
Essentially the article, “How to Tell Your Business Story in 60 Seconds or Less,” conveys the importance of entrepreneurs having the ability to clearly summarize the value proposition of their new venture to investors in under 60 seconds. It really is important. I’ve had a start-up of my own and you have to have the canned statement ready when people ask you what you do and why they should believe in/trust you. (I can assure you it was not my dashing good looks that got me contracts when I was a geeky college student with a web development company.)  You almost have to have the story embedded into your DNA, its like having a tape recorder as a part of your voice-box and when someone asks you, you just hit rewind and then play again – spitting out the same paragraph over and over again. Carmine does a good job of emphasizing the importance of this, and offers a good suggestion for summarization (as noted in the list of 4 questions above).

The General BA Tie-In
I can’t tell you how many times I have spaced out listening to a stakeholder. And less attractive for me to admit, I don’t even want to imagine how many times people have spaced out listening to me talk about a requirement. (Notice there is no “s” on that – I truly mean a single requirement.)

If you, as a BA, cannot articulate the intent and benefit of a requirement in less than 60 seconds then you’re not doing the best job you can do.

• You won’t be able to effectively communicate with your executive sponsors or executive management if they ask about it. (Communicating at ALL levels of the organization is a paramount skill to possess.)
• Your developers will tune you out when you start talking. (They want direct, concise, to-the-point explanations of what they need to do/why they need to do it.)
• Your business stakeholders will likely perceive you as overly verbose. (They need the confirmation that you “get” what they are saying, what they need, and that you can articulate it for them. Not to mention, if you don’t elicit all of this information from your business stakeholders you are not doing your job,)

The Agile Tie-In
Requirements in agile are most often depicted by User Stories. They are a STORY – using the guidelines from this article allow you to frame up the majority of the information you need to convey within a user story, help you partner with the  product owner in order to understand true business value, and tell a story about the feature/capability of the system.

User Stories are also meant to foster the conversation. Remember, agile is about “conversation” not “documentation” – so internalizing these key benefits from an elevator pitch along with the primary aspect of a user story (actor, action, benefit) you can nail the communication during daily scrum sessions when team members have questions and you can succinctly summarize for team members during story review and story grooming sessions. The quickness of the conversation is also important. Iterations/Sprints are meant to be short, and very moment is valuable as you want as many minutes available for producing working software as you can get. The more concisely the requirements can be articulated, the more efficient the team, the higher the velocity, and the more business value gained.

Lastly, the User Stories should (if at all possible) be articulated from the end-user point of view. Asking these questions will get you to that level of detail and allow you to spin something around to showcase business value and benefit.

More context to come on my recent professional transition, for now I leave you with a note wishing you Happy Holidays!

The conversation I am about to recap for you is a likely sign I am thinking a little too much about work.

Some History
The IT team I work with converted from Waterfall to Agile in January of this year. We are in the process of wrapping up operational enhancements that we call “Agile v2″ in the hope that we can address some of the gaps in the processes we rolled out at the beginning of the year. This has meant countless working sessions, process flows, and debates on the good - bad – and ugly of the way the teams have been doing theirwork. It has also meant receiving Agile-Purist advice from our Agile Coaches as well in order to help us keep true to the methodology we are committing to.

Last Night’s Conversation
As my husband tells me, in the middle of the match I started trying to explain to him that boxing was like agile software development. It probably went something like this…

Me: (picking my head off of pillow) “Hey, ya know, agile is sort of like boxing.”
Him: “What?”
Me: (sleeping)
Him: “Honey, did you say something?”
Me: “Huh? Yeah…Agile. It’s sort of like boxing.”
Him: “What are you talking about? Just go back to sleep.”
Me: (somewhat incoherently) “No, it’s true. Agile is like boxing because…[something nonsensical]”
Him: “Sweetie, you’re half asleep. You’re not making any sense.”
Me:(somewhat belligerently) “I am not sleeping, they really are similar because… [something nonsensical]“

There were probably some pretty significant pauses between my rebuttals and it probably continued on for several more rounds. This morning we got a good laugh about it, and he was convinced I was completely out of my mind. But of course I couldn’t stop thinking about it, and once I drew a parallel in my head I had to try and convince him that Agile and boxing really are similar. My rationale was that like agile…

• Boxing has rounds (similar to sprints)
• During the breaks between each round they talk about how it went (a retrospective)
• Before starting the next round they talk about what they should do (sprint planning)

Very simplistic, but at least amusing – and very likely I’m in need of a break from the office.

Back in the days of Justinsane Design, my Web Development start-up from college, I started collecting fortunes from fortune cookies. They were originally taped to the frame of my iMac monitor, and once I switched computers they moved to a hot-pink sheet of construction paper. Over the years the fortunes started hanging off the edge and they were accumulating in a folder so I decided to get a little crafty and preserve them for display.

Maybe I’m lucky, or maybe its simply a coincidence, but I tend to get good fortunes. Not only good ones, but relevant ones. For example, one reads: “You will do well in the field of computer technology.” Yeah, go figure.

Recently I was adding some more fortunes to the frame and as I was scanning through everything on the board I realized lots of them can be applied to the work I do, so tomorrow I will kick off “The Fortune Series” – a set of posts inspired by the fortunes on my wall.

We decided to go a bit off-topic for the late-summer gathering. Why read another BA book when we could read something about one of the most fascinating companies around these days? So, here it is:  “What Would Google Do?” by Jeff Jarvis. I will be taking a participants view for this discussion and turning over the reins to Reid Parker, one of the CLT BA members. I look forward to his facilitation of the discussion. (Get the book on Amazon now.) The discussion will be on Thursday, August 11, 6:00PM. Light Dinner & Beverages will be served. Thanks again to ettain group and Macquarium – our gracious sponsors!

REGISTER NOW!

I thought there were two really strong take-aways for the business analyst.

Make Your Thinking Process Visible
When in requirements elicitation or analysis sessions its extremely important to ensure all stakeholders are on the same page (and even more important when it is a sensitive subject or something people are passionate about – as the article references). The last thing a BA needs is for people to walk away with their own version of understanding in a situation.

In order to eliminate any confusion try out:

• A process flow that outlines your personal decision making / analytical thought process
  • Include the key decision points in the flow to show that you covered a variety of possibilities and angles on the situation
  • Tag possible outcomes with an ID
• A clear list of the inputs that influenced your decision making
• Grid out the affected stakeholders with a column for each possible outcome to clearly illustrate how each is impacted by the options

Use Past-Tense Questioning
As the article references, this can get stakeholders to change their perspective and analyze a situation as if they have already completed the work. This can also be an effective way of evaluating already identified action items during the session in order to ensure the list of to-dos are complete and accurate. This is a technique I’ve never tried before, but am looking forward to giving it a go.