Do software project teams still need dedicated business analysts? I’ve heard this debated frequently of late. Some argue that it’s more efficient for developers to collect requirements directly from stakeholders, rather than relying on business analysts. Others believe full-time business analysts are the experts at this process and can prevent a frustrating cascade of rework and cost overruns.
Who’s right? My own project management experience has taught me that it’s more important how the role is filled than who fills it. No matter what part of the team he or she comes from, you want the person to focus on understanding the business itself before trying to solve its problems.
Look Both Ways
Various forces can lead the software development team to start trying to fix problems before understanding them. Sometimes software developers themselves are to blame. They believe they understand the problem: The project is necessary because an organization is too slow, too inefficient or competitively disadvantaged, and they must create a software solution to address that. However, these project objectives alone are not actionable by someone in the role of software developer.
Objectives need to be broken down into requirements, then into designs and finally into technical development work breakdowns. To synthesize all of these into a project scope that truly meets objectives, the person charged with creating requirements first must have a detailed understanding of existing organizational processes.
Objectives need to be broken down into requirements, then into designs and finally into technical development work breakdowns.
Software developers are not always effective during this part of the process, because their skill sets and ambitions are most often rooted in creating technical solutions, rather than engaging organizational experts about how the business operates. A project manager who uses developers as business analysts must make sure that processes are documented before the team makes technology decisions or creates feature designs. If development team members can’t resist the tendency to skip ahead and focus on technical solutions, project managers should consider using dedicated business analysts instead.
Define Roles Clearly
The rush to try to solve business problems before they are understood also can originate during workshops held with stakeholders or subject matter experts to uncover and discuss existing business processes. These workshops often lack roles and guidelines. To combat this, project managers first need to clearly decide who’s responsible for documenting detailed business processes. The project manager also must name someone as the facilitator, so this person can drive the conversation toward business analysis and away from designing software and solving. Finally, guidelines for attendees in these workshops must be set—and enforced.
Challenges can arise when powerful stakeholders attend these workshops, as they sometimes neglect to read agendas or respect defined workshop roles. If a CEO attends, for example, the facilitator might not feel empowered to keep him or her from venturing off topic. Factors such as experience, power and the value of an executive’s time encourage the CEO to rush ahead of the facilitator, whose agenda is to slow down and understand problems before solving them.
Check out PMI’s new guide to business analysis, page 68.
If software developers are being used in a business analysis role during these exchanges, their desire to rush to solve a problem before understanding it might increase because there’s a rare opportunity to speak directly with influential stakeholders at such workshops.
In these instances, project managers should support the person acting as business analyst by stating workshop roles and responsibilities before the meeting. Preparing high-ranking stakeholders about workshop etiquette prior to arrival is also recommended, so they show up appreciating that projects are cross-functional efforts that progress more smoothly when all attendees forget about their position on the organization chart.
Business analysis is a critical component of any software project, regardless of who performs it. Project managers must ensure the person conducting business analysis does it correctly and without distractions. When obstacles are cleared by clarifying workshop meeting roles and empowering them to drive workshop agendas, it results in quality business process documentation. In the end, this provides a strong foundation to drive the correct software project requirements—which in turn maximizes success rates. PM
Share Your Thoughts
No one knows project management better than you, the project professionals “Getting It Done.” So every month, PM Network shares your expertise on everything from sustainability to talent management, and all project topics in between. If you’re interested in contributing, email [email protected].
| Mike Liskow, PMP, is an IT project manager at the United States Gold Bureau, Austin, Texas, USA. |
