The IT industry is plagued by outdated-waterfall methodologies rooted in manufacturing paradigms. If I had a nickel for every home construction or moon landing metaphor referenced in my professional life, the weight of my pockets would rip my pants off. The problem is not that these types of comparisons are completely irrelevant, it’s that they lack imagination and keep us from adopting flexible and people-oriented methodologies. Software development is NOT like deploying the MARS land rover. It’s much simpler than that. By remaining stalwart supporters of waterfall methodologies we overcomplicate what can be a very organic process. Nowhere is this more evident than in the Business Intelligence space. Iterative development can be a magical alternative to antiquated-waterfall methodologies, particularly for BI work, but your potion will require a few key ingredients to work: an awesome team, a transparent budget, structure, and trust.

There certainly is a time and place for “ye-old waterfall” project. Mission critical applications where mistakes can result in loss of revenue, customer dissatisfaction, jail time, or death are well suited for ridged, measurable, and risk-averse methodologies. However, some organizations are so entrenched in this line of thinking that every project is subjected to the tortures of the waterfall. In nature, a rushing waterfall is fluid and fast. In the business world waterfalls are clunky and slow.

 
In my last article I wrote on how different roles within projects and organizations view BAs. An important part of being a Business Analyst is understanding how we are perceived and how we fit in with those around us. As the career and roles of Business Analysts evolve we also need to look at our experience as a BA and reflect. Reflect on where we fit, the next step, and how we prepare for the next role we want. At some point the industry, ourselves, the company we work for, or the role itself evolves. No matter where we are in our evolution as a BA we wear many hats, how does each of these hats contribute and influence project results?  What makes a BA the one that leaders use as the example of value that BAs bring?

The idea of what makes a great BA has changed over time as we grow in our careers. Much of this has been due to how the IT industry has evolved and how business groups have changed in relation to IT.  In this article I attempt to follow the growth of a “typical” BA through various stages of progression in the BA skill set. Realizing that we all have a different path and the skills and experience we gain depends on project complexity and the cultural environments we learn these skills in.

According to the International Institute of Business Analysis (IIBA):

A Business Analyst works as a liaison among stakeholders in order to elicit, analyze, communicate and validate requirements for changes to business processes, policies and information systems. The Business Analyst understands business problems and opportunities in the context of the requirements and recommends solutions that enable the organization to achieve its goals.

Business Analysts (BAs) face a variety of challenges. For example, a recent survey (Business Improvement Architects, 2005) identified the following top organizational challenges:

1. Lack of clarity in the scope of the business functions.
2. Business requirements not well defined.
3. Conflict between business groups.
4. Not bringing in business analysts in sufficient time.