I came across this article that discusses why having both a Project Manager (PM) and an Analyst is important on a project. It goes into great detail about differences and similarities between the two disciplines and it's a pretty good read.
It reminded me of the presentation I give at Ascentium Boot Camp (what we call New Hire Orientation) so I thought I'd share a somewhat lengthier and wordier version.
I am a Business Analyst (BA) and I think Analysis is the Center of the Universe. Analysts are generalists and because we are, there's often overlap between Analysis and nearly every other actor on a project.
Business Analysts (BA) often follow a career path toward Project Management because of the overlap in skills and goals; managing customer expectations, being a big one. The line where PMs end and BAs start is blurred because it varies from one match-up to another. Despite the duality, there is one key difference between Project Management and
The overlap doesn't have to be redundant because each discipline serves to balance the other out. Managing to the overlap is what is important and that can only be accomplished with communication. When a project kicks-off, it's critical to project success to clearly define the responsibilities of the PM and the BA. This identifies the overlap and the gaps so each can fulfill their roles effectively and efficiently.
The same holds true for BAs and Information Architects (IA). I sometimes hear, "We don't need a IA on the project because we already have an BA." While many of our skills are the same, it is critical not to confuse similarities with being substitutes for each other. We have similar deliverables from workflow diagrams to annotated wireframes but while a BA may define a workflow, an IA may consume it and translate it into a user experience. An IA may create a wireframe but a BA may annotate and extend it.
We may both participate in user interviews but we are listening for different things. This article distinguishes the two disciplines by saying, "Business analysis provides the who, what, and why. Information architecture explains the how." BAs have the same kind of relationship with IAs and BAs have with PMs; BAs are still advocates of the Business Requirements but IAs are User advocates.
BAs push for things the Client needs through Business Requirements but our Clients aren't always End Users of a system. IAs concentrate on user-centered design and must speak on behalf of the End User to ensure his needs are met. The Client may not realize it, but User needs are Requirements, too, because without User Adoption, the solution we build will not be successful. And when the product is not successful (everybody now), the Client is not successful and, therefore, we are not successful.
The relationship between Analysis and Development is less confusing than the the other relationships I have described. Analysts don't write code. It's pretty simple; except when we do actually write code. I've been known to crank out some HTML and CSS in a pinch but anything beyond a little ASP.old and VBA and I'm lost. Some of our Ascentium Analysts used to be Developers and they may no longer break open Visual Studio (except for TFS), but they use their historical experience to talk with Developers. Even the Analysts who were not Developers are often technically savvy and can hold our own in a technical discussion.
And holding our own is pretty important when it comes to working with 733+ Developers. There is a push and pull between Requirements and how (or IF) Technology will satisfy those requirements. In these
Armed with knowledge of Technical constraints, trade-offs, and alternative options, analysts often translate between the Client and Developers.
Sometimes, Analysts serve as Customer Proxies and make decisions on behalf of the Client because both Clients and Analysts have the goal of solving business problems. The business problem to solve, however, can differ between us. Clients may understand the business problem one way or may understand a piece of the problem but not how it fits into the overall strategy of the roadmap or the business. They may envision a solution but not consider its impact. Sometimes, Clients are just too busy; they just know they have a problem and they need Analysts to figure it out.
In many ways, Analysts are just playing devil's advocates so we can bridge the gap between a long-term strategy and meeting immediate needs. Who is arguing which side will vary but we work together to distinguish the difference and prioritize features.
Requirements can get hairy. Technical Requirements may conflict with Business Requirements or User Requirements; and User Requirements may push the bounds of Budget Requirements. It's the sorting through the tangles that Analysts really shine. Anyone can do it. Analysts are just GREAT at it.
Analysis is about problem-solving. It is about understanding, communication, and facilitation. We analyze to understand the project, the business problem, the users, and the technology solution. We grease the wheels between the cogs in the project machine by collaborating and communications with our colleagues. Most importantly, we facilitate the conversations and negotiations between disciplines to manage expectations.
Managing expectations isn't just about what the end product will be. Project health is dependent on clear expectation among team members. Define roles and responsibilities between disciplines on a project. Bridge the gaps. And embrace the overlap.
-Ann
Senior Business Analyst
No comments:
Post a Comment