In business today, any project is ultimately measured by one thing: return on investment. There are dozens of metrics to be measured along the way—from budget and deadline to scope and stakeholder satisfaction—however, at the end of the day, ROI trumps all.

Remember the movie Titanic? It overshot its budget by a nautical mile and took much longer to make than originally scheduled. However, a lifeboat full of Oscars later, the movie grossed about a billion dollars around the world.
Unfortunately, with your current projects, you probably won’t be able to lean on Leonardo DiCaprio to drive profits. That’s why, from a business standpoint, it makes sense to give your projects the best chance of success from the very beginning of the project life cycle. In other words, don’t sink your chances at profitability before you even leave the harbor. Metaphorically speaking, of course.

The best way to do this is to mix business analysis into your project management efforts. For years, professionals have been realizing that the infusion of business analysis can dramatically improve the likelihood of project success. Business analysis is essential for establishing project requirements, ensuring that your stakeholders are on board and eliminating the countless hours of rework that can wreak havoc on your budgets and timelines.

To help guide you in the integration of business analysis into your project mix, I’ve listed five key tips. From requirements gathering to communication to verification, think of it as your crash course in the value of business analysis. Each tip can be mapped back to the International Institute of Business Analysis (IIBATM) Business Analysis Body of Knowledge (BABOK®)

1. Ensure That Requirements Support Your Overall Business Needs

Having a list of business requirements is certainly an integral part of your long journey toward project success. However, before celebrating, you need to be absolutely certain that those requirements support your organization’s overall business objectives.

For example, if a company is looking to increase the efficiency of its call center by 20% over the next 12 months, it must first determine whether the requirements for achieving that goal fall within the business’ needs in terms of benefit and cost. If the requirements call for too much time and money to be spent, than the validity of the project should be called into question.

To determine if requirements support the business needs, analysts can use one of business analysis’ most central functions: enterprise analysis (EA). EA assesses an organization’s internal environment from multiple perspectives in order to gain a thorough understanding of the business as a whole and identify how that business can meet its strategic objectives.

2. Clearly Understand the Requirements Elicitation Process

Throughout the business community, it is widely agreed upon that about 50% of troubled projects are troubled because of poor requirements definition. So, obviously, at the beginning of a project, it is vital to effectively elicit all of the requirements needed for success. This is accomplished by relying once again on our old shipmate enterprise analysis.

EA, when performed correctly, will help you go beyond simply understanding the as-is state of the business and clearly define your stakeholders. There are several business analysis practices that will aid you in this process:

• RACI Charts offer a means for identifying different types of stakeholders—responsible, accountable, consult and inform—and offer strategies for dealing with each.
• User Profiles provide insight into the different classes of stakeholders and what their interaction will be with the intended solution. This ensures that all interested parties are included in the process.
• Stakeholder Questionnaires help narrow your pool of potential stakeholders to the true decision makers. Too often, business analysts, project managers and project sponsors discover in the middle of a project that they’ve left someone off the stakeholder list or included someone who doesn’t belong. Going backwards and bringing new stakeholders into the fold is time-consuming and expensive.

It is also essential very early on to create a glossary of terms and to ensure that everyone involved in your project is working within the same set of variables. What’s the difference between a business analyst and a business systems analyst? It may sound like semantics, but you could find yourself arguing over these sorts of terms throughout the life of your project if their definitions aren’t made clear from the start. And, be sure to get your variables straight, too, especially when working with partners and stakeholders around the world. In 1998, NASA lost a $125 million spacecraft on the surface of Mars because a subcontractor on the program referenced imperial units used in the United States instead of the NASA-specified metrics used in Europe.

3. Avoid Analysis Paralysis

Once you’ve successfully identified your stakeholders, you’re then tasked with choosing the most effective elicitation techniques. The key here is to be flexible and open enough to consider different techniques for different audiences. Techniques should be chosen based upon the different stages (vision, definition, analysis and decision) of solution development, the type of project, the size of the project and the experience of the team members involved.

At the Vision Stage, brainstorming and brain writing are effective. The Definition Stage is well supported by focus groups and joint-application-development sessions. During the Analysis Stage, gap analysis, root-cause analysis and force-field analysis are preferred. And, finally, during the Decision Stage, you should implore multi-voting, criteria-based grids and impact/effort grids.

Regardless of the technique you choose, however, you must always be mindful of sheer logistics. Over the years, I’ve seen countless requirements elicitation and verification efforts blown off course due to a business analyst’s failure to identify the many risks associated with something as seemingly simple as geographically dispersed stakeholders. For example, if you’re in Washington, DC and you’re scheduling a conference call with stakeholders in Singapore, it’s frighteningly easy to mix up the time zones. A careless mistake or a technical snafu at the wrong time can lead to a loss of momentum, a missed deadline or just general frustration and annoyance.

4. Deliver the Right Message to the Right People

The communication of your business requirements is nearly as important as the development of those requirements. To effectively communicate requirements to your stakeholders, you need to develop a communication plan that will determine who will communicate with your stakeholders, what they will say and when and how they will say it.

Of the who, what, when and how of your communication plan, you should pay particular attention to the who. Your designated communicator or communicators should obviously have solid business communication skills; however, you must think beyond that. Everyone has a different communication style, and it’s your responsibility to ensure that you’re communicating to your stakeholders the right way. This begins with determining whether you’ll be communicating with a homogenous or a heterogeneous group of stakeholders. If you find that you’re dealing with a homogenous group of C-level stakeholders, it’s best not to send your most meticulous thinker into the room. Chief executives tend to think in big-picture terms; bog them down in the details and you could be asking for conflict—particularity if you’re trying to prove the case against moving toward a proposed solution.

5. Verify the Business Needs

Once your project is complete, and after your team has enjoyed a happy hour, you’ve entered the solutions assessment and verification stage of your project. Your main objective here is to ensure that your finished product meets the initial agreed-upon requirements and that it has fulfilled its original purpose. For many projects, this process will be aided by simply adhering to regularity standards. However, for those projects that aren’t overseen by such standards, traceability matrixes are helpful because they create unique identifiers for each requirement that maps back to the original business need.

Also, traceability matrixes will help you make sure that no unnecessary requirements have crashed the party along the way. For example, if your goal was to build the world’s best sports car, you’ll be able to identify the incongruity of the towing hitch on the back bumper and, more importantly, recognize that it shouldn’t be there.

In Conclusion: Iceberg Avoidance

Any project you launch will face challenges, and the bigger your project gets, the rougher the waters will be. However, by following these basic tips and integrating business analysis into your projects from the very beginning, you’ll be much more prepared to identify all of the icebergs in your path and keep your projects afloat from beginning to end.

Source: Improving Return on Investment: Business Analysis in Projects | ESI PM Blog

–