It’s that time of year again for me to make my annual predictions about the BA space. Taking to heart the lessons learned from last year, I’ve positioned these with a slightly different approach. I managed to narrow my list down to nine predictions that I’m fairly comfortable with, along with a guest prediction from a good friend. As you read through these predictions you may accuse me of waffling, but I prefer to think of it as hedging my bets.
- The number of organizations utilizing (or claiming to utilize) agile will continue to grow. Many of these organizations will adopt a WaterScrumFall (sometimes referred to as a “hybrid”) approach where they do deep dive analysis across the entire effort before handing off to a development organization that develops iteratively and then collects all of the resulting code together for a single big bang release at the end of the project. Organizations utilizing this approach may see some limited benefits in the effectiveness of the development efforts, but will miss out on the broader benefits that agile can bring. The main disadvantage is that organizations may still end up delivering unneeded or unwanted features, either because of the sunk cost that has already occurred in analyzing those features or the lack of feedback due to a single big bang release.
- Scaled Agile Framework (SAFe) originally described, incidentally, in a book titled Agile Software Requirements will continue to be the hot new buzzword for “scaling” agile. While SAFe does provide some good ideas for dealing with large programs of work (those needing between 50 – 150 people) it will continue to be misapplied in organizations that don’t exist in that context. Specifically, in organizations whose entire development department is between 50 – 150 people working on a variety of projects that are not related to each other. The good thing with this trend is that SAFe will act as a trojan horse to make the idea of standing, cross functional teams acceptable to those organizations that up to this point have organized their IT organizations using “resource pools.”
- The new PMI-PBA certification will continue to grow in popularity with the release of the Business Analysis For Practitioners: A Practice Guide and advertising out to the broader PMI community. People attaining the certificate will be a mix of people who are currently doing business analysis in an organization that places value on PMI certifications, Project Managers who have multiple other PMI certifications, and people who seek to get as many certifications as possible. There will also continue to be discussions surrounding which certification is better, CBAP or PMI-PBA. I think the answer comes down to which is valued more by the people for whom you work or would like to work.
- Some business analysts will be asked to take on multiple roles on projects, especially project management and testing.
- Some business analysts will specialize in very specific areas of analysis, such as cost benefit analysis, scoping, or IT project requirements. These analysts will sometimes, but not always, have specialized titles such as business systems analyst for those working specifically on IT project requirements.
- People with business analysis backgrounds will continue to make their way into positions where they have a broader organizational influence, although they won’t always be doing it with the title “business analyst.”
- Efforts of folks like Sarah Gibson will start to bring more attention to the need to incorporate some design thinking into business analysis activities. This is part of a broader realization that the business analysis community and the user experience community are trying to solve the same problem using different approaches in different context. Both are appropriate in certain circumstances.
- There will continue to be confusion and disagreement over exactly what the responsibilities of business analysts are, even through there are now at least three specific descriptions of what a business analyst does (IIBA, BCS, and PMI). As far as I can tell, these three definitions tend to be fairly well aligned, with some differences reflecting the philosophy of the organization. I think the real confusion comes from the way that different organizations tend to lump together a large number of different responsibilities and associate them with a role labeled business analyst. You’d be hard pressed to find a consistent set of responsibilities for a role called business analyst from one organization to another. Perhaps we could prevent some of the confusion and disagreement by focusing on the activity of business analysis instead of on the role (profession) of business analyst.
- The business analysis community will start to focus on outcomes rather than output, and ideas such as impact mapping, feature injection, story mapping, and the mobius loop will start fighting ideas such as user stories and use cases for mind share among business analysis practitioners.
Finally, I did an informal survey of business analysis practitioners for their predictions. I found it’s not always to ask people to make predictions over the holidays, but I did get one great prediction from Chris Matts: “I predict that the best business analysts will start to adopt product management techniques, even for projects that do not have external customers. In particular, the use of hypothesis based thinking which goes along with hypothesis testing as a discipline. A consequence of this will be the rise of metrics as a means to determine success rather than a binary “Did we ship?” mentality.”