Martin's BA Blog!

I just saw Noah Dawson’s blog on WizIQ that professors should be SMART. Now as a professor, I was immediately intrigued. After all, I think of myself as being “smart”. Then, the capitalization of SMART got my BA side going: SMART = specific, measurable, etc…

Hmmm… I read his well written blog and it was about professors using SMARTBoards — you know the one’s that act as giant interactive touch surfaces. In fact, I use them myself when I delivery seminars and workshops — good stuff…

But, then it got me thinking. Maybe professors (and teacher, presenters, instructors) should be SMART — Specific, Measurable, Achievable, Relevant, Testable.

In fact, I would say that all presenters (including professors) should be:

• specific in what they say
• should state ideas that can be measured (or “proven”)
• ask for for work that is achievable
• present what is relevant to the topic at hand, and
• make the ideas testable.

But, I do agree with his conclusions: presenters (and most definitely professors) are often too lazy to leverage all the resources they have at their disposal. Let’s be honest, building and delivering an interactive, engaging, and insightful presentation is difficult and exhausting; I guess to many presenters have more important things to do…

Understanding and managing the stakeholders is a critical activity in successful project implementations and other initiatives. It is performed as soon as a business need has been recognized. It is a continuous effort that occurs throughout the initiative’s lifecycle.

Definition

A stakeholder is any person, group, team, or internal or external organization that is affected by the initiative, has influence over it, or is involved in constructing, deploying, or managing the solution.

Analysis Dimensions

Stakeholders should be evaluated along a number of dimensions:

• Position within the organization
• Role and responsibilities on the project
• Needs, expectations, and requirements
• Success criteria that they will use to judge the outcome of the initiative
• Communication needs
• Influence on the project, solution, or initiative
• Attitude towards the initiative
• Impact of the initiative on their role and responsibilities
• Interest in the project, solution, or initiative

Impact, attitude, influence, and interest can be measured along a scale ranging from positive to negative.

Business Interactions

Stakeholders may not only be individuals but rather may be organizations within or outside a company, such as customers, vendors, suppliers, markets, regulatory bodies, and so forth. They may be teams, groups, or virtual organizations. Therefore, the interactions between organizational units must be defined and described. Such interactions are best visualized through a diagram.

Analysis Process

Stakeholders should be identified early in the project’s lifecycle to ensure that their needs, expectations, and requirements are uncovered, documented, and communicated.

Stakeholders can often be grouped into classes whenever possible to reduce the number of individual stakeholders. For large groups, a representative must be chosen. If no such representative can be found, then a surrogate must be appointed.

During the requirements gathering effort, those stakeholders affected by or with input to the requirements must be consulted.

Evaluating Stakeholders

Stakeholders should be continually assessed along four dimensions:

• Attitude toward the project or initiative
• Influence over the project or initiative
• Impact from the project or initiative
• Interest in the project or initiative

Assessing Attitude

The attitude towards the projects can be supportive or unsupportive. It is determined whether:

• The solution will benefit them personally
• The organization at large benefits from the initiative
• The initiative curtails their power or influence
• They believe that the project team capable of delivering the solution on time
• They think that their input is valued
• There needs are being addressed
• They believe that their collaboration on the project will be supported by the organization
• They might be directly or indirectly punished or disadvantaged by participating in the project
• They trust the project sponsor and business analyst
• They have a good rapport and relationship with the business analyst and project manager
• They believe that the team members value and appreciate their participation

Analyzing Attitude

For each stakeholder, the business analyst must ask himself or herself from the perspective of the stakeholder:

• Personal Benefit: There has to be a positive benefit to the stakeholder for them to be engaged; if there is no benefit, the stakeholder is less likely to participate in workshops, volunteer information, remain engaged throughout the lifecycle, and generally support the project.
• Personal Threats: A solution, project, or initiative that somehow threatens the stakeholder affects their attitude negatively. For example, a stakeholder who loses their job or loses influence or power will be less supportive of the project.

Assessing Influence

The influence wielded by stakeholders on the project or initiative can range from strong to weak. Influence is determined by factors such as whether:

• They can affect funding, make decisions affecting resources, or exert influence over others in power to make funding and resource decisions
• They have authority to allocate funding or resources or cause others to do so
• They can sway the project sponsor
• Have sufficient influence to effectively affect a project’s funding, resources, or organizational support
• They can positively or negatively affect the attitude of other stakeholders
• They have domain knowledge or subject matter expertise that is critical to the project

Assessing Impact

A project may impact a stakeholder positively or negatively. Impact on the stakeholder is determined whether:

• The project benefits them or their immediate organizational unit
• They gain or lose power or influence within the organization

Assessing Interest

Stakeholders may be more or less interested in a project or initiative. Their interest is influence whether:

• They will directly benefit from the project
• They respect and trust the project team
• They believe that the project team will deliver the solution

Monitoring Attitude, Influence, Impact, and Interest

The four dimensions of stakeholder analysis can be mapped in a number of different two-dimensional matrices in order to better understand the relationships and how the stakeholder needs to be managed. This can be an invaluable tool in stakeholder communication planning and in how much “care and feeding” is necessary for a specific stakeholder or stakeholder group.

Next time, we’ll look at some techniques for mapping stakeholders and using that to determine how to manage them. So, stay tuned…

How do you monitor and evaluate your stakeholders?

In this blog we’ll take a look at requirements, particularly the different types of requirements described in the BABOK(r), and how to write them to be effective for implementation and testing. Let’s start by defining what a requirement is. Simply put, a requirement is a feature that a product or service must have in order to be useful. For example, two requirements for a customer relationship management system might be to allow users to update the payment terms for an account and to add new customers.

The IEEE Glossary of Software Engineering Terminology provides a more precise definition. The same definition is also used by the BABOK®. Both define a requirement as a

1. condition or capability needed by a user to solve a problem or achieve an objective.
2. condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed document.
3. documented representation of a condition or capability in (1) or (2).

Not all requirements are expressed at the same level of detail and specificity. Some might be high level requirements expressed by the business sponsor (e.g., reduce the cost of invoicing customers) while others might be very specific requirements that describe a function needed by a particular user (e.g., allow me to click on a customer name and then display that customer’s account history).

Requirements Classification

The BABOK® defines the following requirements types: business, stakeholder (or user), functional solution, non-functional (or quality of service), solution, constraint, and transition. Note that these terms are overloaded and have different meaning in different organizations. For example, a stakeholder requirement is often referred to as a business requirement in some organizations and a business requirement is sometimes called a business goal or project objective. Functional solution requirements are also often called technical requirements, detailed requirements, or system requirements. So, it is important to understand the semantics of the terms being used.

Business Requirement

A business requirement is a higher-level requirement that defines a business objective or goal for the project or initiative. For example, a business requirement for installing an asset-tracking system at a University might be to “reduce theft or misplacement of fixed assets by 10% each year.”

Business requirements describe the reasons for initiating a project. Each stakeholder requirement must be traceable back to a business requirement in order to be considered in-scope.

Stakeholder Requirement

A stakeholder requirement defines the need of a particular stakeholder, such as a project sponsor, end user, or regulatory body. These requirements are commonly defined through use cases as they describe how a stakeholder intends to interact with the solution. Stakeholder requirements define product features. For example, a stakeholder requirement for an asset-tracking system at a University might be to “allow IT Specialists to record fixed assets.”

Solution Requirement

Solution requirements describe specific characteristics of the solution both in terms of functionality and quality of service. Solution requirements are sub-classified into functional and non-functional requirements.

Functional Requirement

Functional solution requirements define details of the expected behavior of the solution. For example, a functional solution requirement for an asset-tracking system at a University might be to “display each asset’s ID, description, acquisition cost, current location, previous locations, and current responsible party.”

Non-Functional Requirement

A non-functional solution requirement defines a quality of service requirement such as those relating to speed, response time, throughput, usability, security, privacy, availability, and so forth. For example, a non-functional solution requirement for an asset-tracking system at a University might be to “display an asset’s current location and responsible party within 2 seconds after having its QR code scanned 90% of the time.”

Transition Requirement

Transition requirements express how the solution will be placed into service and how to transition from the current state of the organization to its future state. These requirements, unlike the others, are temporary and require that the solution exist. For example, a transition requirement for an asset-tracking system at a University might be to “enter asset information from the current file records into the asset-tracking system through manual data entry.”

SMART Requirements

Writing requirements that follow the SMART template is a good starting point. SMART requirements are specific, measurable, achievable, relevant, and testable. Note that there are alternate but equally valid definitions of SMART used in practice. SMART requirements apply equally to functional as well as non-functional (quality of service) requirements.

Specific

A good requirement is specific and does not rely on generic or vague terms and descriptions. It should be precise enough to avoid being misinterpreted and be non-compound. In other words, a requirements definition should state a single requirement, so conjunctions such as “and”, “or”, “except”, and so forth should be avoided. Split the requirement into several requirements if necessary.

Measurable

The requirement must specify a metric that can be measured. Common metrics are time, performance, response time, volume, and so forth.

Achievable

The requirement must be attainable; in other words it cannot state a condition or capability that cannot be implemented.

Relevant

The requirement must address some need and must be traceable back to a business objective. It must be relevant to the project. This attribute helps manage project scope by only considering requirements that address an actual objective.
As a challenge question ask the stakeholders: “If this requirement were not implemented, would we still be able to achieve all of our business objectives?” If the answer is yes, then the requirement is not relevant and should be considered out-of-scope (or at least low priority).

Examples of SMART Requirements

The online course registration portal shall allow students who register for courses but have an outstanding balance to pay the balance online using one or more U.S. bank issued Visa, MasterCard, or American Express credit cards as long as the outstanding balance is less than $1,000.

The asset tracking system shall allow users authorized to view report to generate an end-of-month report that includes a list of all currently deployed assets along with their last known locations and responsible parties’ full names.

Examples of Poor Requirements

Requirements that don’t meet the SMART guidelines tend to be poor and lead to issues meeting the business and end users needs. Here are some examples of requirements that are not SMART compliant.

The system shall produce a periodic report that displays all assets data.

Why is this requirement poor? It does not specify what periodic means and it wants all data. All is too generic and creating a test for that would be difficult. What should happen if new fields were added to the assets’ records? Would that invalidate that requirement? Can you devise a set of test scenarios that demonstrate that the asset tracking system meets these requirements fully?

The system shall provide immediate feedback when an assets’ bar code has been scanned to indicate a successful scan.

This requirement is poor because the term immediate is impossible to implement. There is always a lag between the time and stimulus occurs (the barcode scan) and an action happens (the lookup of the asset and the display of its data).

So that’s it for now. Tell us, how do you define requirements in your organization and how do you measure the effectiveness of requirements.

Love that quote in Bart Cleveland’s blog about how to keep creativity flowing:

” He said that when he lived up north, he learned quickly that a faucet that was not dripping was the sign of a frozen pipe in the near future.”

We really don’t take enough “time outs” from our daily work grind to step back and think about where we are going and whether what we are doing and how we do it is making sense. I too often hear my client lament that they are overworked and have too much to do. When I ask why they are doing all that, they always seem to reply with “Well, we’ve always done it that way” or “That’s the way we do things around here”. Now that doesn’t seem all that smart to me.

So take a time out once a week for 30 – 60 minutes. Get together with your colleagues that think about what you could do better. Discuss an article or some new set of tools. Get inspired. You may not be able to change your work environment right away, but you will feel refreshed and you never know what you can learn. How about a brown-bag lunch where you discuss some article or review a tool? Or read a book together ad discuss its impact. Love the new book about Steve Jobs by Walter Isaacson — very inspiring and very insightful.

One of the stories that Walter recounts in his book is about how Steve Jobs that said that he “invented” fonts for the Mac because he took a calligraphy course in College which inspired him. That inspiration led to a revolution in desktop user interfaces and created the desktop publishing industry. So learn something new everyday and take some “time outs”. You never know what inspiration you are going to get…

Tell us: have you taken time outs before? done off-sites just to think?

As BAs we need to know where projects originate so that we can pick the right techniques to apply to analysis and documentation. So, where do projects come from? Projects originate from many sources. They can come top-down, bottom-up, from the middle, or from the outside.

Senior management originates project needs based on their strategic goals and directions. This requires the development of business cases and using high-level requirements analysis strategies, such as business use cases, context analysis, and business benefit statements.

Click-level end-users are a frequent source of projects. They encounter problems with a system or a business process during their daily work and based on those complaints they force us to launch projects to repair those defects. Requirements catalogs, use cases, storyboarding, and prototyping work best for those situations.

Middle managers often need information to make decisions. They need reports and dashboards that consolidate data from different sources. For those types of projects use cases, context analysis, and prototyping work best as requirements analysis techniques.

Finally, many projects come from customer complaints, market changes, competitive landscape updates, and regulatory changes. Depending on what the changes are, different requirements analysis strategies will work. Commonly, SWOT analysis, Fishbone diagramming, brainstorming, and prototyping are well suited for these types of projects.

So, know where your project’s coming from — it’ll help you understand where it’s going, who you need to consult, and how to get there…

There is an issue that I’ve heard from my clients consistently over the past few years. It’s that too many Business Analysts (BAs) simply act as “order takers”. They go to the business to get requirements and simply write down what the business says. To them that’s the job of the BA and that’s what requirements elicitation is all about. I disagree! Elicitation is more than that and the BAs job goes beyond order taking. We must advise the business and we must analyze the requirements.

For example, too often we are given a fixed scope, fixed deadline, and fixed resources even before the requirements are even conceived. We then try to “get the requirements” and then struggle how to fit them into the project’s constraint. That’s not analysis. We need to advise the business when the goals are unrealistic — we need to manage expectations. If the project’s scope can’t be done in the timeframe we’ve been given, then tell the business why it can’t be done and tell what can be done.

As a former CEO, I always provided my projects teams with a vision, an overall scope, a deadline, a budget, and resources. Good leaders put stakes in the ground. If you don’t then the project teams work without goals and they won’t focus — deadline and resource constraints force prioritization and efficiency. But, if my constraints were unrealistic, I expected my project teams to tell me as soon as they know. I also want to know what they can do within the budget and timeframe. I want them to analyze the problem — not just go off, grumble and complain, and then tell me in the end that they can’t get it done. After all, I have set marketing, sales, and client expectations. So, if you can’t meet the objectives, let me know right away — I’ll understand if you give me reasons.

Anyway, we need to act more as analysts and not simply take orders and then go off without helping the business understand what can and can’t be done. Keep in mind that business does not know how IT works; educate them, help them understand why some requirements might not be doable.