ITIL for BAs – Part VIII; What is Design?

Written by Terry Longo on February 24, 2009. Posted in Articles.

A colleague of mine who is much wiser than I (that could be pretty much anyone!) defined “design” as “the art of tradeoffs”.

It is easy to “design” an IT solution for 100% availability, more than enough capacity, extremely secure, with all the functionality currently desired, etc. – and such a design would surely meet business needs! But in most cases such designs are neither practical nor feasible and are thus empty exercises. True design replaces thoughtless overkill with a prioritization of the dimensions of a solution in a way that reflects the solution’s intent. That prioritization informs tradeoff decisions driven by the realities of cost and schedule.

In earlier posts I had discussed ITIL’s general coverage of Quality of Service (QoS) requirements. In ITIL V3, the Service Design book covers five specific QoS-related processes that should be considered during design. (The book also covers Service Catalog Management and Service Level Management, which we discussed earlier). During elicitation, analysis, and solution investigation, it is quite important for the BA to engage IT, through these processes, to ensure that

those QoS characteristics are properly prioritized relative to the solution’s desired business outcome (not just the business requirements, but the outcomes that ought to be realized by meeting those requirements), and
tradeoffs between these various QoS requirements, functional scope, cost, schedule, and risk are rigorously rationalized

Capacity Management ensures “that cost-justifiable IT capacity in all areas of IT always exists and is matched to the current and future agreed needs of the business, in a timely manner”. The consideration of “current and future needs” is at the level of specific applications and solutions as well as the overall IT infrastructure and organization itself (e.g., the possibility of mergers and acquisitions).

Availability Management ensures “that the level of availability delivered in all services is matched to or exceeds the current and future agreed needs of the business, in a cost-effective manner.”

IT Service Continuity Management supports “the overall Business Continuity Management process by ensuring that the required IT technical and service facilities (including computer systems, networks, applications, data repositories, communications, environment, technical support and Service Desk) can be resumed within required, and agreed, business timescales.”

Information Security Management seeks to “align IT security with business security and ensure that information security is effectively managed in all service and Service Management activities.”

Supplier Management’s goal is “to manage suppliers and the services they supply, to provide seamless quality of IT Service to the business, ensuring value for money is obtained.”

ITIL V3 defines a “manager” role for each of the above processes. The more mature these processes and roles are in IT, the more IT is able to participate effectively with BA in

requirements elicitation and analysis
negotiation (since there will undoubtedly be times when the business asks for more than IT is presently capable of delivering)
solution rationalization

Furthermore, IT in and of itself is not in a position to make tradeoff decisions but needs the BA’s involvement in and knowledge of the requirements and desired business outcomes, in order to make those tradeoffs.

There is of course much more to design than is covered here, such as designing for manageability and supportability, planning the solution’s retirement, etc., and the Service Design book covers all of that and more.

The key takeaway from today’s post is (a) QoS requirements can and should be reflected in the IT’s organizational structure and capabilities and (b) omitting consideration of these QoS characteristics can open the business to significant risks.

How mature is your IT organization with respect to these design activities? Do you and your fellow BAs engage IT early on in the requirements process? Are there past cases where in retrospect that did not happen but should have?

Please feel free to share your comments with your fellow readers.

When Needs Become Conflict

Written by Richard Lannon on February 24, 2009. Posted in Articles.

Recently I was reminded that only 10 percent of conflict is extreme and that 90 percent of conflict is acceptable. In working with a client, I noticed some needs that were not being met. Those needs erupted into what we would call conflict between several people on the team. It was interesting to observe what took place. Mostly it was a flight situation. The people in the conflict situation left the area. This is not a bad thing as sometimes you just need to get out of Dodge. When it comes to conflict we all need to take some common thinking into consideration.

First, conflict has its positive place in our lives. Conflict is natural and depending on our disposition we might fight/flight or fend/befriend. We are wired that way.

Second, think of conflict like the ice berg in the ocean; two-thirds of it is underwater. For people the portion under water has to do with our history, values, culture, beliefs and feelings and all the other stuff that is happening in our lives.

Third, one-third of the ice berg is above the water. This is where we observe people behaviours. The above the water iceberg represents the actual conflict event that occurs among individuals and teams.

Conflict thinking is often broken down into four levels. These include:

Position: This is the level that is about facts, data, and information. At this level a person or team takes their position.

Standards: This level is about policy and procedures that do not necessarily fit the individual or team culture. Somewhere a change is mandated without regard to the people impact.

Objectives: There is a lack of alignment in the organization, team and individuals goals and priorities. People are confused and are not sure what is important. There are conflicting interests and generally poor leadership.

Culture: The culture level is about values, beliefs and attitude. This is the level where individual, teams’ and organizations’ interest lies. This level is the deeper under the water level that should be understood and taken into consideration. This level can represent a real challenge.

We all need at least one approach to conflict resolution. The following 10 steps is an approach used in dealing with one on one conflict that, if engaged correctly, can go a long way towards resolving conflict.

Present the issue without emotion, blame, or judgment
Ask for the other person’s point of view
Explain your point of view clearly
Clarify and define the issues in terms of both your needs
Create a joint plan with which you both agree
Brainstorm and discuss possible solutions
Select the best chance of meeting both your needs
Develop a realistic plan of action and determine who will do what, by when, where and how
Implement the plan, make a commitment to it and follow it
Evaluate the success of the solution based on the joint objective

During the conflict resolution discussion, do your best to keep your emotions in neutral. That does not mean divorce yourself from your emotions. It simply means that it is alright for both sides to recognize their emotions and feelings. Each party needs to acknowledge their emotions, be willing to describe the situation and express how they feel. In turn, they must clearly specify what is expected and consider the consequences of individual, team and organization behaviours.

Much of conflict resolution is about acknowledging and settling the emotions through collaborative problem solving to satisfy the various stakeholders’ interests to the greatest degree possible.

Richard A. Lannon partners with business and technology organizations to help clarify their goals and objectives and train their leadership and professionals on how to achieve them. He provides the blueprint for you and your organization to be SET (structured, engaged and trained). That is why his clients call him the SETability Expert. Voice: 403-476-8853 Email: [email protected] Web: http://www.braveworld.ca/

Harness the Power of the PM/BA Partnership

Written by Cynthia Low on February 17, 2009. Posted in Articles. 1 Comment on Harness the Power of the PM/BA Partnership

Projects play an essential role in the growth and survival of organizations today. It is through projects that we create value in the form of improved business processes and new products and services in response to changes in the business environment. Since data and information are the lifeblood of virtually all business practices, projects with significant IT components are often the key mechanism used to turn an organization’s vision and strategy into reality. Executives have their eye on the project portfolio to ensure that they: (1) invest in the right mix of projects, (2) optimize their resources, (3) develop expert capabilities to deliver flawlessly, and ultimately, (4) capture the expected added value to the business. In the 21^stcentury we are bombarded with constant change brought about by the Internet, the global economy and the prevalent use of technology. As a result, there appears to be a never-ending demand for new business solutions supported by IT products and services. Executives across the spectrum are adopting the practices of superior project management and business analysis to increase the value projects bring to their organizations.

The Project Performance Partnership

In the spirit of high-performing teams, project managers align themselves with professional business analysts, expert technologists, and business visionaries to understand business problems or new opportunities, and determine the most appropriate, cost-effective, fastest time to market, and innovative solutions. As this core team forms, a project performance partnership emerges that rivals the world’s great teams, (e.g., tiger teams, special operations teams, professional sports teams, parametric teams). At the center of the team is the dynamic twosome: the project manager and the business analyst. The project manager keeps an eye on the management of the project, ensuring the project delivers on time, on budget and with the full scope of the requirements met. While the business analyst focuses on management of the business need, business requirements, and expected business benefits. The wise project manager welcomes this teaming trend, understanding that inadequate information relating to business needs leads to poor estimates, and makes time and cost management virtually impossible.

Business analysis and project management have become central business management competencies of the 21^st century. These competencies are essential because requirements play a vital role in engineering business solutions, and projects are essential to organizational success. In addition, organizations are realizing that the reasons projects fail are almost always tied to poor requirements and ineffective project management. (The Standish Group International, 1994-2006). The table below depicts the resolution of 30,000 applications projects in large, medium, and small cross-industry U.S. companies tested by the Standish Group from 1994 to 2006.¹³

Year	Successful Projects	Failed Projects	Challenged Projects
2006	35%	19%	46%
2004	29%	18%	53%
2000	28%	23%	49%
1998	26%	28%	44%
1996	27%	40%	33%
1994	16%	31%	53%

Source: The Standish Group Project Resolution History, CHAOS Research Reports (1994–2006)

Clearly there has been a steady improvement in project performance since 1994. According to the Standish reports, the reasons for the overall improvement include: smaller projects (the average cost of a project had been downsized more than half by 2001); better skilled project managers; and better methods and tools to manage changes. The Standish Group continues to recommend minimizing project scope, reducing project resources, and downsizing timelines to improve project success. The Standish Group also predicts that the number of critical projects wills double each year; therefore, we must continue to work vigilantly to improve project performance, paying particular attention to the elements it calls the Recipe for Project Success: The CHAOS Ten, which are listed here grouped by category. Notice that many of these elements relate to business analysis and the remaining are about better project management.

Recipe for Project Success: The CHAOS Ten

Project Management	Business Analysis
Executive support Experienced project managers Standard infrastructure Formal methodology Reliable estimates Small milestones, proper planning, and competent staff	User involvement Clear business objectives Minimized scope Firm basic requirements

It is the project manager who owns the Business Solution Life Cycle, and the business analyst who owns the Systems Requirements Life Cycle, from understanding the business need to ensuring that the delivered solution meets the need and adds value to the bottom line. (See Figure 1, below) For complex 21^stcentury projects, the business analyst has a critical role throughout the Business Solution Development Life Cycle, not simply during the requirements phase. Business requirements analysis differs from traditional information systems analysis because of its focus, which is exclusively on adding value to the business. In particular, project managers rely on business analysts to assist in providing more detailed project objectives; business needs analysis; clear, structured, useable requirements; trade-off analysis; requirement feasibility and risk analysis; and cost-benefit analysis. Poor requirements definition emerges without this key liaison between business and IT departments, resulting in a disconnect between what IT builds and what the business needs.

Figure 1 – Business Solutions Life Cycle Mapped to the Systems Requirement Life Cycle

Combining Disciplines Leads To Success

For organizations to achieve strategies through projects, a strong partnership between the project manager and the business analyst is essential. Indeed, when this partnership exists, and they both embrace the contributions of expert technologists and business visionaries, collaboration, innovation and far superior project performance is realized. For an in-depth discussion of the project manager and business analyst partnership, it is helpful to frame the dialogue in the context of a generic project cycle. Refer to Figure 1 once again, the Business Solution Life Cycle Mapped to the Systems Requirements Life Cycle, to provide context as we examine the nature of the partnership. The diagram shows a sequential development approach, from strategic planning to the business requirements to the delivery of a complete business solution. This is a simplistic model that guides the development process through its typical phases.

Strategic Planning and Enterprise Analysis

Strategic Planning

Strategic planning is the first phase in the Business Solution Life Cycle. During this phase the current state of an enterprise is examined and the desired future state is determined and described by a set of broad goals. The goals are then converted to measurable objectives designed to achieve the strategy.

Project managers and business analysts may not contribute directly to strategic planning activities since it is the responsibility of the senior leadership team. However, senior business analysts and project managers may be asked to conduct market research, benchmark studies or competitive analysis surveys to inform the executive team as input to the strategic planning process. In some organizations, senior business analysts and project managers help plan and facilitate strategic planning sessions. Nevertheless, business analysts and project managers should have a full understanding of the strategic direction of the enterprise to determine how new initiatives fit into the long term strategy and/or mission of the organization, and to help build and manage the business case and other relevant information regarding business opportunities.

Enterprise Analysis

The enterprise analysis phase of the Business Solution Life Cycle consists of the collection of activities for depicting the current and future views of the business to determine the gap in organizational capabilities needed to achieve the business strategies. Enterprise analysis activities then determine new business opportunities to close the gaps.

Enterprise analysis activities begin after the executive team of the organization develops strategic plans and goals. The core activities center on: (1) identifying new business opportunities or solutions to business problems, (2) conducting studies, gathering information and determining the solution approach, (3) developing a business case or project proposal document to recommend a new project to the leadership team for their decision whether to select, prioritize and fund a new project. If the new change initiative is selected, a new project is formed and requirements elicitation and project planning commence.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the enterprise analysis activities.

Deliverables	Description
Business Architecture	The business architecture is the set of artifacts that comprise the documentation about the business.
Feasibility, Benchmark, Competitive Studies	Conducting formal or informal studies prior to proposing a new project helps to discover very important information about the business opportunity.
New Business Opportunities	As an outgrowth of strategic planning, the business analyst and project manager review the results of feasibility, benchmark and competitive analysis studies, and the target business architecture to identify potential solution alternatives to achieve strategic goals.
Business Case	A business case should be developed for all significant change initiatives and capital projects.
Initial Risk Assessment	Once the business case is developed, the project manager and business analyst facilitate a risk management session using the same set of experts.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration to complete the enterprise analysis activities, including:

Conducting feasibility, benchmark and competitive studies
Creating the business case, scope statements, preliminary time and cost estimates
Conducting risk assessment and risk response planning
Establishing project priorities
Managing stakeholders
Getting the right people involved and excited about the potential project
Partnering with senior IT architecture team to create the solution’s “vision”

Requirements and Design

During the requirements and early design phases the business need is discovered, analyzed, documented and validated and the solution concept begins to come into view.

Requirements Elicitation

Requirements are always unclear at the beginning of a project. It is through the process of progressive elaboration that requirements evolve into maturity. Requirements elicitation involves conducting initial requirements gathering sessions with customers, users, and stakeholders to begin the specification process. Requirements gathering techniques include: discovery sessions and workshops, interviews, surveys, prototyping, review of existing system and business documents, and note taking and feedback loops to customers, users, and stakeholders.

Requirements Analysis

Requirements are first stated in simple terms, and are then analyzed and decomposed for clarity. Requirements analysis is the process of structuring requirements information into various categories, evaluating requirements for selected qualities, representing requirements in different forms, deriving detailed requirements from high-level requirements, and negotiating priorities. Requirements analysis also includes the activities to determine required function and performance characteristics, the context of implementation, stakeholder constraints, measures of effectiveness, and validation criteria. Through the analysis process, requirements are decomposed and captured in a combination of textual and graphical formats. Analysis activities include:

Studying requirements feasibility to determine if the requirement is viable technically, operationally, and economically
Trading off requirements to determine the most feasible requirement alternatives
Assessing requirements feasibility by analyzingrequirement risks and constraints and modifying requirements to mitigate identified risks. The goal is to reduce requirement risks through early validation prototyping techniques
Modeling requirements to restate and clarify them. Modeling is accomplished at the appropriate usage, process, or detailed structural level
Deriving additional requirements as more is learned about the business need
Prioritizing requirements to reflect the fact that not all requirements are of equal value to the business. Prioritization may be delineated in terms of critical, high, average, and low priority. Prioritization is essential to determine the level of effort, budget, and time required to provide the highest priority functionality first. Then, perhaps, lower priority needs can be addressed in a later release of the system.

Requirements Specification

Requirement specifications are elaborated from and linked to the structured requirements, providing a repository of requirements with a completed attribute set. Through this process of progressive elaboration, the requirements team often detects areas that are not defined in sufficient detail, which, unless addressed, can lead to uncontrolled changes to requirements. Specification activities involve identifying all the precise attributes of each requirement. The system specification document or database is an output of the requirements analysis process.

Requirements Documentation

Requirements documentation must be clear and concise since it is used by virtually everyone in the project. Transforming graphical requirements into textual form can make them more understandable to non-technical members of the team. Documentation activities involve translating the collective requirements into written requirements specifications and models in terms that are understood by all stakeholders.

Requirements Validation

Requirements validation is the process of evaluating requirement documents, models, and attributes to determine whether they satisfy the business needs and are complete enough that the project team can commence work on solution design and construction. The set of requirements is compared to the original initiating documents (business case, project charter, statement of work) to ensure completeness. Beyond establishing completeness, validation activities include evaluating requirements to ensure that design risks associated with the requirements are minimized before further investment is made in solution development.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the requirement deliverables:

Deliverables	Description
Stakeholder analysis and communication needs	Interviews are conducted with individuals and small groups to find out what business functions must be supported by the new solution.
Elicitation Workshops	Requirements workshops are an efficient way to gather information about the business need from a diverse group of stakeholders.
Surveys	Surveys can provide a valuable tool to collect a large amount of information from an array of stakeholders efficiently and quickly.
Document Reviews	The business analyst and project manager review all existing documentation about the business system, including policies, rules, procedures, regulations, process descriptions.
Test Plan	Typically a document that describes the scope, approach, resources and timing of test activities.
Business Requirements Documentation and Validation	Structured, validated, archived and accessible requirements are the functional and performance needs for the new solution, captured in: documents, tables and matrices, models, graphics, prototypes
Requirements Management Plan	A document that describes how changes to requirements will be allocated, traced and managed.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during requirements activities, including:

Conducting requirements elicitation workshops
Determining the number of iterations of requirements elicitation, specification, and validation
Determining the appropriate life cycle choice (e.g., waterfall, Agile, Spiral)
Developing the project management plan
Conducting trade off analysis for the requirements and solution trade-offs
Balancing the competing demands
Validating requirements
Prototyping
Updating the business case
Planning and facilitating the control gate review, signoff on requirements, and go/no decisions

Solution Construction and Test

During the solution construction and testing, the business analyst and project manager collaborate to ensure changes to requirements are identified, specified, analyzed for impacts to the project (cost, schedule, business value add), and dispositioned appropriately. The goal for both the business analyst and the project manager is to reduce the cost of changes, and welcome changes that add business value. Requirements management activities include: allocating requirements to solution components, tracing requirements throughout system design and development, and managing changes to requirements.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution construction and test activities.

Deliverables	Description
Solution Verification and Validation	Validating requirements to provide evidence that the designed solution satisfies the requirements through user involvement in testing, demonstration, and inspection techniques. The final validation step is the user acceptance testing. Verifying requirements to provide evidence that the designed solution satisfies the requirements specification through test, inspection, demonstration, and/or analysis.
Business Policies, Procedures, Rules, Education	For new business solutions, there are almost always changes to business rules, policies, and procedures.
Testing	Including integration, system, and user acceptance testing.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution construction and testing phases including:

Developing the test plan and test approach
Validating activities to ensure the solution meets the business requirements (customer reviews, product demonstrations)
Reviewing test results and dispositioning identified defects
Conducting defect root cause analysis and determining the appropriate corrective action
Managing issues
Managing stakeholders
Facilitating the go/no go decision to deliver

Solution Delivery

Planning for the organizational change management that is brought about by the delivery of a new business solution is often partially or even completely overlooked by project teams that are focused mainly on the IT application system. While the technical members of the project team plan and support the implementation of the new application system into the IT environment, the business analyst and project manager are working with the business unit management to bring about the benefits expected from the new business solution by:

Assessing the organizational readiness for change, and planning and supporting a cultural change program;
Assessing the current state of the knowledge and skills resident within the business, determining the knowledge and skills needed to optimize the new business solution, and planning for and supporting the training, retooling and staff acquisition for skill gaps;
Assessing the current state of the organizational structure within the business domain, determining the organizational structure needed to optimize the new business solution, and planning for and supporting the organizational restructuring;
Developing and implement a robust communication campaign to support the organizational change initiative; and
Determining, enlisting and supporting managements’ role in the championing the change.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the solution deployment activities.

Deliverables	Description
Deployment plans	Developing and communicating the plans to implement the new business solution.
Business policies, rules, procedures	Implementation of business policies, procedures, rules, etc.
Education and training	Training of business customers, stakeholders and users to accept and operate the new business solution efficiently.
Post-implementation support	The business analyst and project manager provide support to the business customers, stakeholders and users to help them learn how to operate the new business solution efficiently, and to resolve any issues that arise.
Lessons learned	The business analyst and project manager conduct lessons learned sessions with the project team, the business customers, stakeholders and users, and the technical team to determine what went well, and what needs improvement for future projects.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during solution deployment activities including:

Developing, communicating, and getting approval for the deployment plan
Approach (deploy to all business units or use a phased in)
- Which business units are affected?
- When will the business units be implemented?
- When will training be delivered?
- When will post-implementation support by the core project team end?
Making the decision to move to O&M
Conducting lessons learned sessions

Operations and Maintenance

The business analyst and project manager contribution to the success of the project does not end when the business solution is delivered and operational. There are key responsibilities during Operations and Maintenance (O&M) that must be filled. O&M is the phase in which the system is operated and maintained for the benefit of the business. Maintenance services are provided to prevent and correct defects in the business solution.

Deliverables

The business analyst and project manager collaborate with selected business and technology experts to produce the deliverables of the O&M phase.

Deliverables	Description
Solution benefits measurement	The actual business benefits that are realized are captured, analyzed and communicated.
Identification, prioritization, and planning for solution enhancements	Maintenance and enhancements projects are: identified, prioritized by business value, planned, executed
Decision to deactivate	At some point, the solution will need to be replaced. The decision to do so often involves the enterprise analysis activities described above.

PM/BA Collaboration Opportunities

The project manager and business analyst have numerous opportunities for collaboration during O&M including:

Prioritization of enhancements
Root cause analysis of performance and value attainment issues

Final Words

Gaps in technology, techniques, and tools are not the fundamental reasons why projects fail. Rather, project failure most often stems from a lack of leadership and poor choices made by people. Undeniably, the business analyst and project manager are evolving into strategic project leaders of the future. The key issues are no longer centered on control and management, but rather collaboration, consensus, and leadership. Team leaders develop specialized skills that are used to build high-performing teams. When building software-intensive systems, well managed teams undoubtedly accomplish more work in less time than do poorly managed teams (Bechtold, 1999).

References

Bechtold, R. (1999). Essentials of software project management. Vienna, VA: Management Concepts.
Hadden, R. (2003). Leading culture change in your software organization. Vienna, VA: Management Concepts.
Mooz, H., Forsberg, K., & Cotterman, H. (2003). Communicating project management: The integrated vocabulary of project management and systems engineering. Hoboken, NJ: John Wiley and Sons.
The Standish Group International, Inc., “2007 First Quarter Research Report,” The Standish Group International, Inc. (2006–2007).
The Standish Group International, Inc., “Extreme CHOAS,” The Standish Group International, Inc. (2001), Online at http://www.smallfootprint.com/Portals/0/Standish%20Group%20-%20Extreme%20Chaos%202001.pdf (accessed January 2008).
Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems engineering: Coping with complexity. Indianapolis, IN: Pearson Education, Prentice Hall PTR.

Kathleen B. Hass, PMP

is Senior Practice Consultant for Project Management and Business Analysis, and Director at Large and Chapter Governance Committee chair for the International Institute of Business Analysis (http://www.theiiba.org/). She is the author of Managing Complex Projects: A New Model (Management Concepts, October 2008). Since 1973, Management Concepts, headquartered in Vienna, VA, has been a global provider of training, consulting and publications in leadership and management development. Management Concepts is a Gold International Sponsor and an IIBA Endorsed Education Provider For more information, visit http://www.managementconcepts.com/ or call 703 790-9595.

More Bad-Ass BA Techniques

Written by Cecilie Hoffman on February 17, 2009. Posted in Articles.

Guidelines for Interviewing Candidate BAs

You have just been told by your manager that you will be interviewing a candidate for a mid-level business analyst position on your team. “We can’t hire full-time employees right now, but we can bring on contractors for this project. Make sure they have the skills we need, okay?” is the only direction you receive in the email other than the candidate’s resume.

Among us are few who have been taught how to conduct an interview, and I’m not talking about the “don’t ask these questions, ever!” memo from Human Resources. Just how do we determine whether a candidate, who has dressed properly for the interview, and seems like a nice person, could be a great contributor to our team?

I look for fundamental traits and indicators. Many people will use the term “soft skills” to describe these traits. I hate the term “soft skills” because it implies that the difficult skills are the domain-level technical skills, while the problem-solving and human interaction skills are “easy.” In my humble (ha!) opinion/experience, the problem-solving and human interaction skills and fundamental traits are the most difficult attributes to find in a candidate, and the most difficult to teach to an already hired employee.

Candidates are usually interviewed for their knowledge of a business domain, like, finance applications, or medical service auditing. There are plenty of people with the subject matter expertise who can interview a professional level candidate to determine if they have the right knowledge. Few people have been trained to interview a business analyst candidate for the critical thinking and communication skills that are indicators for success.

Here is my list of questions for a professional level candidate, an intern candidate (no previous professional experience) and a list of traits that I have found most successful BAs to possess. I hope this will be helpful for your next encounter with a candidate.

General Interview Guidelines for a BA

These suggestions are in no specific order.

Use the Dilbert cartoon: http://www.csus.edu/indiv/l/legorretal/160_Spring_2006_05_
Dilbert_on_requirements_gathering.jpg
Ask the candidate to explain why it is funny, and ask for an example of how they resolved a difficult requirements elicitation situation.
Ask the candidate to describe what information goes into a Business Case, and how does that information relate to a Requirements document.
Ask the candidate to explain the difference between the role of the BA and the role of the PM, and how they have managed when they had to play both roles on a project.
Ask the candidate how they go about obtaining success criteria for requirements, and for bonus points, how they determine what metrics to associate with those success criteria.
Ask the candidate to describe their group facilitation skills.
Ask the candidate to describe the difference between functional and non-functional requirements.
Ask the candidate to describe the difference between a requirement and specification.
Ask the candidate to describe the most interesting problem they ever built a model for, and what the model showed.
Ask the candidate if they are an “ask for forgiveness or wait for permission” type of person, and why.
Ask the candidate what they enjoy about being a business analyst.

Interview Questions for the BA Intern Position

People who interview for an intern position are not expected to have previous professional-level experience. Keep in mind that while you, the hiring group, are hoping for high-quality and low-cost labor, the candidate is evaluating you as a potential mentor.

Do you know what a business analyst is, and what a business analyst does?
How does being “in between” the business and technical world sound to you?
Do you write? Poems? Short stories? Keep a journal or a blog?
Tell me about a situation where you and some friends were trying to solve a problem. I’m looking for a situation in which some people wanted to go about dealing with the situation one way, and you or someone else had a different idea.
planning a team effort for a school project
planning a social gathering, party, sports event
Tell me about a project that you worked on that you enjoyed a lot. Would you give me the big picture first then tell me about one detail-level part of the project.
Is there a technical device that you really enjoy using? How would you describe that device, and what it is good for to, let’s say, your great uncle who won’t use an automated bank teller?
How do you feel about asking questions in a group situation?
When you have been in a group, and people are arguing, how do you feel? Do you try to resolve the conflict? What if you are responsible for the group coming to an agreement?
Have you used flowcharts or process maps in your school work? How do you decide when to use words to describe something and when to use graphics/pictures?
In school you found yourself with multiple “priority one” tasks. How did you decide what to work on? How did you decide how to manage your time and energy?
Sometimes you have to make decisions in the absence of guidance. Are you more comfortable taking the initiative or do you prefer to wait until guidance is available? Tell me about a situation where you had to make that choice.
How would you describe your leadership style?
- authoritarian
- participative
- delegative
- I don’t consider myself a leader

Traits of Successful Business Analysts

Has a strong interest in problem identification and problem resolution
Able to determine when solutions are being presented as problems, and can drill down to the underlying problem
Able to comprehend both big picture and detail-level information, and know when to work at which level
Able to abstract a big-picture from detailed information
Able to translate between business and technical ways of talking about something
Able to function with both fuzzy and crisp representations and know when to use which
Able to ask the dumb questions
Able to appreciate the need for process even when it will mean possibly missing a deadline
Able to mediate or temporize when serious conflict arises
Able to remain collected and productive during conflict
Able to generate alternative solutions for consideration to facilitate the decision making process, even if the analyst has a strongly preferred solution
Able to play the role of advocate for a weakly-represented group or alternative that needs more consideration
A high degree of honesty and integrity
Able to engender trust and confidence from all the various parties involved
Maintains a sense of detachment from the influence of power mongers
Sensitive to politics and power structures
Tolerant of ambiguous situations
Respectful of each individual
Has a warped sense of humor
Predisposed to work collaboratively while still being able to work independently
Able to modify own leadership style so that it is appropriate for the project and the parties involved
Able to take initiative appropriately (do the right thing in the right situation), that is, decide whether to ask permission or to act and then seek forgiveness

Cecilie Hoffman

is a Senior Principal IT Business Analyst with the Business Analysis Center of Excellence, Symantec Corporation. Cecilie’s professional passion is to educate technical and business teams about the role of the business analyst, and to empower the business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the Silicon Valley chapter of the IIBA. She writes a blog on her personal passion, motorcycle riding at http://www.balsamfir.com/motoblog/motojournal.html. She can be reached at [email protected].

B.A.gile!

Written by Marcos Ferrer on February 17, 2009. Posted in Articles. 1 Comment on B.A.gile!

This is NOT another Agile Methodology posting. I make no claims to any special agile expertise, nor am I interested in methodology wars. I just want to say that fads are fads, and never substitute for analysis. I completely understand the attraction to agile. It is an excellent summary of what can work for some teams, on some projects.

It is my observation that all the named methodologies I have run into can map onto BABOK concepts, and the BABOK is a superset of them.

Here is the manifesto itself for context (derived from the Agile organization’s own web site at www.agilemanifesto.org ):

Manifesto for Agile Software Development

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

———————————————————————————

And here is one analysis, based on general knowledge, personal experience and BABOK concepts:

BA Fundamentals (and hence the essential skills to perform Requirements Communication) have to be present before tools matter. Tools can only support competent, effective behavior, not create it. In a sense, all successful projects are “agile” – it is my observation that all successful projects are full of brilliant individuals who interact fast and freely. This single factor seems to compensate for everything else – counterexamples are welcome, I don’t have any.
Software over documentation is already the most common approach in software development, so it is hard to understand why it matters to “Agile”. Since 65% “failure” rates are already being achieved in software development, it must be items 1, 3 and 4 that really matter, if Agile is effective at all.
Substitute “Iteration of Requirements with Stakeholders” for “Customer Collaboration”, and substitute “waterfall requirements” for “contract”. Contracts, at their worst, are an attempt to “lock in requirements” before they are understood, leading to excess change order profits for the contractor (when changes are allowed), or failed stakeholder acceptance (when they are not). Waterfall requirements are best saved for “one shot” efforts like the moon program.
Over planning, and reluctance to adjust plans as requirements are “learned”, is clearly a cause of certain project failures – it is mostly a failure of intelligence (see item 1). What is missing from this concept is the idea of Enterprise Analysis (especially risk analysis, stakeholder analysis, and cost benefit analysis) and the Requirements Planning that must follow from these. Another way to put this is – IF the project is simple and low risk enough, Agile may be a fit (see BOK tables 3.0 and 4.0 in the Enterprise Analysis section, and see if you can spot which projects might use Agile.

SO, from analysis to opinion (if you have your own opinion, send it in, we will tally responses and report on same):

IN MY OPINION: Agile process fits certain kinds of projects, but hardly most. Here is my list – what is yours?

“Small potatoes” – low risk, decent to high payback systems that only have to satisfy a small number of users with homogeneous interests, have low visibility, or represent proven, successful increments to already successful systems (yes, maintenance and enhancement).

“Feasibility” or “Proof of Concept” trials, which could clear the way for more investment in a larger project?

“Research” projects, where almost all is unknown, budgets are huge, and the paybacks considered indispensable, if they can be achieved at all. These are really rare; one example was the “skunkworks” team that developed the unique (and ultimately unsustainable) Blackbird spy plane.

“Invention” projects for systems that can succeed “virally” and evolve, that represent completely new behaviors ,or huge boosters to behaviors, that people crave, regardless of how poorly delivered (e.g., cell phone service, social networking, 45rpm records).

WHAT AGILE PROBABLY DOESN”T DO is Enterprise level projects, projects that must organize the efforts of many people. I am sorry to say that I hold this opinion in spite of the fact that I helped lead just such a success – an Investigation Management system for over 1400 government users. We succeeded by using all four principles in the Agile Manifesto, AND this only worked because we were an A-1, Agile Item 1 team.

My advice – get the smartest team you can that actually CARES about their work, and put them under tremendous pressure – they will cut to the bone, and will NOT skip any critical steps, and you can call it Agile if you want, but I call it B.A.gile!

More shall be revealed. Keep the feedback coming to [email protected].

Have fun!