Hello all – BobtheBA here. Sometimes we can be inspired by the littlest things like a bee, a mosquito, or a play on words. Such was the case for me last month in all three examples, where the last of which I was inspired by one of my students who accidentally substituted “illiciting” for “eliciting” during a class exercise. We all knew what was meant and in class spelling does not count (which is the beauty of it happening during training – a safe environment!). However, in that moment I was immediately drawn to the concept of illicit requirements and what that might mean. Illicit is an adjective meaning “contrary to accepted morality or convention”. Is it possible to have requirements that do not fit accepted convention, i.e. “illicit” requirements? Absolutely!
Posts Tagged ‘business analyst role’
Illicit Requirements
Posted: April 19th, 2011 by Bob Prentiss. 2 Comments »
The Art of Business Analysis War
Posted: March 8th, 2011 by Bob Prentiss. Comments »
Hello all – BobtheBA here to briefly talk about strategy. Business Analysis? War strategy? What do these two things have in common? Surprisingly a lot. It is very important to plan and manage your requirements effort but more importantly it is how we deal with the moments in-between the tasks and deliverables that truly show the art of business analysis. Planning and Managing your requirements may be new for you and if it is not, you will know how difficult this can be. Training may be in your future to help out in this area. In the meantime, why don’t we get some inspiration from one of the definitive works on military strategy of all time?
Assumptions are Project Killers!
Posted: February 8th, 2011 by Bob Prentiss. Comments »
Let me be candid and up front – I do not like assumptions. Never have, never will. I truly believe that they can be one of the most destructive forces in business analysis. I do not like them here or there. I would not like them anywhere. I do not like them I believe, so make them go away and leave! (Thank you Dr. Seuss, you always inspire me). So why is BobtheBA all jacked up about assumptions? Well… let’s just say he has first-hand experience with the pain they can bring. Now even though I do not like them I will also recognize up front that they are a necessary evil. Notice I said evil.
Notice Everything For Greater Success
Posted: January 7th, 2011 by Bob Prentiss. Comments »So we have all heard of the saying “the devil is in the details”, right? But what does it really mean? This idiom actually derives from an earlier phrase “God is in the detail” which expresses the idea that whatever you do should be done thoroughly; i.e. details are very important. When it comes to business analysis that could not be a more true statement. Missed details = miss requirements = missed functionality = less value to the business. It all makes sense on the surface, but how does one actually ensure that details are not missed?
Make No Mistake That Was a Missed Opportunity!
Posted: November 18th, 2010 by Bob Prentiss. Comments »
I have often heard that BAs make “common” mistakes. Perhaps it is just an unfortunate choice of words (or perhaps my glass is always half-full), but I personally believe that we should focus less on the negative and more on the missed opportunity. So what are missed opportunities? Missed opportunities are generally considerations or course corrections that were not accounted for in the business analysis approach. We should remember that there are a million and one ways to slice, dice and do business analysis. Business analysis approaches on projects are not one size fits all nor are they ever the same. The business analysis approach is dependent on the expertise of the BA and influenced by a number of things that includes real-life experience, training, stakeholder influence, size and complexity of the project, standards and corporate culture. So what are some of these missed opportunities that BAs should take advantage of?
Business Analyst + Leadership = Success!
Posted: August 12th, 2010 by Bob Prentiss. Comments »
Hey BAs – stop taking notes and start leading!
I have taught for years that Business Analysts must be leaders (not just note takers) and I have to admit that I have not always received the warmest welcome when I delivered that message! And what is up with that? Isn’t it obvious that project success will increase? Increased collaboration with your stakeholders? More control over what you do on a daily basis?
Is the BA a Product Owner or Tester On Agile Projects?
Posted: August 3rd, 2010 by ElizabethLarson. Comments »
There have been many articles lately about the role of the BA on Agile projects. Some postulate that the BA role is closest to the product owner. After all, it is often suggested, they reside with and represent the business. They are in the best position to be the final voice when defining and prioritizing requirements. Others believe that the key role for the BA on Agile projects relates to testing. Since they define the requirements, they should complete the appropriate testing processes to ensure the final solution meets the requirements. I believe that neither of these is a business analyst role. That’s not to say that someone with the title of BA cannot play other roles as well. It’s just that when they are playing these other roles, they are not doing business analysis work.
Should Business Analysts Model Requirements?
Posted: April 8th, 2010 by ElizabethLarson. Comments »During a recent client visit I encouraged the use of modeling as a way to uncover hidden requirements and expectations. One of my clients expressed her rather strong opinion that modeling requirements was not and should not be a part of business analysis work. Oh, she could accept the fact that uncovering gaps between the “as-is” and “to-be” using process models made some sense, but she was adamant that this gap analysis should be done by a business Subject Matter Expert (SME), not by a business analyst (BA). As to data modeling, well that was technical in nature and if done at all, she said, it should be done by the technical IT staff. Use cases were helpful to the testing staff, but were clearly technical and were not to be done by BAs. Prototyping? This should be done by developers—no question about that one!
Four Tips for Avoiding Conflict Between the PM and BA
Posted: March 10th, 2010 by ElizabethLarson. Comments » 
At a recent conference I sat next to a project manager who observed, “My organization hired a new consulting company to do business analysis work. They’ve completely taken over. Now they do a lot of the project management work that I used to do, such as meeting with the sponsor to uncover the business problems, determining what we’re going to do on the project…I can’t believe it! I feel like I’m being treated like a second-class citizen!”
Where We Were in 2009 and Where We’re Headed in 2010
Posted: February 2nd, 2010 by Lorna McMillan. Comments »How did the role of Project Managers and Business Analysts change in 2009? What might happen in 2010? Check out this latest article by Elizabeth Larson and Richard Larson at BATimes.com: http://tinyurl.com/yeq2wmg.
