BobtheBA here taking a look back at 2011 before we get too far into 2012 where we will boldly go where BA’s have not gone before! The New Year, a time of renewal and promised change. And generally speaking it is the only time when all creatures on this planet embrace change, but unfortunately not in a sustained fashion (more on this in my next blog as we look forward to 2012). For now let’s take a brief look back at 2011 from the world we live in to the world we work in. There was much to celebrate, mourn and marvel at. Was it a good year for you?
Requirements Analysis Posts
2011 BobtheBA and A Quick Look Back
Posted: January 9th, 2012 by Bob Prentiss. Comments »
7 Trends in Business Analysis and Project Management to Watch for in 2012
Posted: January 9th, 2012 by ElizabethLarson. Comments »By Elizabeth Larson, PMP, CBAP, CSM and Richard Larson PMP, CBAP
The close of one year tends to make one reflect on what has occurred in the past year and ponder the future. Here we ponder some trends in the Project Management and Business Analysis fields for 2012. Here are our top seven predictions for business analysts (BAs) and project managers (PMs) in 2012.
1. Divergence of the PM and BA Role. In 2009 we predicted that as the economy tightened, organizations would decrease their project budgets and combine the role of PM and BA. For 2012 we believe that organizations will see the need for both roles, particularly on strategic projects, and move away from a combined role. There are several factors for this trend:
Scrooged!
Posted: December 6th, 2011 by Bob Prentiss. Comments »
Scrooged!
“Bah humbug!” Well at least that is what it sounded like to me (BobtheBA) at the time, a few Christmases ago. And all I could think of was “What a Scrooge!” So what’s the story that brought out the worst in two people during the holiday season? Well before I tell you this true story just know that this person and I are close friends and I do have permission to tell the story (we laugh about it a lot now).
Why Spend Time on Use Cases in Agile Projects?
Posted: December 2nd, 2011 by RichLarson. Comments »
Someone at a recent conference asked me how to respond to project stakeholders when they say that Use Cases take too long in an agile environment. I was presenting a talk on “BA Toolkit for an Agile Project (or any other for that matter).” Here are my answers with some added depth. (Thanks to Justin Roebuck for the great question.)
Turning Requirements Trash into Stakeholder Treasure – Part 2
Posted: August 23rd, 2011 by Bob Prentiss. Comments »
Hello all – BobtheBA here and when we last left off we were exploring how innovation can be key to turning requirements trash into stakeholder treasure. The scenario we were exploring was a difficult stakeholder that was not forthcoming with their requirements. Your job (should you choose to accept it) was to improve your 1:1 interview process through innovation by looking at it through different eyes like those of a hostage negotiator. It may yield a different result or help you to be more prepared than what you thought possible.
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?
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?
Scenarios and Use Cases – Useful Techniques
Posted: July 9th, 2010 by RichLarson. Comments »In continuing to cover all 49 BABOK® techniques, this entry is about scenarios/use cases.
UC Diagram-Training Example
Since most people refer to these as use cases, that’s the name I’ll use. They are a great way to elicit, analyze, and model interaction requirements. Plus, they help generate related requirements for interfaces, data, process, and business rules.
I gave a use case training class last week, so it’s fresh in my mind. It also influenced me to put this explanation in question and answer form.
Q. What is a use case?
Data Modeling – Why is that Technique in the BABOK?
Posted: May 12th, 2010 by RichLarson. Comments »(In my continuing coverage of BABOK® techniques, I plan to comment on all of the general and task-specific techniques. This week’s entry is about data modeling, a technique you may or may not be familiar with, but a sure source of CBAP® exam questions.)
The impetus for this blog comes from having just taught a successful training class in Data Modeling to a mixed group
of BAs, BI specialists, technical architects, and business SMEs (subject matter experts). What made it successful was not only the learning that took place, but also the students’ willingness and eagerness to apply this technique back on their jobs.
Five Tips for Estimating Requirements
Posted: February 10th, 2010 by ElizabethLarson. 2 Comments »Years ago I worked on a large effort to reengineer a distribution
center for a large retailer. We provided an estimate for both the business analysis work and for the entire project, which would involve the organization’s first use of Electronic Data Interchange (EDI), new business processes, many software changes, and the purchase of new barcode scanners. The business analysis effort took far longer than we anticipated, and at the end of it we refined our estimate for the total project. When we reported the new estimate to the president of the company, he literally pounded his fist on the table and asked, “How did we get to this point? Why didn’t we know sooner? You’ve already spent all this time on the project and what do we have to show for it? Nothing!. Absolutely nothing!”
