OK, so we know that there is often a little friction, if not jostling for position between BAs & Developers on projects. After all we are both working at the same level of detail -only one looking at the business process and the other is coding. Some years ago our organisation had everyone in one happy family with little apparent friction. Then in order to control the transformation of the business areas we decided that we would pool business PMs, BAs, Testers & the programme office together. A good idea on the surface but is it compromising team integrity for projects? Any thoughts would be welcome. Saving Changes...
Mark Price PerryBusiness Driven PMO Evangelist| BOT InternationalOrlando, Fl, United States
Dear Nicola,
Should BAs and developers be in the same department..? Companies debate this and make reorganization decisions all the time. This begs the question, "have they fixed the process, or have they just rearranged the deck chairs." Regrettably, for most organizations, it is the latter. How many PMOs started as a resource pooling exercise, followed by deliberations and purchase of an expensive PPM tool, followed by training usually aligned to theory and certification rather than process and functional improvement, followed by executive exasperation and dissatisfaction, followed by PMO abandonment or restructuring? Though many organizations (and I) like to see PMs, BAs, Testers, etc. all together in the programme office, organization is secondary to the process and in many case reorganization merely provides a temporary illusion of having made real progress. Deming said it best, "Fix the process, and you fix the problem." Great post and observation. And you are right, there is often a little friction, if not jostling for position between BAs & Developers on projects. I hope we hear and learn from others.
In our organization, one key to a successful project from the client perspective (in other words, a project where the client gets what he/she wants) is open accessibility between developers, testers and the business analyst. The business analyst must be open to questions about the intended product use, the unspoken/unwritten meaning of a requirement, the functional design fundamentals... the more developers and testers understand about why, the better the product is. So, while we have separate departments for developers, testers, and business analysts, the doors are always open and people feel free to ask any question. Saving Changes...
My experience is that BAs and Developers are really working side by side to achieve the same goal, but in doing so each has slightly differing perceptions of how to reach that goal.
The BA acts as the rational voice (hopefully) of the user often advocating for more functionality, more special case handling and often, even customization.
The developer would prefer to limit scope and changes and develop special purpose code that solves all problems once. Changes which cause redesign and even trashing of code is troublesome for the developer and even frustrating.
So it becomes the project managers role to decide which changes, which functionality and in which release to make the changes in a way that doesn't prevent the developer from releasing a quality piece of software. Leadership and pragmatism are key ingredients to making these decisions. It doesn't hurt to have really good rapport with your users as well. Saving Changes...
Joseph IngemiExecutive Consultant| Price SystemsMount Laurel, Nj, United States
No
Business Analysts responsibilities include:
-Determining the customers needs
-Determining the Cost-Benefit of implementing those needs
When the Business Analysts sit side by side with programmers, they become requirements engineers. Saving Changes...
Anonymous
BA's should primarily represent the business. For most shops unfortunately that means that they perform that role from an IS perspective, but still the entire reason that the BA position evolved is because Systems Analysts always came with a system solution, and business just got fed up with having to conform to technology.
BA's should work closely with Developers because they are the business to the Developer. They are the eyes and ears for the business within the development team.
Jim - CBAPtm Saving Changes...
Joe MooneySenior Technology Project Manager| Independent ConsultantOviedo, Fl, United States
The Business Analyst is a consultant to both the user and the developers. As stated earlier, it doesn't really matter where they sit as long as they understand their role. They must be an advocate for the user and a translator for the developers. Our BAs are not in the development shop per se but we are part of the organization that "owns" the developers. I would like to see BAs a part of the PMO, as long as the PMO functions as a PMO should. BAs would then "report" to the project manager providing the PM with the views of the development and the users. Saving Changes...
PMO is probably the worst place for BA's, unless the PMO needs a BA to review their process. BA's need to plan their own elicitation and requirements. PMO's tend to have a one template fits all approach and really don't understand the BA roll. It seems to get morphed into a technical writer roll when PM's drive it. PMO should not have BA's any more than they should have any other departments. If anything the BA's should drive the PM work at the Enterprise level (Enterprise Analysis).
The best place for a BA is reporting directly to the area they are serving (Marketing, Accounting, etc...). Saving Changes...
Many BAs who have 30+ years experience have always mentored other BAs whether as part of the job or as a volunteer. Yes developers have the network to rely on, but some of the reliance is based on their need to play with new technology rather than to solve a business need. Balance is important, BAs working with Developers can resolve almost any business requirement, but neither can do so in a vacuum. Saving Changes...
Bernard GorePortfolio, Programme & Project Professional| NZ PoliceWellington, New Zealand
There's no easy answer - it is an organisational question, and often a cultural one. I've seen both options work well - I've seen (and managed) combined teams where the flow of ideas benefits the deliverables, and I've seen others where the separation of the two disciplines helps a tech-resistant client base feel "safe" from the techies! Saving Changes...
arlene trimbleAssistant IT Director| Local GovernmentAlamo, Ca, United States
I have worked in organization wherein Developers and BAs were together in the same department and it worked as it was a very high performing team. The team was very cohesive and highly productive. Chemistry was great! There were less hand-offs so work was in a stable cadence.
