10 career crushers that threaten every business analyst

ⓒ 2012 Blueprint Systems Inc. - Confidential & Proprietary 1

10 Career Crushers That Threaten Every Business Analyst


Introduction

Your Speaker: Tony Higgins VP Product Management, Blueprint Career in Software & Systems development. Specializing in Business Analysis / Requirements for last nine years.

HOT ISSUES FOR BAs

• lack of communication within the company. • Its like pulling teeth to separate needs from wants. • Getting the time of all needed • Breaking through decades-old mentality: “I never had

requirements in the 70s so why do I need them now?” • Change of Project Scope. SME's adding additional scope • Articulating clearly & concisely so business and technical get it. • Knowledge of the existing system. It’s complex and

undocumented. • Line of Business people overwhelmed, minimal availability • Playing catch up. This is a new role - finding its footing • Simplifying complex requirements & fostering their understanding • Understanding English sentences varies by requirements consumer • The struggle between doing things effectively versus achieving the

requirements due date.


Presenter

Presentation Notes

We did BA survey Among other things the ‘biggest issues’ (no order) All can relate Things like xxx and xxx

TOP 10 CAREER CRUSHERS

Presenter

Presentation Notes

- From this and our customer visits and others – boiled down to a top ten list - A list we call the “top 10 career crushers”


Career Crusher #1

Settling into the role of the ‘custodian of the document’

Presenter

Presentation Notes

First … Heard many times; expressed many ways; hit me personally when starting out … Resp. for reqts on large project After stakeholder analysis, travelled nation wide/interviews Analyzed an evolved reqts Series of draft docs – growing bigger and bigger Effort exponential – managing data, assembling doc, updates, tracking, consistent – MECHANICAL Colleague came by; big picture conversation; “Ur not Analyst anymore – Ur custodian of document” Mechanical became 80% or more of the work Little time to ‘get it right’


… but most BAs are too busy producing and revising the BRD to focus on analysis and critical thinking

Career Crusher #1

Settling into the role of the ‘custodian of the document’

Presenter

Presentation Notes

A quick related statistic … - 96% BAs say analysis and critical thinking are crucial But .. Most BA’s today spend so much time on the mechanical job of producing and revising documents that it leaves precious little for analysis and critical thinking In the end, That is not good value for your company or for your customers and clients.

Career Crusher #2


Using email by default to communicate with busy, hard-to-reach people

Presenter

Presentation Notes

Career Crusher#2 … Email tends to be first approach people use –they don’t have wait to “connect” with the person just fire off an email and people will get to it eventually. not surprising that its often the default way to converse with people about REQUIREMENTS Everything from a quick and simple question, to a long raging debate involving several people, to passing around entire requirements documents as email attachments However there are very real issues with this ….

Career Crusher #2


The average office worker spends 41% of each workday managing email

Using email by default to communicate with busy, hard to reach people

Presenter

Presentation Notes

One of these is sheer “volume” AVERAGE emails typical office worker in a day is 87 … can be much higher average office worker 41% of their day reading, responding to, and managing email. This means your important REQUIREMENTS conversations, vital for getting good requirements, of which there are many, now competing with all the other emails …. For attention. They may get missed, flagged but never followed up, not get the attention they deserve because they COMPETE with all those other messages. other reasons to … can be ‘exclusive’ leaving people out of the loop. How many times have you forgotten to add someone or cc them on an email? How many times were YOU the one missed? spam-filter so you never saw it Or as I said just sheer volume it got missed, or put in the pile of flagged emails and never got to it All of these cases and more have basically the same result – they leave people excluded from the process. technology advancements in social media has really started to make email look like a ‘first generation’ collaboration tool. But people continue to use as default


Career Crusher #3

Being left in the dark when key discussions are going on

Presenter

Presentation Notes

Career Crusher #3 – a project is a whirlwind of things happening, at a fast pace, BA often isn’t aware of happenings or decisions made that directly affect him/her. They find out later.. impact could be significant. On the other hand they don’t want to be proactively informed of every little thing that ‘might’ affect them they’d be totally swamped with a lot of things that are of low importance or significance. - Somewhat of a catch-22


… the impact of finding out about changes too late can range from mildly annoying to entirely catastrophic!

Career Crusher #3

Being left in the dark when key discussions are going on

Presenter

Presentation Notes

A related statistic 57% of BAs say requirements change continuously throughout the lifecycle in other words the decisions originally made and signed off, are being RE-visited and RE-decided throughout the lifecycle. a project is a continuous series of changes and decisions from beginning to end to not be aware of these is very risky – discovering after the fact, depending on what that decision is about, could have impacts ranging from mildly annoying to catastrophic.

Career Crusher #4


Falling victim to the Blind Approvals nightmare

Presenter

Presentation Notes

Career Crusher#4 … everybody today is swamped. You’re swamped with, among other things, creating a BRD or requirements document. critical document; imperative it be right. a ton of hard work, ends up being pretty substantial in size. from the consumer’s point of view … they’re swamped as well – with lots of high priority, very important tasks. with a “thud” this large volume of complex information dropped on their desk they’re asked to look it over, make comments, and attend the Friday meeting to provide their feedback. it’s a very tough read. Every statement is hand-crafted by an expert BA, every word holds important meaning. have to read, and then re-read statement multiple times to make sure they “get it”. they are of course interrupted, losing their train of thought, and have to start over when they return to it. as they get deeper becomes even more challenging statements now start to depend on previous ones cross-referencing to be dealt with. net - requirements take a lot of time and energy to “digest”; tough read; and can take many, many passes to start to get the picture. people don’t have all that time; when they do they’re fighting the constant interruptions that make it all that more inefficient. result – people give what we call “Blind Approvals” They simply can’t get through it all, or not with the level of understanding that’s really needed. they sign off without really understanding all the content. It’s not that they have bad intentions … as I said they often simply don’t have the time that’s needed to thoroughly “consume” what they’re given. They also rationalize their signoff by assuming others have understood it, so if those others are signing it off then it’s probably ok. Or they feel their signoff will get things moving, and any issues will surface soon after development starts anyway so we’ll catch them then.

Career Crusher #4


Often times, the very same people who “signed off” on the BRD later ask for changes to the very details they approved. How can this be??

Falling victim to the ‘blind approvals’ nightmare

Presenter

Presentation Notes

- related stat, 53% of BAs say that MAJORITY of requirements feedback is later stages of the lifecycle, after signoff !!! yes may have missed including some people yes some business conditions changed during development BUT outside of this, much feedback that drives changes is from people who agreed with the requirements and approved them. How can this be ? ‘blind approval’ of the document meant they really didn’t understand it in its entirety Because the document is too long, too complicated, they just didn’t have the time or mental stamina to read, absorb, and truly understand it. net result lots of later feedback and changes; SOME start to point the finger at the BRD questioning it’s quality; by extension the author – the BA.

Career Crusher #5


Relying on Track Changes to Manage feedback and revisions

Presenter

Presentation Notes

Career Crusher #5 – natural for people to reach for ‘what they have’ or ‘what they know’ for tools this is true when updating requirements in documents. - typical pattern … BA works very hard to get BRD ready. Distribute, often via email, ask for redlined versions to be sent back. Maybe sched review a few days or a week out. Each reviewer tries to find the time to read – or the requested portions – mark it up with redlines and comments. typically in isolation. ask some questions as they go along. - BA gets multiple marked up copies coming back. go through each version of input – suggested changes, notes, comments, questions, clarifications, - and reconcile Some simple, but much of it requires discussion, debate, and analysis that requires multiple people. this involves many back and forth communications, or finding time where all needed are available to meet. - then repeat - cumbersome, manually-intensive, error-prone, process that’s not very engaging or collaborative.

Career Crusher #5


… but BAs frequently invite stakeholders to deliver the majority of their feedback in complete isolation

Using “Track Changes” to manage feedback and revisions

Presenter

Presentation Notes

Stat: 84% of BAs see collaboration as a critical part of their role BUT… they frequently ask stakeholders for feedback in complete isolation, alone with a document making redlines. When reviewing doc questions arise for which there’s no easy/immediate way to get answers forces reviewers to make assumptions just to keep moving many of these assumptions could of course be false. BA no insight into the reviewers feedback until send back the marked up document. you really have no idea how much work awaits you multiply by the number of reviewers and you can easily be facing a tidal wave of work. this approach … you giving permission – or even encouraging– to disengage from a collaborative approach And several rounds of review and multiple redlined copies of different doc versions - you’re left with no coherent, easy to reference audit trail

Have you experienced these?


Custodian of the document

Email by default to communicate

Being left in the dark

Blind Approvals

Relying on track-changes for feedback

Career Crusher #6


Settling for text to communicate ideas

Presenter

Presentation Notes

Career Crusher#6: people still rely on “text”, some pictures, to express requirements and to communicate a ‘vision’ of what needs to be built if someone doesn’t understand a text, reaction is to add more text to elaborate or clarify. soon end up with the big, thick, legal-style document hugely expensive to maintain, and hugely difficult to read and understand.

Career Crusher #6


BRDs are full of text. People don’t think in text.


Presenter

Presentation Notes

Stat: 58% of BAs consider visual modeling as a critical or very important part of the requirements. But … Your typical document FULL of text simply, people don’t think in text - … they mentally conceive ideas with imagery, and pictures, and story sequences. the more vibrant and ‘alive’, the more easily and effective they are communicated and understood with the large BRD people forced to translate their vibrant ideas into flat, legal-style text. As I said before reaction when people don’t understand, is to write more text to clarify The result is the ever-growing document that becomes huge, an unwieldy according to surveys most BAs recognize the value of visual modeling but its that catch-22 again .. so consumed trying to write, maintain, and hold the BRD together - little time available to do this modeling not saying dispense with text completely - stop the over-reliance on it, use visualizations where they replace text or to augment text.

Career Crusher #7


Using spreadsheets to manage dependencies

Presenter

Presentation Notes

Career Crusher#7: Dependencies absolutely vital to capture and maintain throughout a project Or you cannot effectively make changes, manage scope, ensure coverage, or track progress against higher level objectives i.e. you can’t run the project. How effective you are at … getting them all, Keeping them current updated, making exactly the ones you need quickly accessible directly determines how successful your project is key challenge - so many; not all important. most common pitfalls: not focusing on just the most important ones - making huge number to manage even bigger second, using best tool you have but not up to the job – and that is, simple spreadsheets.

Career Crusher #7


… this is a staggering number of BAs who have placed the risk of major requirements errors squarely on their shoulders!


Presenter

Presentation Notes

- stat: 54% of BAs report using spreadsheets to manage traceability on their projects today. staggering number - placed most critical project functions onto a generic, office-automation tool. causes tremendous workload to maintain, when inaccurate, not current, or not readily accessible by those who need it … can be cause of requirements errors again, falls on the shoulders of the BA. Points .... Dependencies, CRITICAL to good requirements, and project success provide context for each requirement, how relate to one another, without them can’t get complete picture Try with spreadsheet huge burden; if not 100% all the time then significant risk.


Career Crusher #8

Hand-assembling every User Acceptance Test

Presenter

Presentation Notes

Career Crusher#8 BA’s often involved in, or responsible for, “User Acceptance Tests” ensure it fulfills the original need … in other words, what was said in the requirements issue is user acceptance tests are written manually today. usually a lot - at least as many as there are requirements could be 2,5,10 times as many to cover all the cases.


… trying to cover off all use case scenarios manually is highly error-prone process.

Career Crusher #8

Hand-assembling every User Acceptance Tests

73% of BAs create User Acceptance Tests manually.

Presenter

Presentation Notes

you’re not alone. Most do manually Creating user acceptance tests is a big job, and very risky risk because so manual, the tests may be flawed, you may not be adequately covering the requirements you many not be testing the most critical areas or scenarios you may be wasting valuable testing time & resources with redundant testing as these errors and inefficiencies become apparent, people – including the business client – begin to lose confidence. instilling confidence is exactly what User Acceptance Testing is supposed to do !

Career Crusher #9


Losing most of your work at the end of every project

Presenter

Presentation Notes

Career Crusher#9 project over, got through UAT, ops rolling out. Many consider project over, gone or ramping up on their next projects … BUT app you built just starting it’s life. need maintenance. List might already be forming for the next round of enhancements for those maintaining or enhancing moving forward - WHAT ARE THEY given to work from they have the last version of the reqts docs Sometimes reflects delivered app- but I’ve seen where doc not up to date Now when changes happen missing all that work -conversations, debates, intermediate analysis, review feedback, track changes, the ‘rationale’ and ‘logic’ that led to those requirements decisions being made. we’re left with the decision – but HOW that came to be and WHY is lost. pretty common for the people who WERE involved at the time, to be gone or unavailable. information like this is like gold Trying to work without it - very time consuming - you have to re-discover it, … VERY risky - new decisions made without benefit of original work.

Career Crusher #9


FACT: All the work that lead up to the creation of the BRD has TREMENDOUS reference and repurpose value. Where is it all?


Presenter

Presentation Notes

Stat: 95% BAs use things OUTSIDE OF TRACK CHANGES to communicate and record feedback, discussion, and rationale This info tremendously valuable … “Where is it?” it’s in emails, instant messages, yellow sticky notes, on whiteboards. example: ask “How easily can you trace or access a key conversation or decision from 5 months ago, so you don’t rehash the same debates again later?” fact is if you can’t retrieve within minute or two, it’s as good as lost people start to traverse the same old ground – AGAIN.

Career Crusher #10


Using documents and spreadsheets as your primary Business Analysis tools

Presenter

Presentation Notes

final “Career Crusher” sums up what we’ve discussed today …. Career Crusher#10: majority of BA’s today, this is the case according to recent survey well over HALF are dissatisfied with these tools. shouldn’t be surprising - Word Processors and Spreadsheet NEVER designed to do job of Business Analysis. historically, EVERY other discipline SW proj has had their ‘tools of the trade’ evolve. now have modern, purpose-built tools to do their job Project managers have modern resource and task management systems Developers have elaborate IDEs Testers or QA have modern test mgt and execution platforms; these from Y2K investments - But BA - who creates the “Blueprints” for the project that everybody works from – still using general purpose office-automation tools

Career Crusher #10



88% of BAs still use documents and spreadsheets to some degree to perform their job.

Job performance is SEVERLY restricted by these rudimentary office tools.

Presenter

Presentation Notes

Stat: 88% BAs still using docs and spreadsheets as the primary Business Analysis tool use of these as primary tools is a huge obstacle to getting better those using documents and spreadsheets have pretty much hit the ceiling on job performance. force BA’s to do so many high-volume activities manually, that it can literally consume them. being manual, means prone to human error - adds more to the workload. not only BA’s suffering - because everyone on the project depends on the BA’s work-products, they suffer to … all the way ultimately to the customer and end-user of the application.

Have you experienced these?




Hand-assembling every User Acceptance Test



A major root cause: Poor Requirements …

• Poorly defined applications (requirements) contribute to a 66% project failure rate [Forrester Research]

• 31% of all software application defects originate in the requirements, and they are the hardest to both prevent and fix. [Capers-Jones 2012]


The Problem Software Project Failure Continues …


• Ford Motor Co. purchasing system – abandoned. Spent: $400M

• New York City ‘CityTime’ payroll system over budget. Original: $63M Final: $760M

• IRS electronic fraud detection system – abandoned. Spent: $185Million

• UK Electronic Health Records program – abandoned. Spent: $12Billion

The Problem Software Project Failure Continues …


• Ford Motor Co. purchasing sytem – abandoned. Spent: $400M

• New York City ‘CityTime’ payroll system overbudget. Original: $63M Final: $760M

• IRS electronic fraud detection system – abandoned. Spent: $185Million

• Estimated loss in fraudulent refunds because system not in place: $894M

Total loss .. $1.1B

• UK Electronic Health Records program – abandoned. Spent: $12Billion


Blueprint

• Founded in 2004 • Focused on Requirements • Over 30% of company developing product • Mature solution – 8 Major releases • Vibrant user group • Strategic partnerships (MS, HP)

Blueprint Helps Remove the Career Crushers


Career Crusher Blueprint Solution

custodian of the document Generate Documents Automatically

Using email by default Inherent Social Features

Being left in the dark Activity Center

Blind Approvals Lightweight, online review

Relying on Track Changes Inline discussions with states

Communicating ideas with text Visual requirements and Simulation

Spreadsheets for Dependencies Automatic Trace Matrix

Hand-crafting user acceptance tests Automatically Generated Tests

Losing your work at project end Repository with history and discussions

Using MSOffice as primary BA tool Integrated Business Analyst “Workbench”

Example: Purpose-built application for Business Analysis


Presenter

Presentation Notes

purpose-built BA application is as compared to trying to do your job solely in documents and spreadsheets. Blueprint IS A WEB-BASED SOLUTION and is the most complete RDM platform available – covering all aspects of the requirements lifecycle There are five major areas to the product, all completely integrated however as part of a single, unified application.

Return on Investment

‘Measurable’ Benefits • BA Time saving (25-40%) • *Rework reduction (50-75%) • Automated Test scenario creation (70-90%)


*Notes: • 25-50% of project budgets are wasted on rework • 70-85% of rework attributable to requirements issues

Thank you !



Example: Generate requirements documents automatically

Presenter

Presentation Notes

The way that modern requirements tools like Blueprint can help is that they remove much of this ‘mechanical’ work by generating the documents, like the BRD, automatically. For Blueprint customers the daily work of the Business Analyst happens inside Blueprint, focused on the requirements themselves, and doing analysis work. When a document is needed, they hit a button and get the document automatically. What this does is shift the balance back to have the majority of the BA’s time focused on getting the requirements right The other really good thing about this is that it’s highly scalable … as the number of requirements grow in size to double or quadruple – you still get the document by hitting the button. This is something I dearly wish was available to me those many years ago when I fell into the trap of being the “document custodian”.

Example: Communicate within the Requirements Application


Presenter

Presentation Notes

For Blueprint customers the majority of communication happens right inside the Requirements application using the many social features it provides, like Discussions. These discussions take the many disjoint email dialogs and pulls the conversation together into one place, directly attached to the requirement being talked about. People participate on their own schedule – often taking away the need for a meeting and the pain involved with trying to schedule a time for everyone to meet. When you mention someone in one of these discussions they are automatically notified and given a link that draws them into the conversation. ‘Like and Disliking’ of comments is an easy and informal way to gauge where people’s heads are at – beyond the words. And this is just one example of a range social features that keep people engaged, inside the application, and focused on the requirements

Blueprint: Being kept aware


Presenter

Presentation Notes

In modern requirements applications like Blueprint, there are a growing number of social features that draw team-members and stakeholders into the application and that keep them aware of things going on in the project that are relevant to them. For Blueprint users this means proactive email notifications for things they need to take action on – like their involvement in a review, or when they’re mentioned in a discussion, and so on. For items less urgent, but that you want to be kept aware of, each user’s personal Activity Center provides a chronological feed of these items. So every time you come into the product, at a glance you can see what’s happening that’s relevant to you.



Presenter

Presentation Notes

Blueprint users have a simple, lightweight “Review Experience” This can dramatically help the ‘consumers’ of requirements in a number of ways … First – instead of a huge document containing all the requirements that you have to wade through to find what’s relevant, this Review Experience lists only those requirements the reviewer needs to look at Second - much of the requirements info is displayed visually in the experience, making it easier to consume and understand Third – going even further to help reviewers understand, they can ‘simulate’ the requirements in the Review experience – like a prototype, bringing them to life, interacting with them and experiencing them Fourth – related or traced requirements are instantly accessible, meaning you get the context of the requirement – knowing what it depends on, and what depends on it. This means you don’t have to keep your fingers marking different pages in the huge requirements document and flipping back and forth Fifth – historical versions are also instantly accessible. You can see the entire life of the requirements, see when and why things changed, and even go back to see what things were like in an older version Sixth - your feedback is provided right inline, attached to the requirements your talking about so nothing gets missed Seventh – your comments can be part of discussion threads with other reviewers. So instead of reviewing in isolation you engage with other reviewers and the facilitator clearing up issues and misconceptions early in the review process instead of just feeding them back to the author. This approach makes requirements understandable and is far more engaging, and can really reduce that ‘Blind Approvals’ syndrome.



Presenter

Presentation Notes

Blueprint users benefit greatly by receiving feedback directly within the requirements application, which has several advantages over using ‘Track Changes’ in a document. -First the feedback tends to be of higher quality because the reviewers could interact with each other, and with the review facilitator (usually the BA) during their review – instead of reviewing in isolation. So their questions could be answered, their assumptions validated, issues discussed, WHILE THEY’RE REVIEWING and then it’s the resulting input after ALL OF THAT which is fed back and acted upon The other thing is that each of these discussions has ‘states’ that the BA uses to facilitate their change workflow. It essentially becomes their to-do list where each piece of feedback can be acted on then closed off when done. It also lets you see all feedback from all across the project in one consolidated view that can be filtered by person, date/time, state, or area of the project – making it very easy to locate the specific feedback you’re looking for.

Example: Visualize your requirements


Presenter

Presentation Notes

Blueprint lets users express requirements in using text … but also with a wide range of visual editors. Business Process diagrams, domain diagrams, use case diagrams, user interface mockups, storyboards, and generic diagrams for example The very important thing here is that they are all integrated … The data elements on the Domain Diagrams are referenced from the Business Processes, The swimlanes in the business processes can be related to the actors … which are related to the use cases … whose steps have user interface mockups on them … which can also be strung together in a storyboard sequence. And all of this together can be brought to life in a simulation of the future application – kind of like a prototype that you can walk through and interact with. This type of visual expression of the requirements is maintained in the application, and is far, far more understandable by those who need to review and later work from the requirements.

Example: Managed Dependencies


Presenter

Presentation Notes

As you’ve seen in the examples so far Blueprint has extensive requirements definition capabilities using Visual formats and Social Features, AND its also has very practical and efficient traceability as well. So there’s a few points you need to consider when deciding on how to automate the management of traceability. First the traceability information should exist WITH the requirements themselves instead of off in some totally separate artifact like a spreadsheet. Second, these relationships have to be very easy and natural to create –often relationships and dependencies are first discovered during elicitation sessions and its very important they not be lost, so the tool cannot get in the way. Third, while everyone is working with the requirements – either analyzing them, reviewing them, maintaining them, working from them – the relationships need to be indicated and obvious with the requirement itself. So many errors happen when people are working with requirements and important dependencies aren’t considered. If you look a the little picture at bottom right you see an indicator above some of the shapes. These indicators appear throughout Blueprint in every view, on every diagram, to show where relationships exist. Clicking it then brings up the exact list of dependencies for that item. This keeps those important relationships top-of-mind while working. Then the last point here is leveraging these relationships to do very important things like: ensure coverage of requirements, to manage scope during development, to assess impact when requirements change. Blueprint Users click a button at any time to immediately see the current state of relationships in a traceability view (shown here). Now this view is completely filterable ……. You can just look at requirements from certain areas of the project You can just look at certainly kinds of requirements or diagram elements It can be very precise .. .for example you can show traceability to an individual use case step, or an individual control (like a dropdown list, or radio button) on a screen. So these are just some examples of how the critical job of managing dependencies can be horrendously difficult and labor-intensive when using spreadsheets … or can managed efficiently and provide immediate answers with modern requirements applications like Blueprint.

Example: Automatically generated tests


Presenter

Presentation Notes

Blueprint users are able to automatically generate a comprehensive set of user acceptance tests from the requirements information This is a set of tests that exhaustively covers all possible user scenarios as expressed by the requirements They are well-formed tests … meaning EVERY step has a user action, and a corresponding expected outcome from the application that you can check off as being met or not. It also provides complete traceability back to all the requirements information so you’re able to ensure coverage and track progress in terms of how many requirements have been successfully tested Finally …. These tests can be output to a spreadsheet, or automatically integrated into HP ALM (Quality Center) or Microsoft TFS.

Example: Requirements ‘rationale’ stored and accessible.


Requirements Mapped to original Business Need

Requirements Traced to source documents and materials

Discussions that lead to decisions are ‘attached’ to individual requirements artifacts

Presenter

Presentation Notes

When organizations that use Blueprint transition their applications from Development into Operations they’re able to pass on the Blueprint repository which has not just the requirements, but all the “WHY” information that gave rise to the requirements. - For example all the requirements information is completely traced back to the original business need - expressed for example as business requirements, business rules, business processes, domain diagrams, and so on. The requirements in Blueprint also reference back to all relevant source documents or materials – things like standards, regulations, or guidelines that have to be adhered to And as I mentioned before, all that feedback and discussion that leads to decisions is directly associated – or attached – to the individual requirements, for anyone to back and look at. So organizations using Blueprint are able to go into the requirements and instantly access all this background information for any requirement at a click of the mouse.