BA to Developer Ratio

"Currently, many organizations have BA to developer ratios like one to six, but that ratio is rapidly increasing. With the sophistication of developer tools and the speed at which code components can be assembled, the ratio will swing toward more BAs. It takes more time to perform thorough analysis and clearly understand a business problem (and design a solution) than it does to build software. In the next couple of decades, the ratio may be much more like two to one or even three to one BAs to developers." - Seven Steps to Mastering Business Analysis


The ratio of BAs to Developers, mentioned in the Seven Steps, is evident in my current employment. Software Engineers are being given the role of Technical Analysts on major projects. Their role is to take the Business Requirements defined by BAs (both client and provider BAs in a one to one relationship) for an individual workstream and write a Software Requirements Specification.

Each TA (and workstream) is assigned a number of external (outsourced) resources, roughly around 4 or 5. These external resources use the bespoke framework system to develop a solution to the specification set out by the TAs.

Therefore, the Software Engineers are being deployed more and more in an Analyst role.

MSc Business Analysis and Consulting

Where was this course when I finished my degree!!!???

Strathclyde University - MSc Business Analysis and Consulting

OK, so when I completed my degree I wouldn't have given this course a second look, but now... yeah sounds like a good MSc.

Definitely couldn't do the Full Time course at the moment, and with work and family life the Part Time course would be difficult.  So for the moment it's a no goer.

Just need to stick to my degree and MSc.

Requirements - The Moving Target

• "There is a new version of the Requirements Document, can you check your Specification Document still meets the Requirements?"
• "The business are reassessing the requirements"
• "Some new information has come in from the business"
• "I know your SRS is due for sign off, but we still need to sign off the BRD"

Does any of this sound familiar?

Why is it that the requirements constantly change and even new business requirements come to light after the project has been completed?

OK, fair enough new legislation can come into play, but more likely than not, it is missed requirements or additional information or ideas that come to light when the product starts to take shape.

Do you deliver what the client signed off on and have a product they don't like or do you amend the requirements, implement change requests, extend deadlines and/or bite the bullet and build in the new requirements in the existing timescales?

According to Watermark Learning they say that "It seems the only constant when it comes to business requirements analysis is that things keep changing."

I totally agree, so you need to accept and deal with this as part and parcel of your role.



However, Watermark Learning think that, "Maybe it’s time to increase the requirements analysis skills in your organization with business analysis training."

Are they just trying to sell their training packages or does increased training enable the BA to extract more fuller requirements and eleviate the changing requirements?  The jury is out on this one from my point of view.



Even with increased knowledge and training, (and experience), I would still think that "the only constant when it comes to business requirements analysis is that things keep changing."  You just have to have fast reflexes and a good aim to hit those moving targets!