Pivoting Business Analysts Tasks To Match SDLC Challenges

One of the most important skills a business analyst should have isn't given a lot of coverage in many of the books, blogs or even business analyst job descriptions. This is the ability to pivot when "Plan A" won't be effective. Most plans that are focused towards software development can be traced back to a few core Software Development Life Cycle (SDLC) interpretations.

Many times that inability to pivot isn't because the business analyst isn't familiar with various tools or techniques. A well educated and intelligent business analyst may be able to pass a certification test that covers dozens of well documented situations. However, these same analysts can adopt a single method of doing their work and blame others when it is ineffective. In some cases, others might be the root cause of the problem but a professional business analyst has to overcome those and many other obstacles to be effective.

So why is pivoting such a challenge to some business analysts? Here are a couple thoughts that might contribute to the problem. 

- The BA is not familiar with methodology an organization is using
- The organization isn't using a recognized methodology (seat of their pants or hybrids)
- The group has serious misinterpretations of how a particular methodology works
- The BA is a template zombie, set in their ways and not motivated to try anything different

Focusing this discussion on SDLC methodologies, the BA can run across one or more of the following ...

Waterfall: A phase gate approach that is well suited to traditional business analyst techniques but often doesn't produce great software in a timely manner. This approach tends to end after deployment and sustainment activities are on their own. Normally, the BA will be leveraged highly from concept to the end of the requirement phases. Some organizations will also leverage a business analyst during the design phases and others can strictly forbid it.

Agile: An iterative approach that is more challenging for a "single purpose" BA to add value. In these cases, the BA often has to be able to wear many hats. It helps if they have a development, support or software testing background. Agile "can" produce great software but can be fragile when conflict within the team arises. I'm not says that Agile cannot handle conflict but any form of team disfunction can significantly impact production. The good news for Agile is that this type of problem comes to light pretty quickly due to short iteration deliverables. Similar problems with Waterfall teams can go on for years and never be fully resolved.

Blended Environments: The most common of these is a waterfall system that has Agile iterations processes within a particular phase. The BA can work very well here, in particular if they can move from one project to the next in accordance to multiple product roadmap release cycles.

Waterfall But Not Really: This is when one of more of the stakeholders say it is a waterfall environment but their environment doesn’t adhere to a formal phase gate approval method. The BA with waterfall background can add strong value in these situations. Not only can they do the traditional BA tasks but they can help support building more formality into the organizations processes.

Agile But Not Really: This is when one of more of the stakeholders say it is a Agile environment but it really isn't. The BA with an Agile background can add strong value in these situations in much the same way as in the “Waterfall But Not Really” setting. In these cases, the BA needs to strongly support or actually adopt Agile roles such as the ScrumMaster or the Product Owner.

Blended Environments But Not Really: In other words, everyone is going rouge. The BA can add great value here, if they have strong soft skills to help empower an equally strong set of hard skills. In this case, the main project the BA has is the organization itself and this often entails an organization that doesn’t really want formal processes.

©2015 Dwayne Wright