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 validation, 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 (IIBA) 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, then the validity of the project should be called into question.

To determine if requirements support the business needs, analysts can use one of the most central business analysis functions: enterprise analysis (EA). EA accesses 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 Gathering Process

Throughout the business community, it is widely agreed 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 gather 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.

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 encourage multi-voting, criteria-based grids and impact/effort grids.

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. Validate the Business Needs

Once your project is complete, and after your team has enjoyed a happy hour, you’ve entered the solutions assessment and validation 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 the icebergs in your path and keep your projects afloat from beginning to end.

---

Glenn R. Brûlé is Director of Client Solutions at ESI International (www.esi-intl.com) and IIBA Director at Large. He has more than 18 years experience in many facets of business, including project management, business analysis, software design and facilitation. At ESI, he is responsible for supporting a global team of business consultants working with Fortune 1000 organizations. As the Director at Large for the International Institute of Business Analysis, Brûlé’s primary responsibility is to form local chapters of the IIBA around the world by working with volunteers from organizations across various industries. These include financial services, manufacturing, pharmaceutical, insurance and automotive, as well as government agencies.

I have three young children and we watch animated children’s movies together. They are full of action, with great heroes, nasty bad guys, and plenty of challenges to be overcome. The kids love them and get so caught up in them. So what has that got to do with requirements? Well, in many of the movies the hero is on a quest to reach a goal with very little information, a little like when we set out on a project with minimal information to reach our goal of a full set of business and IT requirements. Like the hero in the movie we might have a map or framework to follow but obstacles are always there and need to be overcome, and the means to do that is not defined within the framework. We must rely on our skills, experience and knowledge, much like the hero in the movies.

Now we don’t have to battle fierce monsters or have big sword fights with enemies in our projects (well not the ones I work on), but we may still face battles of a different kind. Like understanding what the users really want, their expectations, and what can reasonably be delivered within the project’s constraints. Budget and timeframe are obvious ones, but companies often have policies and standards that can create substantial constraints. We also need to know what the current IT capabilities are, and it is critical to understand what integration is required with other systems (some of these can be real monsters; now where did I put my sword?).

A movie it tells us a story. It all starts with a script and is developed into a storyboard which blends words and pictures into scenes. The scenes must work together and flow. Much like the way we model business flow, take our requirements and write Use Cases for how a particular aspect of the system will be used, giving it context.

So how do we make sure our requirements tell a complete story – and the right story, one our users will get excited about? And users do get excited about what the requirements will deliver. We need a business analyst that can act as a director and bring all the ideas, needs and requirements together, prioritise them and, in conjunction with an architect, identify where they all fit together with existing systems and business processes.

It is important for the business analyst to find the best way to communicate and deliver his or her interpretation and analysis of the requirements to the business and all stakeholders. Like the movies we must know our audience and present the information in a way that is right for them. Requirements must also be analysed then reviewed with key business representatives and other stakeholders, from all groups involved (including IT), to ensure understanding and acceptance. We must also accept that we don’t always get it right first time and be prepared to re-work the requirements, format, models, or presentation to gain that acceptance and, in some cases, signoff.

A balance must be found between the business needs and expectations and what is practical to deliver. Plus the solution proposed must suit the purpose. There is no point having a mighty sword if you can’t lift it, just like there is no point having really sophisticated security that lets no one in.

We see from the “making of” section on DVDs, that making an animated movie is a complex process taking many years. They have a team comprising many different groups of people working together in collaboration, and using iterative processes like storyboards and other design prototypes. Obviously a movie is very visual, but it too has integration issues like bringing music and spoken dialogue together with the computer generated images.

In the end all the animation and dialogue must be complete and it must all work together with the music. If something is missing, or poorly done, the film will not deliver the excitement and fun the children (and adults) expect. Using a collaborative approach with constant reviews and good communication, and iterative builds with constant review and testing can be applied successfully to most software projects. As with our projects we must make sure the requirements are well defined and understood, that developers create new or changed applications that look and function well, and are integrated correctly with other systems and all aspects of the agreed business, legal, security, quality of service and architectural requirements have been delivered and work well together. As business analysts we need to see beyond the requirements to the final solution.

Like the line in a recent movie I saw, we must “keep moving forward” and continue to develop our skills and techniques to understand our audience better, and ensure better requirement delivery in software.

After all a requirement is only as good as the delivered functionality that results from it. That’s how to become a BA hero.

---

Ross Wilson is a Senior Consultant with Equinox Limited in Auckland, New Zealand, specialising in requirements management. He has been working in IT for 23 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, project management, and team leadership. Ross can be contacted at [email protected]

National and Global Identity Systems – An Opportunity for BAs to Make a Social Contribution the Likes of Which Have Not Been Seen in Over 200 Years, and Which Is Now Feasible, Given the Existence of Our Neutral Standards Body, the IIBA.

What contribution, you ask? How about establishing the scope, risks and requirements for Identity Systems?

What’s that you say? This work is being done already?

IT IS TRUE that Amazon, PayPal, Blue Cross, MySpace (and now MySpace lenders), VISA/MC, your local police, and the Transportation Safety Authority, among others, are “solving” the “problem” of identity every day. Did you know that DisneyWorld now takes your fingerprint when you enter their park? I will buy a free dinner for the analyst who can tell me why (I know they do; I interviewed them mercilessly until they admitted it).

WHAT IS MISSING from current identity systems projects (ah, the many thousands) is a committed effort to determine requirements of a whole group of stakeholders – “We, the Identified” (WI).

WI are primary users of Identity! If you doubt this, ask yourself who initiates the transaction requiring “identity”? What do we call it if someone else initiates this transaction instead?

In spite of the clear stake that WI have, the systems focus primarily on the needs of the organizations (understandably), and coincide with ours only where the organization also benefits (sure, we all like fast transactions, even if we are being messed with – just so it’s fast!).

The problem here is partly one of the unintended consequences of otherwise rational economic behavior (I missed this reason last month). It is an example of “hidden costs” like pollution, where no single party has an incentive to make improvements in the absence of any outside duress or any market for trading on the costs. An example of the “hidden costs” of poor requirements is the fact that the potential terrorist list has now exceeded 750,000, AND 60% of all “bombs” actually get through airport security (these are recent TSA tests).

So, given the scope of the enterprise (in this case the People of the United States, their constitutionally elected government, and the multitude of identity systems with which we are currently saddled), I issue the following challenge to all BAs:

• To perform a volunteer led, BABOK compliant elicitation, analysis and documentation of the many conflicting requirements related to identification systems within the United States of America “enterprise”.
• To successfully negotiate acceptance of these requirements by all stakeholders, public and private, in such a way that the requirements are adopted into public legislation, practice, and/or the constitution.

Remember that, just as in every project, management (WI, the people?) reserve the right to make any final requirements decisions, and to resolve any disagreements for better or for worse. The political acceptance or rejection of our work will be its acceptance test.

AND – I didn’t forget – we still have an agenda of “BA implementation” problems to discuss. This project will give us PLENTY of opportunity to explore these, in a hands-on way.

We begin next month with a statement of the problem, and an attempt to scope out the stakeholders and their interests.

What do you see as existing issues with personal identity in systems today? How recently have you tried to get your own medical records? Any victims of identity theft out there? Victims of planted DNA?

I, for one, have had enough! How about you?

---

Marcos Ferrer, CBAP is an experienced teacher, public speaker and instructor with ESI International. He has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Mr. Ferrer began his BA career in 1982. While still a student at the University of Chicago, he developed a consulting practice with local property management and accounting firms. Following graduation in 1983, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in a number of different fields. In 1990, Mr. Ferrer became an independent consultant, again working with a variety of clients, most notably in the family entertainment industry. He has also worked on multiple government systems projects and “business” projects, including.

In November 2006, Marcos Ferrer became one of the first 16 CBAPs certified by the IIBA. He as served as Vice-President for Certification at the DC-Metro chapter of the IIBA.

© 2007 Marcos Ferrer