Enter The Business Analyst | ||||||||||||
 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
||||||||||||
 |
[ Login/Subscribe ] | |||||||||||
 |
||||||||||||
 |
 |
 |
 |
 |
 |
 |
|
 |
||||
 |
||||||||||||
Features
Departments
Executive
Resources
|
Home > Departments > Business Analysis
One third of a typical development project’s budget goes to rework — half of which is traceable to poorly written requirements. Some $80 billion is spent annually developing software against requirements that are never used. Combine those facts with reports showing a majority of projects fail to deliver on early expectations, finish late or come in overbudget, and the picture isn’t pretty. Does the emerging project role of business analyst offer hope for improvement?
Seema Phull, principal of the Phoenix-based Arsu Group, is a business analyst — one of those oft-maligned people who write project requirements, translate them into two “languages,” and slog through long meetings with development teams, sponsors and key stakeholders. These professionals, whose previously ad hoc roles are just beginning to gain a defined shape and structure, may be the next best hope for development projects. If they can reliably bridge chasms that divide the technical and the business teams, BAs may be the key to solving myriad longstanding problems.
Along with having technical expertise and experience, business analysts must also understand key business requirements, prioritize expected ROI and process re-engineering requirements, Phull says. They must have a clear vision for an organization’s “big picture” goals and how technology fits into them. “Technology should follow the process, not lead it, or else you get an over-engineered solution.
Please login/register to read the entire article.
| |||||||||||||||||
|
Privacy Policy Contact Us User Agreement