Tag: Stakeholder

Are Business Analysis Documents Becoming the Dumping Ground?

Written by Manish Goyal on December 22, 2014. Posted in Articles. 1 Comment on Are Business Analysis Documents Becoming the Dumping Ground?

Few of the areas within the business analysis context are least understood and as a result the business analysis document becomes a dumping ground of the project content and activities.

Do these questions ring a bell?

Can we avoid the BA documents to be a dumping ground or catch all for the project activities?
Are the stakeholders trying to prescribe “detail tasks” instead of focusing on their actual needs?
Does your stakeholder team get upset when you refuse to record un-related information in the BA documents?
How do we make sure that un-related things are really those un-related things and it needs a bigger and better house?

As Business Analysts, you need to be cautious about the information which needs to be captured. You should be able to decide/comment on content of the document. The suggestions below may help you decide in the future should the above questions arise.

Few areas which are least understood and could be improved are listed below:

Assumptions: Make sure you have a clear understanding of each of the topics of the document. For ex. If there is an Assumption section then to make sure that the assumptions are minimal and purely related to the requirement analysis activities instead of the project activities. Also the exact meaning of Assumption is “a thing that is accepted as true or as certain to happen, without proof”. If your statement clears this test then it is considered as an assumption.
Functional Specification: In the name of functional specification, sometimes the stakeholders are tempted to provide step-by-step and task-by-task description so that the information is not taken out of context. Make sure that the specifications do not contain step-by-step information. For ex: Do this once you have done this.
Business Rules: These are policy statements which do not change over the period of time. It only changes when business changes the way they are doing business.
Business Metrics: Be cautious about the business metrics as it should not include project metrics. Rather it should capture the metrics which would be impacted because of the new/updated business needs.
Repeating: Sometimes the stakeholders become overcautious and they would like to state the same thing in different words in different parts of the document. Make sure that you communicate and emphasize the importance of information overloading.

These were some of the areas which I thought need to be watched carefully while you are dealing with different stakeholders. I am sure there will be several different areas like the above where the business analysts need to be cautious about the content. The idea over here was to provocate thoughts in your mind on this topic.

Don’t forget to leave your comments below.

Everything We Need to Know We Learned on Sesame Street

Written by Marcos Ferrer on December 8, 2014. Posted in Articles.

“Some of these things, are just like the others, some of these things are not quite the same, can you guess which things…” Analysis is the “anti-methodology”, always seeking coherence, relationship and significance rather than exclusion.

Let’s use some BABOK categories to organize stakeholder “stated requirements”. In the process we will see how we can distinguish “requirements” from requirements when we model potential solutions.

Let’s say your stakeholders have stated things like:

We want to reduce data entry errors
We want to increase sales
We don’t want to change the work or conditions
We want easy to use
We want users to write their own reports instead of waiting for IT
We want happy customers
We want to buy this in ONE software package
We want to outsource all software configuration and maintenance
We want large monitors, aluminum cases and wireless keyboards on our PCs
We want to capture name and address and contact info everywhere
We want users to have the freedom to override business rules
We want a consistent high quality customer experience
We want the system to pick the best approach
We don’t want managers interfering with our work (micro-management)
We want easier, better scheduling with fewer disruptions
We want to get rid of old technology
We want direct access to the database
We want reliability, maintainability, scalability and no irritability
We will know it when we see it but no sooner
We must have everything built before release
We must be able to change any business rule after release, so we don’t have to figure them out now.

That’s a nice sample of a typical list – we are ignoring things like “We want the requirements to be what we wrote down in one meeting” and “We want to design the system architecture because we write the checks” and “We want this done better, faster, cheaper”. That is a different list for a different essay. Those statements are not presenting as requirements but are attempting to dictate methodology or the lack thereof.

SO – given BABOK categories that follow, what goes where? Do some statements impact multiple categories? What can you extrapolate from the above to “discover” unstated requirements?

Business Requirements
1. Business Goals / Objectives
2. Business Needs
3. Capability Gaps
4. Solution Approaches
5. Solution Scope
6. Business Case (what matters, how it matters and why it matters)
Requirements [STATED]
Requirements [ANALYZED / MODELED]
Business Analysis Plan
Solution Requirements
1. Functional
2. Non-Functional / Qualities
Transition Requirements

One “breakdown” might look like:

Arrrghh – not AGAIN! We are left to think about it until a future blog.  Doesn’t the author understand that thinking is hard?

The answer is yes – the author knows. Thinking IS hard, the brain uses more oxygen and energy than any other part of the body. People who would never think to run 50 miles actually believe that their thoughts go just as far as anyone else’s. The same folk who might admire an athlete without thinking that they should compete with the athlete have no trouble believing that they know as much about creating business solutions as a performer with an actual track record.

Are you a BA thinker, or just a participant – another talker? Are you a modeler, or just a scribe? Your ability to handle this exercise is your answer.

For those of you who do practice modeling / technical BA skill, here is a cool diagram showing ALL the requirements “types” mentioned in the BABOK. Can you use each one in a sentence?

Cool Diagram:

NEXT TIME – SYNTHESIS.

Don’t forget to leave your comments below.

5 Classic Mistakes of a Business Analysis Centre of Excellence

Written by Phil Vincent on November 24, 2014. Posted in Articles.

A Business Analysis Centre of Excellence (CoE) can be an effective means of improving the way business analysis is performed, resulting in better business outcomes from successful projects and operational support initiatives. It often begins with an ambitious training program, followed by a distribution of templates and instilling the best practices. Some CoEs are successful, but all too often the CoE is disbanded after a couple of years of disappointing results. Having been involved with dozens of CoEs with different companies, I’ve observed some of the most common mistakes and how to avoid them.

1. Failure to Engage the Right Stakeholders

Many CoEs successfully inform executives about the CoE’s reason for existence, and they also let the BAs know what is expected of them. However, few BA CoEs meet the needs of the other key stakeholders. These stakeholders have their own priorities and challenges, and may not have time to worry about better business analysis. Take the time to understand their needs, and to help them make the necessary transitions.

Solution providers like vendors, developers and testers who use the approved requirements may be expecting specific formats and specific levels of detail in the requirements artifacts, and expect that the artifacts will be produced in a specific timeframe. Internal solution providers may have their own CoE with its own tools and standards that conflict with those of the BA CoE; while external solution providers may be bound by contractual specifications about the requirements. There could also be unspoken cultural expectations about the role of the BA and the types of requirements documents and requirements artifacts.
Operational managers and subject matter experts who use BA resources may have business pressures that prevent BAs from spending time implementing good ideas from the CoE.
Customers may have certain expectations about dealing with the BAs in your company; they may actually like the current way of working with your BAs and may object if you change things too much.
An existing union agreement may describe job functions that need to be considered by the CoE, which may also enhance or restrict the ability of workers to implement new techniques or best practices. Or, responsibilities and job titles could exist that have been endorsed by your human resources department, possibly requiring adjustment.
Internal procurement specialists who reach out to suppliers of contract BAs need to be aware of the skills and duties required by the CoE. Existing supply arrangements may need to be revised. If the CoE asks for too much of a change too soon, the organization may find itself unable to find adequate resources that meet the new skillset expectations.
Companies supplying the contracted BAs need to understand the BA CoE’s guidelines about required skills and duties. It will take them some time to source the right people with the right skillsets, and the organization could well find itself paying a premium for such resources.

2. Too Much Reliance on Templates

A document template sets expectations about what types of requirements and requirements artifacts are to be produced.

The first problem with most templates is either that they are too generic and broad to be of use on a specific initiative, or that they are too narrowly focused and fail to recognize the differences between projects. Many BAs are frustrated by their current templates because they don’t meet the needs of a specific initiative.
Many templates are focused on software requirements and ignore all of the other areas where business analysis can really be of use, like changes to business policies and rules, job functions, relationships, capabilities and workflows.
Templates establish the focus of the BA work on documentation rather than on discovery, collaboration and analysis. Filling out the template on time becomes the goal, rather than understanding the requirements and recommending solutions.
A template-driven requirements document is project-centric, and the usefulness of the document diminishes as soon as the project is completed. But, the reality is that the requirements actually live on with the solution and could be relevant for many years. Since most project documents are seldom referenced after the project, consider changing the focus of the BA work to produce a coherent set of versioned requirements artifacts like process models, a data model, use cases and storyboards that live on their own and can be base-lined and assembled into a document at any time. You will need a requirements management tool to do this well.

3. Trying to Make Too Many Changes at Once

It’s usually easy to spot lots of possible areas of improvement in your business analysis practices. But culture, tradition and ceremony are likely to resist too much change at once. Some of the changes requested by a CoE like enhanced time and status reporting may just be perceived as low-value overhead. Left to its own devices, the organization will revert to its previous status quo (the way we’ve always done things). So if you want to make sustained changes, the only way to do so is to lay a solid foundation, make incremental changes, realize and communicate the benefits and provide ongoing and substantial reinforcement to those changes.

Training is the easy part — but sustaining it is difficult. Training can encourage your BAs to consider new ways of working. Applying the theory from training is quite difficult, and almost always requires time to recognize how to apply it in real life, to realize how to apply it effectively and to apply constant reinforcement.
Consistency in the way the BAs perform business analysis should be a primary objective, prior to making substantial improvements. Every one of the BAs has a group of stakeholders who must be informed and educated about the new approaches to business analysis. Time must be allotted to allow them to make the changes and achieve buy-in from those stakeholders. Many of those same stakeholders work with other business analysts, not spotting inconsistencies very quickly. Some stakeholders will exploit those inconsistencies because it makes it easier for them to do their own work.
Focus on incremental changes; test new techniques and tools on pilot projects and make adjustments so that the project is successful. Communicate the successes broadly and then roll the improvements out to other projects, providing strong support until the BAs using them indicate that support is no longer needed. Be prepared to abandon some changes if you can’t be successful with them.

4. Show the Way, Don’t Dictate

The BAs that are being asked to change the way they work must be confident that the people who are asking them to change actually know what they are doing. You can’t fake it; the BAs will know. It’s okay to have a professional manager run the CoE, but skilled BAs are essential to make the changes happen.

The individual members of the CoE who tell other BAs about the needed changes must first have real experience in the new business analysis techniques, not just theory. They should also have substantial business domain knowledge so they can provide relevant examples of how to apply the new techniques.
The members of the CoE must be excellent coaches and mentors.
- A coach proactively provides guidance to the BAs that are working on projects and shares responsibility for the BA’s success or failure on those projects. A coach lets the BA do the work, but anticipates real problems and provides proven solutions and alternatives that the BA can execute. The coaching for each individual BA will be different based on the nature of the project, the stakeholders, and the current skills and abilities of the BA.
- A mentor is someone who an individual BA can ask for specific guidance on a topic. Unlike with a coaching relationship, the interaction is at the discretion of the BA. Mentoring occurs when coaching tapers off, once the coach and the BA agree that the coaching role is no longer needed. The mentoring relationship is based on trust and can only occur if the BA really believes that the mentor is truly proficient at business analysis and understands the business domain.
Coaching and mentoring may be impeded if there is a cultural reluctance to “ask for help” or to be perceived as “requiring help.” Just remember that every champion athlete has a coach; no one gets to the Olympics without one.
External consultants may be engaged as temporary coaches to get things started and to “coach the coaches.” However, every effort should be made to develop internal coaches and mentors.
One effective approach is to rotate some of the roles in the CoE with practicing business analysts. This helps to broaden the experience of individuals and helps to keep the coaching grounded in reality.

5. No Skin in the Game – Misalignment of Goals and Objectives

Most CoEs are established with goals or objectives that align with the organization’s strategic direction. But all too often, the BA CoE’s goals fail to align with those of individual BAs with tactical project objectives like schedule and budget, and with operational objectives such as minimizing customer service delays. This is most evident in a matrix organization where any one person may be trying to meet several disparate sets of goals. The CoE’s goals could actually conflict with the “real work” that is being done.

Operational managers and project managers are likely to resist the imposition of BA standards and templates if they perceive them to be in conflict with their own goals, especially if their own goals are tied to annual performance reviews.
If an individual BA tries to follow standards set by the CoE and the project fails, what degree of accountability is assumed by the CoE?
If a BA is supporting an existing solution and, by applying new BA techniques, fails to implement requested changes as quickly as expected, to what extent is the CoE accountable for the failure?
One of the CoE’s objectives must be to make the individual BAs more successful. And that usually means making the BA’s stakeholders more successful. So the BA CoE must be aware of those stakeholder goals and ensure that the CoE helps to support those goals. The best way to make this happen is to hold the CoE accountable for the successful use of the new techniques and tools.

Conclusion

A Business Analysis Centre of Excellence is no small undertaking. There can be a substantial payoff in terms of better business outcomes from successful projects and operational support. But, great care must be taken to ensure the CoE has a positive and sustained influence, and doesn’t turn into an irrelevant Ivory Tower, or worse, a nuisance.

Critical success factors include the following:

Extensive stakeholder engagement
Incremental improvements built on consistent practices
Focus on improved processes and not just templates
Ongoing coaching and mentoring by people who truly know business analysis and the business domain
Shared accountability for successful business outcomes

Don’t forget to leave your comments below.

Splitting Stories – What do you mean you’re Not Done?

Written by Robert Galen on November 24, 2014. Posted in Articles. 1 Comment on Splitting Stories – What do you mean you’re Not Done?

I saw the following series of snippets in a LinkedIn discussion on the Agile ALM tool Rally. Bear with me as you read through them to get the context for our discussion…

Original Question

I have a serious case of “I want to get back to JIRA Agile”.

My latest challenge with Rally is to find the best and most true way of dealing with unfinished stories at the end of a sprint.

Story: I as a ScrumMaster want to move 3 unfinished stories from Sprint 1 to Sprint 2 gracefully so that the team will have these stories in the next sprint without falsifying the velocity of Sprint 2 or the backlog and not creating any more overhead for the ScrumMaster.

Acceptance Criteria:

Total backlog story points stays true
Velocity of previous sprint stays true (commitment is reflected accurately)
It’s not adding a huge amount of overhead on the ScrumMaster or the person doing it
It doesn’t need a custom app for doing this

Looking forward to your feedback!

Reply #1
A slight modification on the above. We split the story (which actually creates a parent and another child) then Rally will automatically split the completed and incomplete tasks. Then, and very important, set the Unfinished story points to 0. Rally assigns the original points to each sibling. This will create the illusion of a greater velocity that actual. Some people allocate the points, but I am of the opinion “Done or Not Done” (There is no Try!)

Mark the Unfinished story as Complete but not Accepted. Then when the Continued sibling is complete and accepted, go back and accept the unfinished sibling. This way the Feature %done is accurate. I suspect that the parent is not counted in the story count, but I’d have to check.

Reply #2
This is a tough one. Rally’s splitting solution is a good idea for other things, but there is always a trade off with the implementation for rolling over stories from sprint to sprint. Two stories are created with identical points under an epic, and any project scope reports are doubled. If you make the story zero points, you still need to mess with the state to ensure it does not impact feature stats. Until rally creates a way that a story was “historically” in sprint 1 and is now in sprint 2 ( as the same story) you will need to make trade offs.

I typically just move the story forward because I am mostly concerned about work completed, not what was not accepted after the sprint is closed. I find the need to know what was in a missed by the team is only valuable for the retrospective. Not beyond. I keep an external spreadsheet of committed vs earned points outside of Rally for stats only so the team can see if they constantly over/under commit. Not story rehashing.

Reactions

My first reaction is how a tool, any tool, can take over the conversations within agile teams. Here the functionality of the tool is driving much of the thinking of three leaders within their respective agile team contexts.

They also seem to be worrying a great deal about the “reporting”. Are they fairly representing the velocity/points and will observers get the “right” impression from examining the trends?

This is an example of why I don’t like “leading with” tools in the first place. Instead of focusing on effective agile principles and practices, we end up worrying too much about the tool and the data reporting.

How I handle un-Done Work

I know this may be a little severe, but I’ll share with you how I like to handle un-done work. I’ve been doing it this way for 10+ years. Don’t necessarily know where or when I started it nor who influenced me in this direction. I think it’s what’s recommended in most basic agile project management books, but I don’t have a solid reference off the top of my head.

Here we go:

IF a User Story isn’t complete (to a team’s Definition of Done) then they get NO CREDIT for any of the story points in the current sprint
IF the Product Owner decides the story warrants it, it will move to the next sprint (complete it OR remove it)
In their Retrospective, the team discusses how to get better at committing to realistic goals and finishing their work
In Sprint Planning, the team plans the remaining work to cleanup or finish the story
When the story is complete in the next sprint, the team realizes all of the story points

Basically this model reinforces the notions of:

Team receives no partial credit for incomplete work
Team commits to a body of work within a sprint and delivers it (or more)
Team makes their work and dynamics transparent
Team strives for continuous improvement

As I try to influence each team towards base agile principles. And yes, I understand that most agile tools struggle with this notion. They typically want to “split” the story from an “accounting” perspective.

Arguments

I always receive arguments about this approach.

First and foremost is the affect it has on team velocity. Clearly if a team has an average velocity of 25 and misses an 8 point story then their velocity might be 17 points and then 33 points in subsequent sprints. This “turbulence” will be clearly visible to everyone and will probably cause uncomfortable conversations. It’s ugly. It makes stakeholders pay attention. It makes predictability and forecasting hard.

Exactly!

Another argument is that the team will become demoralized.

Why? They clearly struggled a bit with this story and need to reevaluate their estimation and work planning. So what? That happens with newer teams and this event will create healthy discussions and adjustments in their retrospectives.

From my perspective, it all boils down to arithmetic. It didn’t work out, so we have a decision. Do we split the story and take partial credit—hiding the issue OR do we just handle it congruently, move on, and strive to get better next time?

SideBar Story

I once coached an organization where each of their teams had about 25% of each sprints stories remain incomplete at the end of each sprint. It happened so often that they created a term for them—Continuation Stories.

It got even worse. Continuation Stories had a tendency to cascade across more than one Sprint. In fact, on average they spanned 3-4 sprints before they finally were completed and considered “Done”.

Because they “split” the work at the end of each sprint, their velocity appears sound. And because Continuation Stories, became the norm, they really didn’t talk about them much in retrospective.

However, their customers were paying attention and realized that 25% of each sprint was missing. Not only that, but undone work crept into subsequent sprints and continuously undermined the amount of work the team was delivering.

Point being—it was noticed and it wasn’t “good”.

Wrapping Up

I’ve wanted to discuss story splitting as a result of execution and delivery dynamics for quite some time. I think another discussion on a Rally forum was the initiator then as well.

It’s not that the tools are bad. But it is the fact that they encourage us to focus on the “arithmetic” rather than the behaviors we want to instill and inspire in our agile teams.

In this case, I don’t care about the interpretation of velocity or the reactions to turbulence. It happens. What I want the team to focus on is (1) hold firmly to their Definition of Done, (2) if something isn’t completed, determine what happened – exploring root cause(s) and then (3) do something about it to improve their abilities to plan and deliver on their future commitments.

Whether you “split” your stories or not, I hope this article caused you to pause and consider how you handle partially completed work within your sprints.

Stay agile my friends,
Bob.

Don’t forget to leave your comments below.

Requirements Come in Many Forms

Written by Marcos Ferrer on September 22, 2014. Posted in Articles.

“What’s in a name? That which we call a rose  By any other name would smell as sweet.”
– William Shakespeare, Romeo and Juliet

“You say po-tay-toe, I say po-tah-toe……..You say to-may-toe, I say to-mah-toe…..
let’s call the whole thing off!”
– George and Ira Gershwin, Shall We Dance or Quit This Project?

Requirements come in many forms. For concepts slipp’ry ‘twixt our brains
Goals and visions, points of pain. Needs and wants, gaps versus norms
Approaches, scope and upside gains. Costs and plans, assumptions named

A business case, with risks in place. Analysis to gray cells whisked
Away in meetings, don’t explain. Don’t make us think – it’s HARD in rhyme
And only then transitions? — tsk!

Look and feel pushed to design. Test quality at rollout time
And if performance is not so keen? Don’t forget the root cause blame
Change requests, poor user training. So many words, what DO they mean?
– Marcos Ferrer, CBAP

Let’s use the BABOK 2.0 requirements definitions to decide what words mean (yay standards). BABOK recognizes 5 major requirements types:

Business Requirements
Stakeholder Requirements
Solution Requirements Functional
Solution Requirements Non-Functional (don’t tempt your users to agree here)

Transition Requirements

We’ll take a simple, yet frustrating example. An executive wants to organize all of the workers tasks around how much time it takes to do the task. The idea is to do more tasks by doing the quick ones first (don’t laugh – if you haven’t run into stuff like this you are a lucky BA, but may lack skill from lack of exposure).

What is wrong with this requirement? If your answer is “nothing”, you don’t have to read the rest. If you aren’t sure, keep reading. If you can articulate exactly what is wrong and why, you should be writing this blog.

Let’s break this requirement out into BABOK categories, across ALL the requirements types and levels.

Step one: What is the executive’s “requirement” in BABOK?

First and foremost, it is a “stakeholder” requirement, and requires some kind of analysis (thought) to make it into a “real” requirement. According to BABOK the “requirement” is “stated” and/or confirmed (“You really said that? – OK, got it”)

Step two: What kind of analysis?

We might consider breaking the statement down into more detail – what are the tasks and how long does each one take. This is the naïve analyst (naïve IT analyst) approach, and will lead to a failed implementation if not stopped immediately.

The business analyst approach is to consider the business requirement that is driving the stakeholder “requirement”. SO, what is the business requirement analysis that might help fix the stakeholder “requirement” (save it or build it – you are running out of time.

Maybe the business requirement is a vision: “Let’s do shortest tasks first so we can get more work done.”

NOPE – that doesn’t help – restating the stakeholder requirement as a vision leaves us where we were, and even BABOK says that “visions” are the least likely “requirements” to be ongoing / valid as stated.

Maybe the business requirement is a business need: “We need to do shortest tasks first in order to get more work done.”

ICK – again, restating the stakeholder requirement as a “business need” didn’t move the ball – we are still stuck with organizing tasks in an “overly simple” (to be kind) way OR getting into a fight with a stakeholder.

Maybe the business requirement is a capability gap: “We can’t get enough work done because we are not able to organize shortest tasks first.”

Phooey – this doesn’t help, because even though it is true (we are not able to figure out which tasks are shortest, and hence can’t do them first) it is not clear that filling this gap will result in a winning system.

Maybe the business requirement is a business solution approach, as in “Let’s get more work done by doing shortest tasks first”.

Hmmm… this might be better, if only because it shows that:

We want to get more work done (or at least the executive does).
We can use the approach of doing shortest tasks first.

NOW we have some analysis – we broke the stakeholder requirement into TWO parts – a business solution approach and another part. The other part – is it also a requirement?

BABOK offers solution scope business requirements, as in “The business solution shall get more work done.”

Nope – I have seen such requirements, and yet calling them “solution scope” is off.

BABOK offers business case requirements, as in “Organizing tasks to do shortest first will accomplish 10% more tasks in the same amount of time.”

This sounds like what the executive is imagining, but notice that the statement above is NOT a business case and hence is not a business case requirement. The statement is a “justification” statement with no evidence or analytical cost vs. benefit computation. It is, as stated, simply another stakeholder “requirement” – a statement of stakeholder thinking minus any serious attempt to prove feasibility or estimate payback.

To make this into a “business case” requirement would suggest making an actual business case, including feasibility (what are the shortest tasks – what happens if we try them first – what are the longest tasks, and their relation to the short ones?). I for one am in favor, and yet I know that if I insist on a business case it sounds like I am questioning the executive’s thinking, who (theoretically) is responsible for due diligence before writing checks for projects.

Again, NO GOOD, unless:

We don’t like the executive and want to be mouthy (demand the business case and avoid the executive by getting fired or whatever)
We intend to build whatever we think without discussing it and hence risking conflict
We intend to build what the executive seems to have asked for (that’s right – when IT builds what you tell them to build it might mean that “you asked for it” and how words don’t mean what they mean, be trilingual! and what’s more that the IT team figures you deserved “it”.

You are an IT genius even though you chose to go into “people work” like management, or sales and got B’s (C’s?) in math.
IT doesn’t like you enough to do what is right even though you won’t listen
IT knows from experience that if you see any deviation from your exact instructions you will pitch a fit, and they gave up trying years ago., and are prepared to

We are out of business requirements, and surely we don’t want “Let’s do shortest tasks first to get more work done” to be a Solution requirement (functional or “quality” non-functional) or a Transition requirement.

What is the answer? How do you present the stakeholder requirement to “Let’s organize the system around “shortest tasks” first in order to get more work done.” In such a way that it opens discussion instead of shutting down communication and trust with the (very excited at the brilliance of her idea) executive?

Answer in the comments below for a chance to write your own blog in this very space (yes, with editorial help) and have fun, fearless BA readers!

Don’t forget to leave your comments below.