Many good business analysts have evolved into strong software project managers--a natural career move accelerated by the shortage of experienced software project managers. Unfortunately, no one seems to be stepping into the analysts' vacant ecological niche. In this week's column, Payson Hall warns that business analysis is becoming a lost art. And it's the software project team ecology that is suffering the most from this trend.
Once upon a time, in the early days of computing, there was a plethora of creatures called "business analysts." Business analysts are people with technical knowledge, business knowledge, and analytical and communication skills. They frame business problems in technological terms during project definition, and help manage the business implications of technology solutions during implementation. Sadly, the business analyst role is going the way of the dodo bird, 8-track tapes, and mainframes in many modern software organizations.
Many good analysts have evolved into strong software project managers--a natural career move accelerated by the shortage of experienced software project managers. Unfortunately, no one seems to be stepping into the analysts' vacant ecological niche. Business analysis is becoming a lost art. While there are still folks with the title on their business cards, true business analysts are a rare and valuable species in the twenty-first century, and many projects are paying a steep price for their absence from software project team ecology.
As the demand for good software project managers continues to exceed supply, I've noticed a dangerous trend toward assigning people with good, general project management skill (but no software project experience) to software implementation projects. This trend is inadvertently encouraged by those evangelizing professional project management, who sometimes downplay the relevance of domain expertise in their zeal for espousing the commonalities among projects. While it's true that project managers in various disciplines use similar processes for definition, planning, and execution, it is challenging to develop a clear project definition and corresponding task list without domain expertise. In most specialized disciplines, this challenge is addressed by adding subject matter experts to the team. Most people would want a grizzled construction veteran at the right hand of a project manager, overseeing construction of their home. Unfortunately, many organizations don't appreciate that software development is as specialized as building construction. In days gone by, when their population was plentiful, business analysts were the subject matter experts that helped keep things together for the software project manager with minimal software experience.
Two projects I reviewed recently desperately needed business analysts to assist with implementation planning. Although both project managers were bright and competent people, neither had much software project experience. Neither project had strong business analysts on the team, nor recognized the deficit. Both projects had clear statements of the system functionality to be provided. Both procured vendors/systems integrators to deliver that functionality (one through custom development, the other through off-the-shelf product implementation). Both project managers assumed that the vendor would handle the implementation details. Neither appreciated the magnitude of the work that lay beyond the boundaries of what the vendors had agreed to do, nor the challenges inherent in establishing those boundaries.
A good business analyst could have helped define the projects better, more clearly establishing vendor responsibilities, and set better expectations with the affected business units regarding the impact of the changed software systems being implemented. Anyone with a software background can come up with most of these questions. As you reviewed the list, you probably felt a twinge of guilt from personal oversights in your younger days. While asking the questions is simple, developing comprehensive answers is much more challenging and requires business knowledge specific to the implementation at hand.
A good systems integrator might identify and address some of these issues. It is also easy to see how some issues could easily fall through the cracks or be defined to exist beyond the bounds of a vendor's responsibility. This is exactly why the elusive business analyst must be preserved as a vital part of the project team. We need business analysts who are knowledgeable about our specific business practices and technology environment to worry about the specifics of how these issues are addressed. Without subject matter experts worrying about the details, we can't effectively manage our projects--even with extra project managers and a manual full of good project management practices.
Bottom Line
Though the population of systems analysts is dwindling, our projects still need their expertise. Our future depends upon preserving the ones we have by maintaining their habitat and food supply (treat them right and pay them well). We also need to nurture the young ones so that they can grow to be the strong systems analysts of tomorrow. Preserving their niche is vital to our success.
Career Thought for the Week
It is relatively easy to outsource programming to a group of smart people with electricity and Internet access anywhere. It is difficult to outsource business analysis--by definition the business analyst must live in proximity to the systems users.
