Articles Archives - Page 369 of 418 - Business Analyst Articles, Webinars, Templates, Jobs

Bad Ass BA; Peer Review. Part 3.

Written by Cecilie Hoffman on November 10, 2009. Posted in Articles. 1 Comment on Bad Ass BA; Peer Review. Part 3.

Co-authored by Rebecca Burgess

Use and Profit from Peer Reviews of Requirements Documents

This article is part 3 of a 4-part series on the topic of peer review of a requirements document. Before we dive into part 3, indulge me in a personal note.

My organization recently changed from having a peer BA review another BA’s BRD to a novel process in which four BA peers review one BRD. Each of the four peers has a different perspective based on their professional experience. Two weeks ago one of my BRDs went through peer review. In our process, first the reviewers provide their written comments. Then the BRD author has a full day to review the comments before conducting a structured walk-through of the BRD with all the peers in a conference call.

While reviewing the combined comments on my BRD, I experienced a series of emotions I haven’t felt in quite a while: initial horror, shame, indignation, despair and dismay. One of my peers wrote me a note, “Hey Cecilie, is this a test? I’m commenting on your BRD with words that I hear in my head in your voice.” I wish I could say that it was a test, but it wasn’t. I had submitted a BRD to the peer review process under duress (time pressure); the BRD wasn’t my best work but I honestly didn’t expect that scrub cloths would come back so dirty after my peers had examined my work.

I spent several hours cleaning up that BRD. I wasn’t looking forward to the conference call review where, in accordance with our internal process, I would walk the group through the comments that were marked “High” and “Showstopper” – I would have to reply to each such comment and offer a suggestion for remediation. All High and Showstoppers had to be resolved, otherwise my BRD would fail the peer review and fail to move to the next step of the BRD approval process.

My BRD received a conditional approval from my peers – I had to get a couple of questions answered from the stakeholders first. Fortunately the answers came back quickly. Another hour to tidy everything up, and the BRD was fully approved by the peer group to move forward. Most of the time I do leave my ego at the door but apparently I kept it with me during the review because it took a couple of hours of mentally pouring honey on my bruised ego for me to recover.

We’ve been running this peer-group review process for about two months. We are hearing from the downstream reviewers – all managers – that the quality of the BRDs has improved noticeably. I can attest that the quality of my BRD benefited from the scrutiny of my peers. The difficulty in a peer review is that, if the peer reviewer is also your friend, your friend may not be able to be as honest as you need him/her to be. The team of four gave me honest, constructive comments about scope and risk; they caught inconsistencies in the requirements, and questioned the testability of some of the requirements. An un-anticipated side effect of this peer-group review process is that we are learning from each other about how to address BRD authoring problems much faster than anyone expected.

So, that was a long note, but I hope it is helpful to anyone who is nervous about giving peer review a try. Embarrassment will not kill you and in the end you will be more proud of your work.

Let’s do a recap before we begin part 3.

One way to conduct a review is as a series of go/no go checkpoints.

Just to review, here are the four checks:

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check (In this issue)
Requirements Document Housekeeping Check (December 2009)

And here are the typical excuses not to do a peer review, and why those excuses are bogus.

It’s scary! – They won’t say this out loud, but it’s true. You must separate your self esteem from the evaluation of your work by learning to accept criticism as constructive and valued, rather than destructive and to be avoided at all cost.
It takes time – Yes, but the payback is substantial, both in minimizing the impact of errors, and in maturing the BAs on the team.
We are already behind schedule – Would you rather let the customer catch the errors? Or worse yet, miss the errors?
I don’t know anything about that project – So you’ll limit your review to the more general, BA-level comments; that’s still valuable.
It’s hard to do – True. The more you practice, the less difficult it will be the next time.

In the first article we checked for Business Case Synchronicity. We found that the BRD synched up with the business case, that is, benefits for doing the project have been identified, there is an expectation of Return on Investment, and there is an expectation that the project will report on progress towards achieving the ROI claim. Moreover the customer has identified the means for validating project success.

In the second article we performed the Sanity Check. We verified that the Scope not only identifies what is in scope, but what is out of scope as well. The document has a business context diagram, a 30,000 foot view of what the project is about in terms of system functionality, the business entities that will interact with the system, and information that is exchanged between the entities and the system. Finally we verified that the categories of the requirements made sense for this particular BRD.

Now it is time to look at the requirements statements themselves, both individually and, as they relate to each other.

Requirements Statements Content Check

Take a deep breath, hold it, and let it out slowly. Make sure you aren’t going to be interrupted for at least half an hour. Depending on the length of the document, you’ll need chunks of uninterrupted time to do this part of the review.

Check the box next to the item if you can answer ‘yes’ for the document you are reviewing.

Clarity

Is each requirement relevant to the business problem?

Are all requirements actually requirements, not design or implementation statements?

Design and implementation statements are “how” statements; a requirements document has “what” statements that ideally do not imply a desired solution.

Do you understand each requirement? Does each requirement make sense to you?

If a requirement doesn’t pass your “sniff test”, it likely won’t make sense to anyone else.

Are the requirements “solution agnostic”, i.e., do they convey the business need without specifying a solution?

Are the statements constructed as proper statements or sentences?

If you think the requirement statement is a fragmented thought, other people will too. The BA author may need to request more information (not necessarily more detail).

Is the content in each statement just sufficient to convey the idea?

Statements can become too terse (fragments), or too verbose. “Verbose” can be any of these:

Too wordy, but the statement is still just one requirement
More than three lines long.

A statement that is longer than three lines of text is not always verbose, but verify!

Are the business requirements written in non-technical language?

Is the text understandable to a business person and understandable by an independent third-party? The problem isn’t just a missing term in the glossary; if the requirement is jargon infested, the BA author should revise it for the benefit of mere mortals.

If a requirement needs specific business knowledge to understand, will the people who implement and/or test the requirement have that knowledge?

If not, the BA author may need to provide more information in the requirement, or explanatory text along with the requirement.

Are the requirements constructed to reduce the possibility of more than one interpretation?

If not, does the requirement need more detail to limit it to a single interpretation, or should there be a set of related requirements to reduce the likelihood of ambiguity?

Does each requirement address a single concept, topic, element, or value?

It takes a clever BA to decompile a complex idea and turn it into a requirement. The result of the first attempt may be an overloaded requirement, i.e., a single requirement that is actually more than one requirement. Look for requirements that have more than one relative clause, more than one instance of a semicolon, or the frequent red flag, more than three lines of text. These attributes are often indicators that the requirement needs to be split up into a set of multiple-but-related requirements, each with their own identifier, e.g., Security-011a, Security-011b.

Are requirements statements distinguishable from the explanation that often follows a requirement?

Sometimes a requirement needs an explanatory note, that is, text that is supplementary to the core requirement. Be sure that the note is separated, even by a blank line, from the core requirement so that it is clear which statement is the requirement and which is the explanatory note. Notes should not have the telltale “shall” verb.
Sometimes the explanation is a design constraint. Design constraints need to be assembled in their own section such as an appendix section for design constraints, or, at the very least, listed in the Assumptions.

Testable, Verifiable

Are the requirements verifiable by testing, demonstration, review, or analysis?

Do the requirements have success criteria, and a metric that specifies the success threshold?

“I’ll know when I’m happy” is not an acceptable evaluation criterion!

Key, high priority requirements need explicit success criteria and/or metrics. Lower priority requirements or very detailed requirements may have implicit success criteria.

Are the criteria for a “pass/fail” evaluation clear and quantifiable?

An example of a clear evaluation criterion is a named process that a human or a machine can execute to verify the requirement has been met.

If the success criteria/metrics for a requirement are known, is that information associated directly with the requirement?

Sometimes the success criteria/metrics get separated from the requirement, e.g., in another section of the document. Use cross-references or some other means for the reader to put the two together.

Are the requirements free from weasel words? (see BA Times article http://www.batimes.com/component/content/article/106-articles/377-bad-ass-ba-caution.html)

Weasel words will be the ruin of the project.

Business-Critical Dates

Are timing constraints such as due dates, deadlines, and completion-date dependencies identified?

Are the “critical” dates truly critical?

There are many ways to define “critical to the business”. It is important to distinguish “critical” and “important”. In my humble opinion, there are four types of truly “critical” dates:

Beyond this date there will be an impact on revenue generation
Beyond this date we will lose the ability to conduct business
If we miss this date (which we announced to the media) we will be subject to ridicule and derision in the press which will drive our stock price into the ground
If we miss this date we will be subject to contractual or regulatory sanctions, such as a monetary fine. For example, being out-of-compliance, or a real estate lease date expiring, or a contractual completion date not being achieved.

Are the “important to customer” dates articulated?

Even if the date isn’t “critical” by the definition above, a date can be important to the customer and should be identified as such so that the project manager knows about both the date and the expectation.

3rd Parties and Partnerships

Are the major requirements identifying the need for information to be shared, processed, or stored by 3^rd party partners or hosted applications?

Compliance

Are compliance requirements identified?

Compliance requirements often first appear as an assumption. Assumptions can be overlooked during design and implementation. Calling out a compliance requirement ensures that the project test plan will have a line item for verification of compliance. Examples of compliance are data privacy (Personal, Identifying Information (PII)), payment card industry (PCI), legal, financial, and governing entity policy compliance.

If the project does not have any compliance requirements or impact, is that made explicit?

Adding the statement, “This project do not have any compliance requirements.” is better than just leaving the Compliance section of the document blank, which looks like the author forgot something.

Business Communication Processes

Are the major requirements related to supporting business communication processes included?

If the project is going to have an impact on how users do their work, in terms of what they see or what they do, then there needs to be a communications plan. The BA author may think that it is overkill to have a requirement for a standard project deliverable but the manager of the group that provides end user support may see things differently.

Internationalization and Localization

Are the major requirements related to internationalization and localization included?

Internationalization, known as I18n (meaning “I – eighteen letters -N”) to people who do this for a living, is the process of planning and implementing products and services so that they can easily be adapted to specific local languages and cultures. Doing the work of translating the text into local language and culture is called localization, aka “L10n”.

Timing / Response

If time-critical functionality is known when the requirement is written, is the time-criticality identified, and are timing criteria specified with metrics?

A requirement for “fast response” isn’t testable! “Fast” compared to what? Is less than 10 seconds acceptable? Is less than 2 seconds acceptable?

Reporting

Is there a requirement for creating a report to show progress towards achieving the projected return on investment (ROI) on the project/product?

According to best practices, a requirements document should have a business case. That business case identifies the expected ROI for the work that will be done. For the project to be truly successful, it needs to produce the evidence for delivering on the ROI claim.

Are the reports/dashboards/extracts that are expected from this project identified?

Are the audiences for those reports/dashboards/extracts identified?

Unknown, Missing, Incomplete Requirements

Are requirements where information is unknown, missing, incomplete or “to be determined” (tbd), annotated with a reason for the incompleteness?

Some BRD templates have an “Open Issues” section were unknown, missing, incomplete or “still under discussion” topics are called out. Ideally each issue has the following information to help the BA close the issue:

A unique identifier for the Issue, this could be as simple as “Issue.1”
A description of what the issue is
The date the issue was first identified
The name of the person responsible for resolving the issue and a target date for that resolution
A status for the issue, e.g., Open/Closed/Deferred. Seeing a column of “closed” issues is so satisfying.

Requirements Statement Style

Do the requirements statements use one verb consistently, e.g., shall or will?

Are the requirements articulated at a consistent level of detail?

Should any particular requirement be specified in more detail? In less detail? It is important that each requirement be stated at an appropriate level of detail, and that all the requirements in a given document be at the same level of detail.

Is level of information in the document consistent with commonly accepted practices for your company?

Each company has its own rules for the level of information that should be included in a requirements document. If your company doesn’t have a guideline, here is a possible starting point:

A Business Requirements Document has project-level requirements that describe the needs of the Stakeholders.
A Functional/Non-Functional Requirements document has requirements at the software system level and may include requirements at the subsystem-level.
A System Requirements document has even more detailed requirements.

Do the requirements statements use the “Trigger Actor Action Condition” syntax?

Requirements in the form of “Ability to …” are ambiguous unless there is a context-setting statement that all requirements describe who or what the actor is. Requirements must identify the actor as a human or an automated agent. “Ability to …” statements create problems because the reader has to guess at whom or what will have the ability.

Consistency of Requirements

Have inconsistencies, omissions or redundancy been identified and corrected?

Do requirements use consistent terminology to the same object?

It is normal for different groups within a company to have different terms for the same object. For example, in the United States what we call “regulations” may be called “rules” in Europe. It is important to identify both terms in the document’s glossary. Use one term consistently in the requirements.

Have requirements that describe two or more actions that conflict been identified?

The most common types of conflict are logical conflict and temporal conflict.

An example of logical conflict is when there is a general requirement for a “green” system, specifically, no printing, and, a conflicting requirement for the automatic generation of the quarterly sales results report to be faxed to the executives in Japan. An example of temporal conflict is when one requirement says that customer satisfaction data will be sent to an FTP site on a weekly basis and another requirement says that customer satisfaction data will be uploaded and processed on a daily basis.

Once such requirements have been identified, there are two possible ways to proceed. Either have the stakeholders come to an agreement, or, create an Open Issue to address the conflict as part of the design effort.

Requirement Traceability

Are all requirements traceable to at least one “in scope” objective?

Do all objectives/success criteria map to at least one requirement?

If not, there may be a gap in the body of requirements.

Common problems with Categories of Requirements

Do the requirements statements in the categories actually belong in those categories?

UI requirements are really good at hiding in a category other than a User Interface category.
System Interface requirements are often distributed throughout a BRD. Assembling interface requirements in one place makes it so much easier to understand what a project need is. Or, if there is a good reason for not moving the interface requirements from their functional category, give the technical team a reason to appreciate the BA by suggesting a table of Interface cross-references so that at least there is a logical assembly.
Be sure to distinguish internal interfaces from external interfaces. In some companies interface requirements are documented in a separate Interface Requirements Document (IRD) or Interface Control Document (ICD)

Are scope statements, assumptions, business rules and role/responsibility statements in the right category?

Sometimes a statement begins life as a requirement but over the course of revisions, it evolves into something different such as scope, assumption, business rule, or role/responsibility statement.

If there are interface and integration requirements, are they in separate categories?

Business people often use the terms interchangeably. The technical team knows there is a big difference!

Did you answer “yes” to the all the questions? If so, do you now believe in your heart that the requirements are good? If not, mark the requirements that need work and identify what your concern is.

If one or more of these items is not checked, there is some risk that the requirements are inadequate. Your mission now is to convey these “defects” to the BA author in a kind manner. If you are expected to return written feedback, take time to explain what is missing, and provide examples, if possible. If you will be participating in a structured walkthrough meeting, make notes of what you want to say so that your comments are thoughtful and constructive.

The document should not be seen by the customer or stakeholders until the problems are fixed. If the requirements are good, you can now move on to the last quality check, the good housekeeping check.

This is the third of four articles addressing Use and Profit from Peer Reviews of Requirements Documents

Business Case Synchronicity Check
Requirements Document Sanity Check
Requirements Statements Content Check
Requirements Document Housekeeping Check [December, 2009]

Don’t forget to leave your comments below

Cecilie Hoffman is a Senior Principal IT Business Analyst in the Business Analysis Center of Excellence, Symantec Services Group, 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 balsamfir.com. She can be reached at [email protected].

Rebecca Burgess is the Business Process Methodology Analyst in the Commerce Lifecycle Transformation Office at Symantec and a Certified Six Sigma Black Belt. After many years of uncovering problems and determining root causes in software, she is now applying her BA skills to strategic process design and improvement. She can be reached at [email protected].

What do BAs “Do” within Agile Teams?

Written by Robert Galen on November 10, 2009. Posted in Articles.

For the past several posts, I’ve been focusing on user stories within the context of agile teams-how to write them and the role they play in agile development. This month I wanted to switch gears a bit and talk about the role of the BA within agile teams.

The first point I really want to make is not BA role specific but focused towards the general role of the agile team member. You see roles need to become much less clear or constrained within agile teams. Sure, a developer is still a technical role and will be mostly writing code, but that doesn’t mean it’s the only thing they can and should be contributing to the team.

There’s quite a debate in the agile community about generalists vs. specialists as team members. Clearly the more general you are, for example a tester who can write or read code or a BA who can test, the more flexible your contributions are within the agile team.

The pushback within the community is based on folks taking this idea to its (unintended) extreme, for example developers who believe we’re asking them to morph into full-time testers or vice versa. So, in general, pun intended, you should not view yourself narrowly as a business analyst, but more broadly as a team member who has strong requirement analysis skills against an even broader back-drop of capabilities that you often bring to bear within your team.

So, what specifically is the BA role within agility?

It starts out the same as it does in your existing role. You are a customer advocate and liaison. You have tremendous experience in the analysis and capture of critical system requirements. You have broad collaborative and observational skills. Often, you sit down with a wide variety customers, stakeholders, and constituents and gather and define requirements from a wide variety of angles.

But within agility there is so much more you can do along the lines of the following:

Product Backlog Partner. Clearly the BA role focuses on requirement definition & refinement. Using Scrum as our terminology backdrop, it implies working closely with your product owner, customers, and team members to construct and refine the backlog. Remember, in the agile methods all work should be defined on the backlog, so it’s not simply feature-based. You need to be comfortable defining user stories that represent task work as well.
Fostering Team Collaboration. BAs often become a liaison between the product owner (customer) and the team. They foster an inclusive view that brings team members together to better design and build customer-focused solutions. The methods sort of oversell collaboration as a natural occurrence. I have the view that it needs to be encouraged and often championed. BAs can clearly serve as this champion of collaboration amongst team members. I’ve often seen BAs adopt a facilitative role within their teams, facilitating effective meetings, information sharing, and problem solving.
Driving Quality. Working with your product owner and testers, you help to define, refine, and even execute user story-centric acceptance tests. Often, you’ll view the execution of features from a more holistic, end-to-end usability view that is so important to the customer. Verifying that the software is as simple as possible while still meeting the customer’s usability and core expectations.
Maintaining a Value Focus. Taking a page from Lean Thinking, the agile methods are extremely value and cost centric. Often you’ll see Scrum teams that focus not only on priority to determine what is worked on first, but they also try and determine the value (ROI) for a given feature set. BAs can often help facilitate this value-based analysis between team and customer. They can also help guide the team towards Minimal Marketable Feature sets (MMFs) that implement predetermined value, delivering early and often.
Demonstrating Results. As a full-time member of your agile team, your true focus is towards delivering small slices of end-to-end functionality at the end of each sprint. Be willing to serve as a voice of your team in these demonstrations. Truly understand how the delivered software works and how to effectively demonstrate its value. Don’t be afraid to step into the limelight and demonstrate working code as part of each sprint review.

Often I think of the US Army recruitment commercial, “Be All You Can Be”, when I think of roles with agile teams. As an Agile BA, you should grow your skills horizontally and fearlessly contribute wherever you can within the team. Your teams and customers will value you for it!

Don’t forget to leave your comments below

Robert ‘Bob’ Galen is the President and Principal Consultant of RGCG, L.L.C. Bob has held director, manager and contributor level positions in both software development and quality assurance organizations. He has over 25 years of experience working across a wide variety of software technology and product domains. Bob can be reached at [email protected].

Gather Trust then Requirements

Written by Elizabeth Larson on November 3, 2009. Posted in Articles. 1 Comment on Gather Trust then Requirements

Co-authored by Richard Larson

One of the most difficult phases in project management is gathering business requirements from stakeholders. Requirements are often vague because it is difficult for customers to articulate their needs before they see the end product. When business customers and the project team have a relationship built on trust, they can work together more quickly to produce a product of value to the organization.

This article explores various ways to build trust in order to gather business requirements more quickly and accurately.

Solving Business Problems with Requirements

Before the requirements can be gathered, either formally or informally, it is important to discuss the business context of the project with the sponsor. Requirements need to be aligned with the organization’s overall vision and strategic direction. They must link to business goals and objectives. Keeping the vision in mind helps focus the team and helps reduce decisions based on personal agendas.

Initial meetings with the sponsor to discuss the business and project vision, as well as the business problem(s) can be a helpful way to establish rapport and begin to build trust. Focusing on the business need and vision demonstrates business acumen, which in turn builds respect, and leads to trust.

Elicitation Techniques that Can Help Build Trust

There are a variety of techniques that are typically used in requirements elicitation. Below are two:

Facilitated Requirements Workshops.

One of the most common is the facilitated requirements workshop, in which a facilitator enables key business stakeholders with differing needs and expectations to articulate their requirements. Part of this process encourages conflict by purposefully getting different opinions and perceptions out on the table before bringing the group to consensus. When a trained facilitator creates a safe environment, participants can provide their input without fear of rejection. When they start to feel that their input is valuable and valued, they can build relationships and trust with each other. The safer participants feel, the more likely we are to get complete requirements.

One-on-Ones.

Another common elicitation technique is the one-on-one interview. This technique is a way for business analysts and project managers to meet individually with stakeholders. Through these individual meetings trust can be built in several ways:

Assess Commitment. Some stakeholders do not like to make decisions or agree to decisions in meetings. One-on-one meetings provide a safer venue to discuss real needs behind the stated-and unstated-needs.

Address individual Concerns. Some individuals are more inclined to reveal their true concerns about the project and the other project stakeholders in one-on-ones rather than in large groups. When elicitation is limited to facilitated workshops, these concerns can go largely unaddressed.

Address Negative Behavior. Sometimes stakeholders either dominate meetings or demonstrate various types of disruptive behavior that negatively impact the group. By meeting individually, analysts and project managers can focus on the behavior and, together with the individual, determine ways to reduce its impact.

Each individual meeting is a chance to establish rapport and ultimately build relationships and trust.

Barriers to Elicitation

Distance of Stakeholders. In the ideal world all key stakeholders would be based in the same room or section on the same floor in the same building. The further removed the business experts and sponsors are from the business analyst and project manager, the more effort it requires to build and maintain good relationships, and the more difficult it is to collect requirements. Teleconferencing, video conferencing, and net meetings can be used for elicitation, but each presents significant challenges that make the process cumbersome. Scott Ambler, in his Agile Adoption Survey, found that dispersed agile teams while still highly successful, were less so than co-located teams.¹ If we can be co-located with a full-time key business subject matter expert (SME), we can build trust far more easily.

Cumbersome Process for Collecting Requirements. Those of us who have built a house know that our requirements change. In the beginning we have a vision of the kind of house we want to build, but rarely can we articulate all our detailed requirements at the first meeting with the architect and builder. This is true for all business requirements, regardless of the project size. Complexities arise when different stakeholders have different requirements that must be reconciled and finalized. If we expect to collect all our requirements before designing and building our end product, we will probably not be successful. However, if we expect that the business will change and that requirements will change, and if we collect our requirements iteratively, we have a greater chance of meeting expectations, thus building solid relationships with the business stakeholders.

Project Misalignment with Corporate Objectives and Goals. When this happens, executive support and stakeholder availability tend to evaporate. Poor or late attendance at meetings, coming to meetings unprepared, and unanswered voicemails and emails are all symptoms.

Lack of Understanding of the Political Landscape. Business analysts and project managers who begin projects without having a clear picture of the political landscape will struggle, and the project is likely to take longer than expected. We may think that SMEs are providing their requirements, but the “Oh, by-the-ways,” or “Did I tell you that-that’s not right,” or “what I really meant was…” creep into the discussions.

Distrust. The most common reason for stakeholder caution and concern is distrust, caused by one or more of the following:

Fear that the end product, such as a new system, will dramatically change or eliminate their jobs
Fear that the end product will impede or slow their workflow in the name of trying to improve it
Fear that familiar software (ex. existing system or Excel spreadsheets) will be replaced by a system or process that is incomplete, inaccurate, or difficult to learn

Without an established relationship and trust, it will be very difficult for business analysts and project managers to elicit the necessary requirements.

Building Trust

Trust usually takes time to develop. The further away people are from each other, the harder it is. We may initially trust or not trust those involved on our projects, based on past experience, personal filters, culture (organizational, geographical, and otherwise), and a wide variety of factors that can influence our judgment. Business analysts and project managers don’t always have time to let relationships develop, so here are some things that can be done to build trust quickly:

Communicate Bad News. When the project is behind schedule, when it needs more resources or when lack of stakeholder participation is slowing the project, it is important for project managers and business analysts to address these issues with the sponsor and other appropriate team members.

Encourage Laughter. There is a strong relationship between laughter and trust. Having fun in meetings and laughing appropriately (not hurtfully) even under pressure builds a sense of team solidarity and a desire to work together towards the desired project outcome.

Define Clear Roles and Responsibilities. When not defined, not only do tasks overlap, but they more commonly fall through the cracks, which invariably leads to finger-pointing, blame, and lowered morale. Clear definition helps prevent territorial squabbling and decreases the chance of misunderstanding and subsequent project delays.

Be Competent and Credible. We lose trust quickly if we shoot from the proverbial hip, if we continually provide incorrect information, if we don’t communicate effectively, or if we set our own self-interest above the organization’s and the team’s.

Be Courageous. As project professionals, project managers and business analysts need to be trusted advisors. We need to point out risks, even when the organization typically shoots the messenger. We need to make recommendations. We need to ensure that the business takes ownership. These are not easy to do, but they are necessary to building trust.

Maintaining Trust over Time

Once trust is established, it can lead the team members through project difficulties. However, once broken, it cannot easily be regained. Some common trust breakers include:

Disclosing Confidential Information. While we do want to encourage open communications, we cannot disclose confidential information given to us. It is acceptable to tell the inquirer that the information is confidential. It is also acceptable to set up initial communications guidelines.

Creating a Competitive Environment. Competition by its very nature produces winners and losers. While some stakeholders can be positively charged by competition, others may view competition with resentment and even anger, leading to a weaker relationship. Collaboration has proven a key to many successful projects.

Communicating within a Hierarchy. When we keep the entire team informed, we reduce the likelihood of gossip, speculation, and low morale.

Micromanaging. Hovering in its various forms can give the impression that the micromanager does not trust the person being micromanaged. In turn the person being micromanaged will also develop a mistrust of the micromanager.

Failure to Make Decisions. Being indecisive can be destructive for a team looking for leadership. Being decisive does not mean making all the decisions or being authoritarian. It does mean taking appropriate action to resolve real issues, remove project barriers, and move the project forward.

Gathering Requirements = Relationship Building

Requirements elicitation requires building relationships and trust among the project stakeholders. When trust is absent, the requirements elicitation process will take longer, be incomplete, and will generally become an unpleasant experience for all concerned. Although building relationships takes time and effort, it can actually shorten project time and result in improved project performance.

1 http://www.modernanalyst.com/Resources/Articles/tabid/115/articleType/ArticleView/articleId/536/Agile-Business-Analysis-Interview-with-Scott-Ambler.aspx

Don’t forget to leave your comments below

Elizabeth Larson, PMP, CBAP and Richard Larson, PMP, CBAP are Co-Principals of Watermark Learning, a globally recognized business analysis and project management training company. With over 30 years of industry experience each, they have used their expertise to help thousands of BA and PM practitioners develop new skills. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).

Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. With academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. They can be contacted at 800-646-9362 or at www.watermarklearning.com.

12 Rules of Delegation for Business Analysts

Written by Richard Lannon on November 3, 2009. Posted in Articles.

Delegation is one of the most important skills. Business analyst team leaders and other technical professionals, managers, and executives all need to develop good delegation skills. There are many rules and techniques that help people to delegate. Good delegation saves money and time, builds people and team skills, grooms successors and motivates people, and leads to successful projects. Poor delegation sucks! Ask any employee. It causes frustration, demotivates and confuses people and teams. It is important to develop good delegation skills.

These 12 rules of delegation should help you out.

Delegation is a two-way street. That’s right! Delegation is meant to develop you and the people you work with. Consider what you are delegating and why you are delegating it. Are you delegating to build people, get rid of work you don’t like to do or to create an effective team?
To be a good delegator you need to let go. You can’t control everything so let go and trust the people you work with. Hand over those tasks to other people that are stopping you from reaching your full potential.
Create a delegation plan. Use a delegation matrix that shows your people and the main task components and how you can develop your people and get the work done. This will help your people understand the expectations being set.
Define the tasks that must be done. Make sure that the task can be delegated and is suitable to be delegated. Some things you have to do and others can be done by someone else. Be clear on what the task is and is not. People like clarity when being delegated to. So ensure you are clear. If you are not clear your people will not be and you will be disappointed. Worst, your people will feel like failures. Not cool!
Select and assign the individual who should take on the task. Be clear on your reasons for delegating the task to that person. Be honest with yourself. Make sure you answer the question what are they going to get out of it and what are you going to get out of it? Think of it as listening to the radio station WII-FM (what’s in it for them). It’s a good motivator.
Make sure you consider ability and training needs. The importance of the task may need to be defined. Can the people you’re considering do the task? Do they understand what needs to be done? If not, you can’t delegate it to them. If resources are an issue, sit your team down and move things around or develop a mentoring-support program that enables your people.
Clearly explain the reason for the task or work that must be done. Discuss why the job is being delegated and how it fits into the scheme of things. Don’t be afraid to negotiate points that are discussed when appropriate. Don’t say it is because we are told to do it. For your people to own the task you must own the task. Reframe and rephrase it so you have ownership.
State the required outcomes and results. Answer questions like what must be achieved, what the measurements will be, and clarify how you intend to decide that the job was successfully done.
Be prepared to discuss the required resources with the individual and team. Common challenges arise with every person and team including people, location, time, equipment, materials and money. These are important concerns and should be discussed and solved creatively. However, sometimes it is simply as it must be done. Be prepared.
Get agreement on timeline and deadlines. Include a status reporting feature to ensure things are getting done. When is the job to be done? What are the ongoing operational duties? What is the status report date and how is it due? Make sure you confirm an understanding of all the previous items. Ask for a summary in their words. Look for reassurance that the task can be done. Address any gaps and reinforce your belief in the individuals or teams work. They need to know you trust them.
Remember the two way street, well it is most likely a multi-directional intersection. Look around and support and communicate. Speak to those people who need to know what is going on. Check your stakeholders list and make sure you inform them what the individuals’ or team’s responsibility is. Do not leave it up to the individual team member. Keep politics, the task profile and importance in mind.
Provide and get feedback for team members. It is important that you let people know how they are doing and if they are achieving their aim. Don’t get into blame-storming. You must absorb the consequences of failure, create an environment where failure is an opportunity to learn and grow and pass on the credit for success. Pay it forward if you can.

Delegation used as a tool develops you and your people. The better you are at delegation the better the people around you and your teams will do. It is part of command skills and should be used to let go and trust in your people. The difference between success and failure is often a matter of letting go and delegating.

Don’t forget to leave your comments below

Richard Lannon works with those people, organizations and enterprises that want to identify what’s important, establish direction and build business skills that will positively impact their bottom line. He can be reached at [email protected], 1-866-559-8126, www.braveworld.ca

The Future of the Business Analyst

Written by Keith Ellis on November 3, 2009. Posted in Articles. 1 Comment on The Future of the Business Analyst

Many of us are in that crucial planning point of the year when we’re looking forward to what our key initiatives will be for 2010, and with this forward-looking mindset, I thought it might be fun to look forward 10 years or so and speculate on the future of the Business Analyst. Violently agree or disagree if you will with my thoughts – I think the important issue is to create a dialogue, and get people talking.

In a prior life, I spent almost 10 years as an executive at a technology trend forecasting firm. A few bits and pieces to share with you from that experience:

People tend to overestimate change over the short term, but under-estimate the impact of systematic and continuous change over the long term. In 2000, the Internet flurry created an unsustainable bubble founded on short term profit belief. Now, ten years later, the revenue, profitability and transformative effect of the Internet is generally acknowledged.
Every few years, a different wave of focus will come along which re-energizes a concept. Time and motion studies became re-engineering which is kind-of-like SOA and enterprise architecture.
Modernization never really happens… or more accurately, as soon as you modernize, you’ll need to do it again. Mainframe, Mini, client-server, SAAS, Cloud.
Devices gain way more intelligence.
The pace of change accelerates.
We figure out how to do more with less.
People find more ways to communicate, socialize and build community.

Here are my, out-on-a-limb predictions; and I’d encourage you to put your own out there. Let’s look out over the next 10 years. By 2020:

Requirements practices will mature amongst F1000 companies dramatically. This will further fuel the ‘professionalization’ (if I can make up a word) of the analyst function. We’ll see a dramatic rise in performance expectations of individuals and the analyst function. Over the last three years I’ve seen huge strides forward in this area, but I think it will still take a few more years for us to start hearing CEOs talking about business requirements and business analysts in the same sentence as they use the words strategy and competitive advantage.
I think you will see a sub-group of this F1000 that are differentiated in their ability to get more successful, technology-based products and services into the market, faster. With this group, the requirements function will play a big role. We’ll see far more examples of ultra-high requirements maturity organizations and see public stories that showcase the impact of continuous optimization.
Technology for analysts will become much more holistic and cover the spectrum from scoping and elicitation through to QA. The technology will also be more SDLC method independent, so that analysts can accommodate more domains of analysis. Today’s tools tend to be fairly task-specific and limited to one of process flow, or data flow, or managing structure statements of system capability, or modeling, or stakeholder communication, or system visualization – or – they are locked to a specific layer in the requirements life cycle. Task oriented tools are fine, but I think we’ll see an explosion in new players in the market before a rationalization occurs by the time we get to 2020. The winners in this will provide analysts with a well-rounded capability across all those elements above in a well-rounded tool-kit and tight integration into both other layers of the SDLC and other critical change functions. IAG already tracks over 100 tools principally designed for analysts at IAG – in the near future, we’re going to see many more.
Establishing business requirements will take far less time. Dare I say a fifth of what it is today. What you did with stakeholders over half a year, you’ll be accomplishing in a month on average? Why is this important? I think application complexity will continue to rise, I think organizations will continue to remain flat, and analysts will have to respond with far more efficient mechanisms for engaging essential stakeholders, if they are to achieve their objectives.
I think you’re going to see more expansion in the analyst role definition, greater centralization in the organizational specialists that play these roles, and more fusion between business analyst, project manager, portfolio manager, change management and business architecture roles. Business transformation is a strategic function that companies will continue to optimize. We may see this function within the business used as an incubator for developing senior executives.
We’ll see at least two major shifts in SDLC and another two in IT infrastructure/architecture. In five years, will we be talking about Agile – or will we be talking about something else that looks even more promising and scalable. Ten years from now, pundits may be shouting “Scrum is dead” and “cloud computing is the way of the past”. I think organizations may increasingly decouple requirements practices that set need from these other areas which deliver on the need. All analyst methods, project manager practices, SDLC disciplines have techniques that are solid and can be applied within the analyst function regardless of the SDLC is in place. I think you’ll see fewer ‘purist’ shops, and more ‘practitioner’ shops that have a strong framework in place – and adapt new ideas into it, rather than making wholesale changes to the framework.
If I were a betting man, I’d say we’re going to see a massive upswing in the collaborative nature of the BA role. I think Agile is the first of many ‘team-centric accountability’ models for development. If we go into the future and envision an Agile 2.0 somehow harmonized with Plan Driven 9.1 the key to success in that world would be managing controlled and efficient collaboration of business needs on a more massive and virtual scale. Rather than three people in a Scrum, how about 100 in a Scrum 2.0? This would require tremendous skill, automation and collaboration on a scale we’ve not seen yet.
We’ll see greater virtualization, globalization, and automation in mundane analyst activities. As the importance of the activity rises, so too will pressure mount on the function to scale at a lower cost by off-loading non-strategic activities to other delivery channels.
We’ll see ‘twitter 2.0’ and a future generation social media/information sharing technologies integrate themselves into the analyst function.
We’ll see a reemergence in focus on data and how information moves within organizations. From my perspective, this one is getting a little lost in the shuffle and there is lots, and lots of room for improvement.
You’ll have ten more years to gain wrinkles and grey hair… and, by then, someone may have figured out a pill to deal with that.

The BA role has always struggled; it has responsibility without authority. This will never change. As a result, the optimal model for any particular business will continue to swing between centralization and decentralization as businesses wrestle to establish the business analyst role in the value chain. What I think will eventually break this gyration is the economic concept, ‘specialization of labor’. Specialized work-forces are more efficient. What we may see emerge is a more specialized class of very high value BA which the business recognizes has an integral role in the value chain. What happens to the lower value roles, and less specialized team members? These are likely vulnerable to globalization, automation, cost reduction, and the whims of SDLC focus.

Who knows what the future holds – I certainly can’t predict it. I think that in speculating on what this function looks like 10 years from now, there is an opportunity to think about what is strategically valuable in the function today. I also think, while some organizations may be decades away from being able to achieve this vision, some of you are already well along the path.

The future is closer than you think!

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.