The end of one year and the beginning of the next brought with it a slew of posts covering the top trends for just about every field. I’ve run across three so far, all of them providing a different perspective, some I agree with, some I don’t. Regardless of my thoughts, they deserve reading:
- Glenn Brule’s Top Ten Business Analysis Trends for 2012.
- Elizabeth and Richard Larson’s 7 Trends in Business Analysis and Project Management to Watch for in 2012
- Angela Wick’s The Top 10 Business Analysis Skills for 2012
I wanted to include my thoughts in the trends discussion, but instead of responding to what others had to say, I thought I’d add my own shot across the bow. So without further ado, ten things (in no particular order) that business analysts should pay attention to above and beyond merely eliciting and documenting requirements.
- Strategy – understand your organization’s strategy so that you not only understand what job you are trying to get done with your project, but also whether that job is actually worth doing for your organization. You can tell that through an understanding of how that job relates to helping your organization build and maintain a competitive strategic advantage.
- Your organization’s Business Model – who are your organization’s customers? Who are your organization’s suppliers? How does your organization add value? How does your organization generate margin? What are the strategic barriers you put up to keep your competitors away from your customers? Where does your project fit into that picture? This works for non profits as well, by the way.
- Risk – Yes, business analysts need to concern themselves with risks. Particularly those business risks my friend Todd Little likes to call collateral damage – what unintended consequences will completing that project have on other parts of the organization?
- Data – Data modeling is not just for DBA’s any more. Data modeling is a great analysis tool for understanding your business. After all most business systems are all about taking some sort of information in, doing something with it, and spitting it back out. Modeling that data helps you to understand what data you need and what that something is that you need to do with it. Just because your company has data modelers does not mean that you as a BA do not need to know how to work with data as well.
- Politics – not the donkey and elephant kind. (Democrats and Republicans for those of you not in the United States) but the power struggles that (unfortunately) go on in companies of any size and that often show their ugly head in project decision making. Try not to get directly involved in the politics, certainly do not exacerbate them, but do know what they are, and how to prevent them from sidetracking your project.
- Testing – as a Business Analyst, you should be testing. It’s a great way to find out what impact your analysis work has on the rest of the team. Testing is also a great way for you to figure out that communicating via examples is probably the best way to share requirements information. This approach is frequently called Specification by Example.
- Customer Development – Yes, Lean Startup may very well be the business equivalent of Tim Tebow or Linsanity, but there is a lot of validity to the concept, especially the bit about Customer Development, which you can think of as the stuff you should be doing when you don’t understand the job to be done.
- Technology – Can we stop the inane arguments about whether BA’s need to be “technical”? If you are truly performing a business analysis role, you are trying to figure out how to solve a problem with a given tool. Experience has taught me that you should at least be conversant with what the tool can do before you determine whether it is appropriate for the job. As a BA on software project you should be at least familiar enough with the technology to know what is and is not possible, and to also know when someone is trying to feed you a line of bull. Do you have to be able to code C#? No. But being able to read it can certainly be helpful.
- User Experience – Even though you wouldn’t hear user experience folks say it, they do a lot of the same type of thing that business analysts do, but they have a much more defined focus on the people who actually use the things we’re trying to create. These two communities like to wrestle for attention in the software development world, especially the agile community, but we really should be working together. There’s a lot we can learn from each other.
- Product management – You don’t hear about too many business analysts working on software products (those sold directly to end consumers) but there are people doing business analysis on those projects. They call themselves product managers, and they would vehemently deny that they are in fact doing business analysis, but they are. They too have a much better focus on the end customer when they do their work. There’s a lot we can learn from them as well.
This list may be a little self serving, but let’s face it, all of these lists are a wee bit self serving in that they try to push forward the author’s agenda. There’s certainly nothing wrong with that as long as the reader is aware of why the trends noted are important to the author. In my case, I want to emphasize the fact that business analysts need to think about things way beyond requirements in order to be successful. With the list above, I wanted to point you in some directions to start that thought process.