Tag: Enterprise

The Value of a High Performing Business Analyst

ebborn July9“The hottest job in IT right now might be the least “T” of them all: business analyst”. Computerworld Tech hotshots: The rise of the IT business analyst By Michael Fitzgerald July 11, 2012

I have been a Business Analyst for almost sixteen years of my twenty six years of professional life however I have only known what to call myself for the last nine years; a Business Analyst! During my career I have been referred to as a management consultant or IT consultant but both these roles use skills, knowledge and competencies of the Enterprise/Strategic Business Analyst which is a new role that has emerged out of the International Institute Business Analysis IIBA® Competency Model in 2011.

At the company I work for we have been helping more and more companies to think about “why” we doing an initiative or project instead of just doing something that provides little or no value to an organization. 

Recently my company was engaged to analyze a cash handling business process after an audit report raised concerns over staff counting cash. In our first executive stakeholder meeting we asked the question “Why are you still using such a large volume of cash transactions, when your customers are used to credit cards and the organization was already using an internal customer card which held monetary credits and if marketed correctly would encourage return patronage?”. Pretty quickly we understood that the better solution was to reduce the use of cash rather than reengineering the cash process.

Another client wanted to implement a bar scanner into a warehouse to check stock in and out. After completing an analysis of the stock it was discovered that over 40% of stock had no barcode and would therefore need to be bar-coded. Of the 60% that had a barcode 20% was sold as individual items i.e. box 24 items, which needed to be unpacked before a barcode could be added. We asked the client how many warehouse staff were currently employed and if they could handle the additional workload needed to barcode. The answer was no and it was estimated that an additional 2 staff would needed to be employed. We determined that the Return on Investment (ROI) would be negative and that as a strategy adding a barcode scanner into a warehouse would not be an advantage with the amount of unpacking and bar-coding required. Although this consultancy sale did not proceed our business analysis resulted in the client making the decision not to implement a barcode scanner (the right business outcome) and we were happy we didn’t work on something with little purpose or value to the client.

In yet another example of the value of a business analyst one of our clients sought a solution to manage the approval processes and associated documentation for a number of major energy capital projects (projects up to $100 million in value). My company performed the business process automation analysis, mapped the future state processes, and elicited the business and functional requirements through a series of stakeholder workshops utilising aspects of our method, and customised templates, which aligned with the Business Analysis Body of Knowledge (BABoK®). Based on these documented processes and requirements an automated workflow solution was developed. This process automation solution delivered: increased consistency of approval processes; an automated audit trail for the approvals; a reduced incidence of approval related documentation being misplaced or lost; a reliable mechanism for staff to determine the status of payment requests and payments; reduced time and resource wastage on printing and manual approvals; and reduced physical file storage. A key outcome of the project was the minimisation of approval delays, which reduced the external contract resources required for approval processes. The savings due to the reduction of external contractors during the first 6 months after the automated workflow solution was implemented paid for the cost of developing the solution.

Until recently the role Business Analyst (BA) was loosely defined and the activity, tasks & techniques used varied from organisation to organization. However, with the release of the BABOK in 2006 by the IIBA® the BA role has been defined within the knowledge areas providing an international standard for this beneficial role.

Definition of Business Analysis

IIBA® – “Business analysis is the set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals”.

Definition of a Business Analyst

IIBA® – “Business analysts must analyze and synthesize information provided by a large number of people who interact with the business, such as customers, staff, IT professionals, and executives. The business analyst is responsible for eliciting the actual needs of stakeholders, not simply their expressed desires. In many cases, the business analyst will also work to facilitate communication between organizational units. In particular, business analysts often play a central role in aligning the needs of business units with the capabilities delivered by information technology, and may serve as a “translator” between those groups”.

In summary a business analyst is a role, that involves working with key stakeholders to elicit requirements to enable the delivery of solutions to achieve the organizations goals and objectives i.e. deliver services and/or products. The solutions provided maybe Information Technology (IT) related, non-IT related or could be process improvement.

Business Analysts may range in levels from people starting out in the role to highly skilled people with 15+ years experience. In the past it was often thought that the role of the BA was just a stepping stone towards a Project Manager or Architect however we have seen in the last few years the development of a career path from entry level BA through to an experienced BA and even to CIO or CEO.

John Simpson in his article “Why on Earth Would You Promote a Business Analyst” talks about a Chief Business Analyst “By championing the development of thousands of well-written requirements and collaboratively managing them throughout your innovation process, your staff of business analysts significantly impact the performance of your company every day. And, that makes them a strategic asset.”

Either way the role of a “high performing” business analyst will be more and more valued in the future as organisations continually look to be more innovative to survive and prosper.

Don’t forget to leave your comments below.

Gap Analysis Expanded – Vision-Schmision Part 3

ferrer April30 IMG01Motivation:
Gaps are everywhere – just look

Ingredients:

Triggers to Action – External & Internal
Raw Vision (Requirements Stated)
Any Enterprise Architecture not limited to:
       Organization (Business) Goals & Objectives
       Performance Metrics
       Organizational Process Assets
       All Solutions [Constructed, Deployed]
Ten Stakeholder Types
All Information Available on Risks
Business Analysis Resources As Needed

In Vision-Schmision Part 1 we were handed some “Raw Vision” (Requirements [Stated, Barely]), masquerading as some kind of “cost justification” related to going “paperless.”  In BOKworld this looks like:

ferrer April30 IMG02In Part 2 we took the raw vision to the kitchen and mixed it up with Business Goals and Objectives, resulting in more of a Business “Knead”:ferrer April30 IMG03

Our “dough” (we ARE shooting for a business case 🙂 ) is still quite raw. At the end of part 2 it looks like the following (bonus points to those who spot gaps in the “knead” not already noted below):

Problem/Opportunity (Business Knead from Part 2 🙂 )

Recent improvements in automated scanning technology suggest it might be economical and effective to further (we do already have email) reduce the use of paper in our organization. Our current goals and objectives are: 

  1. Improve student satisfaction from 82% to 90%.
  2. Increase fall enrollment from 37,213 in 2012 to 41,500 for 2013.
  3. Freeze hiring at 2012 levels (1017 employees).
  4. Reduce employee turnover from 10% per year to 5%.
  5. Reduce dropouts from 3723 per semester to less than 1500.
  6. Improve community relations by expanding English as a second language (how measured?).
  7. Cut archival costs by 90%

Known problems and opportunities related to the use of paper include, but are not limited to:

Specific Issues:

  1. Bottlenecks / slowdowns in the student admission process due to sharing the paper application file (any process models – use cases, user guides, flowcharts, meeting notes documenting known issues with the process?). Our biggest competitor can give a prospective student an admission decision in less than two weeks, while our average is currently 5 weeks. While we do not know how many students we lose because of this (how many do we lose for reasons that we know?), surveys show that over 30% of our applicants complain about the delays (were surveys limited to applicants in our systems – did we lose prospects who never applied on line?).
  2. Lost or misplaced (how many of each kind?) student transcripts delay financial aid, which we believe is the cause of half of our 3723 student dropouts last semester. Financial aid delays can stretch for months instead of weeks, and always contribute to admissions delays.
  3. Grades are being computed and delivered on paper (by whom?), for entry into a grade reporting system (by whom?). When questions arise about the grade, there is no detail to explain how the grade was awarded (what details might be needed?). The student must fill out a form to formally request explanation from the faculty member. The student ombudsman receives about 200 grade related complaints every semester. The number of formal forms submitted each year is less than 5. The reasons for the difference are unclear? There are approximately 37K students enrolled).
  4. Archival costs (how much, for which services?) seem out of control due to repeated need to access already archived documents. These documents are often related to students who are taking longer than normal (what is normal, and why?) to finish their degrees. We need better (by what measure?) policies and electronic search to reduce this repeated manual searching (how can we quantify this?).

    General Issues:

  5. Departmental managers recently estimated (how?) that an average of 10% of employee time (all employees are affected equally?) is used for filing, handling and re-filing various kinds of paperwork. These include, but are not limited to (are there estimates of quantities, time impacts per document?):
    1. Health care
    2. Counseling
    3. Housing
    4. Part-time work
    5. Hiring (and other HR functions)
    6. Regulatory compliance
    7. Legal work
    8. Grading
    9. Ombudsman cases
    10. Veteran’s educational benefits
    11. Fraternity & student organization oversight
    12. Faculty mentoring and counseling
    13. Preparation and follow-up for management meetings
  6. It is anticipated that more specifics are to be discovered if a decision is made to further analyze and detail requirements for a business case (we shall so decide 🙂 ).
Now, for Part 3 we consider how to “Assess Capability Gaps”:ferrer April30 IMG04

Formally, the BABOK says that this task consists of comparing an “AS-IS” (model) to a “TO-BE” model. Informally, we are seeking requirements, especially missing ones (requirements gaps). To have a good “AS-IS” we need to know we are not missing anything. A good “TO-BE” won’t be missing anything large or important. We have gaps to fill even BEFORE we formally identify “capability gaps”. Once we know enough to specify an AS-IS, we can focus on identifying the bottlenecks that are impeding closing the gaps between current indicators/metrics and target state indicators/metrics. Fixing these bottlenecks gives us potential “TO-BEs”.

The “numero uno” cause of “gaposis” is the failure to understand the needs of one of the stakeholder types. Look for gaps by considering ALL ELEVEN stakeholder types and their needs: 

  1. Customers – DO NOT fall for the idea that Information Technology must treat the business people as customers. It is always nice to be nice to people, but IT must help the business people treat paying customers as customers. This is not the same thing as making IT happy – not the same thing at all.
  2. End Users – If they don’t understand, it means you don’t understand – the more end users, the better. It is possible to have too many to manage, but that is less common. We tend to speak with those end users most friendly to the project. Don’t forget to talk with some hostile “end abusers” – they know stuff too :).
  3. Domain SMEs – The box that you are inviting to think outside itself. If there are no changes to what Domain SMEs already know and do, there are no requirements. If you get resistance to exploring necessary changes, offer to report that there are no requirements, while smiling really hard.
  4. Implementation SMEs – Once known as the glass box, they are becoming “cloud”ier. They are missing money, mostly, along with any serious involvement from the business side. In this BA’s opinion IT investment is generally ½ to ¼ of what it could be. It seems expensive to develop high quality requirements, especially rapidly. Rapid development means heavy business stakeholder involvement. Do what you can to get money and people for IT (use your business case mojo for IT too). Don’t fall for IT’s occasional “we can’t do that, it is too [hard, expensive, politically impossible, outside of scope]. When such statements are offered, ask them what it would take to overcome, and negotiate. What they build isn’t for them, it is for the business – remind them if you must.
  5. Suppliers – If you don’t trust them with your future implementations, why do you buy their stuff at all? Consider involving them early, especially if their performance affects yours (which it does).
  6. Testers – One requirement equals One Hundred tests – work with them early and often or they won’t be able to finish on time. If they are bored waiting for your requirements, engage them in developing requirements.
  7. Operational Support – It is NOT NEVER NO-HOW “just an install”. Dump purchased software (or new policies) on operations without requirements and you will see what I mean. The minimum requirements gap to fill with operations is in understanding load (performance) requirements. Real changes in technology require MUCH training, planning and impact analysis and other Transition requirements.
  8. Regulators – here, there are only gaps in conscience and execution, as requirements are usually spelled out in words and in spirit as well.
  9. Business Analysts – are you REALLY advocating for what you need (BAPM on the head with BA Planning), or just saying yes to the project manager?
  10. Sponsors – Don’t let them build skyscrapers without blueprints, nor enterprise systems.
  11. Project Managers – Scopes based on Visions are Hallucinations – help them understand where refinements to scope will help them make time and money deadlines with USABLE solutions.

Another place to look for gaps is in Enterprise Architecture (AS-IS). When a solution fails, the failure tends to show up as a failure to accomplish the work of the organization. What IS the work of the organization? Can you list at least 150 processes in less than a day? Try it – it pays in reduced “gaposis”. The more you know about your business, the less likely you are to recommend requirements that will “break” things. 

A wonderful recent example of forgetting business work process in favor of systems was NetFlix, who imagined how much better their systems could be if they divided “on line” subscriber services from “DVD” snail mail subscriber services. The forgot that the process for their users was (AS-IS):

  1. Sign up for an account (once)
  2. Search for movies you want to see.
  3. Put the movies you want in a queue (DVD or online).
  4. Watch the movie when it shows up in the queue (mail or instant view).

They imagined the users wouldn’t mind the following changes, which would make their business systems much simpler (TO-BE):

  1. Sign up for an account (twice)
  2. Choose which list to search for movies – online vs. DVD
  3. Search for movies you want to see
  4. Put the movie in its queue (online vs. DVD)
  5. Choose which queue you want for selecting the movie you want (if you remember)
  6. Watch the movie (if you find it)

Hmmm – better for users, or better for coders? 

Another quick and dirty “gap analysis” is to use BABOK requirements types. As a BA, start with the business requirements, which are almost always missing . “No way”, you say. “Way”, I reply, since good business requirements must have good indicators (the thing we will measure) and metrics (the quantity measured), and these indicators and metrics can be quite rare. “Increasing sales” is NOT a business requirement, nor is “increasing sales 10%.” If you disagree, it means that cutting prices 50% could be a solution, as this would surely increase sales at least 10%. Business requirements – often missing – look out!

As for stakeholder “requirements” (Requirements [Stated, Confirmed], according to the BOK), their “gaps” (wishes, misconceptions, ignored innovation opportunities) are found in analysis towards Solution and Transition requirements, after the AS-IS, TO-BE and the full business case are better understood.

Last but not least, remember that risks are a HUGE source of “gaps” in requirements. 

Example 1: Risk of users rejecting new application – 50%. Mitigation – make the application REALLY work for the users, not just for management. This is where the “business requirement” for ease fo use comes from, easy and fun, fewer steps, better interface.

Example 2: Risk of misuse of application data – 90%. Mitigation – make sure that the data requirements are modeled to reflect the true domain (customers have many addresses, addresses serve multiple purposes, addresses serve more than one customer). If we make one address per customer, and one customer per address, we only make life difficult for the users, who must work in the “real world”.

There is much, much more (ask for “pain points”, perform “external analysis” of competitor’s capabilities and changing trends, look for regulations and other solution documentation, understand the history of the “AS-IS” so you don’t regress it and break other requirements. Example: Original Requirement: Quality, validated data for 99.9% accurate reporting. New “request” (requirement [stated]) – users want to load spreadsheets in bulk, skipping validation. You would think the new request would be ignored (“my job is too hard, let me do a worse job”), but this requirement was actually implemented by a client, defeating the data validation.

Again – stir these new ingredients well, rewrite “them requirements as what needs rewriting”, and don’t forget to leave your comments. 

Next month: The Schmision takes on “AS-IS” and “TO-BE” as we look at the BOK formal “Assessment of Capability Gaps”. We will notice that in our organizations, “Solution Approach” and “Solution Scope” tend to precede capailbity gap analysis, as we seek to escape the hard work of evaluating the original “vision” for what it (most often) is – a rush to solution. 

P.S. Look up “vision” requirements in BABOK, and you will find they are mentioned explicitly as not likely to be “ongoing” requirements. Betcha! What do you think?

Don’t forget to leave your comments below.

Cooking The Business Case – Vision-Schmision Part 2

Ferrer March26 Img01Last month we saw a “cost justification” posing as a business case. It showed money but, but it did not show WHERE to find the money. Nor did it show how the “paperless” tactic aligns with the goals and objectives of the organization. It did not show any requirements at all. The implied requirement (“Replace all paper with scanned documents?”) is a very, very, very low-quality requirement, and nothing like a vision at all.

A vision paints a picture clear enough to reach for. “Scan all paper” is not even close. What about junk mail? Can we ditch the office printers? What indexing, if any, & who decides how? What about email “documents”? Restrooms?

This month we will combine the ingredients listed above (slightly changed from last month’s list – hooray for iteration and a shout-out to Peter Gordon, CBAP for peer review!). We will use a proven recipe to “COOK” the business case, instead of throwing the kitchen at a sinking project later.  🙂

Every Business Case must start with preparation of a well-formed Business Need. Start by sifting through the Business (Organizational) Goals and making sure they are refined into edible objectives (Specific, Measurable, Attainable, Relevant, Time-bounded – BABOK® section 5.1.4.1). Mix in any new objectives that are missing (gap analysis one) to balance the vision and let rest for 24 hours. Allow conflicting or ambiguous objectives to rise to the top. 

Use any available whisks (risks) to beat the Sponsor (Stakeholder type 1) into the mixture until the raw mixture is clarified. Chef’s note: When this process fails, it is typically because of sloppy (or no) Measurement leading to irRelevant objectives. It may be better to throw such a batch out right away and start again, while is cheap and easy. Without measurement everyone is unsure of the recipe even though they know the time left to bake. Even if personal taste approves of the final dish, no one will be able to say exactly why. Such dishes will be difficult to duplicate, and appeal to narrow tastes.

If the vision clarifies, refrigerate it overnight (Business Requirements [Stated]). After additional stirring the following day, use the aroma of the clarified vision with the sponsor as a guide to specific stakeholder sauces worth adding. Make a BA Plan to quickly hunt real meat from a sample cross-section of steakholders – (some say puns are the highest form of humor. Some don’t 🙂 ). 

Following the BA plan, mix the clarified vision with validation and other input from the 10 stakeholder types (BABOK section 1.5.6.1, figure 1-3. Including the BA there are 11). To avoid unnecessary boiling, keep the types apart before blending their flavors into the mix. Grind any distasteful issues or problems until their root causes float to the surface. Use honey (opportunities) to catch any flies in the kitchen. Remix until all stakeholders are nodding (use alcohol if it helps, or doughnuts and coffee). You will know that the business need is ready when every stakeholder has identified desired (and S.M.A.R.T.) outcomes for the meal to be served.

For the “paperless” meal in question we had this “implied Business Need” last month: “We are going paperless to save $5M.” Compare that to what might emerge from the recipe above, shown below:

Problem/Opportunity:

Recent improvements in automated scanning technology suggest it might be economical and effective to further (we do already have email) reduce the use of paper in our organization. Our goals and objectives are currently as follows: 

  1. Improve student satisfaction from 82% to 90%.
  2. Increase fall enrollment from 37,213 in 2012 to 41,500 for 2013.
  3. Freeze hiring at 2012 levels (1017 employees).
  4. Reduce employee turnover from 10% per year to 5%.
  5. Reduce dropouts from 3723 per semester to less than 1500.
  6. Improve community relations by expanding English as a second language.
  7. Cut archival costs by 90%

Known problems and opportunities related to the use of paper include, but are not limited to:

Specific issues:

  1. Bottlenecks / slowdowns in the student admission process due to sharing the paper application file. Our biggest competitor can give a prospective student an admission decision in less than two weeks, while our average is currently 5 weeks. While we do not know how many students we lose because of this, surveys show that over 30% of our applicants complain about the delays.
  2. Lost or misplaced student transcripts delay financial aid, which we believe is the cause of half of our 3723 student dropouts last semester. Financial aid delays can stretch for months instead of weeks, and always contribute to admissions delays.
  3. Grades are being computed and delivered on paper, for entry into a grade reporting system. When questions arise about the grade, there is no detail to explain how the grade was awarded. The student must fill out a form to formally request explanation from the faculty member. The student ombudsman receives about 200 grade related complaints every semester. In spite of this, the number of formal forms submitted each year is less than 5. There are approximately 37K students enrolled).
  4. Archival costs seem out of control due to repeated need to access already archived documents. These documents are often related to students who are taking longer than normal to finish their degrees. We need better policies and electronic search to reduce this repeated manual searching.

General Issues:

  1. Departmental managers recently estimated that on average 10% of employee time is used for filing and re-filing various kinds of paperwork related to student, faculty and administrator needs. These include, but are not limited to:
    1. Health care
    2. Counseling
    3. Housing
    4. Part-time work
    5. Hiring (and other HR functions
    6. Regulatory compliance
    7. Legal work
    8. Grading
    9. Ombudsman cases
    10. Veteran’s educational benefits
    11. Fraternity & student organization oversight
    12. Faculty mentoring and counseling
    13. Preparation and follow-up for management meetings
  2. It is anticipated that more specifics are to be discovered if a decision is made to further analyze and detail requirements for a business case (we shall so decide 🙂 ).

Reasonable people may notice that the above is far from complete, or even remotely detailed. It certainly isn’t a business case at this point, and is just barely a “Business Need”. There may be premature “solutioning”, more “root cause” work needed, and almost certainly major gaps (are we “collaborating” on documents or just “sharing” them?) What solutions or workarounds already exist? Can these be improved without new acquisitions? How many employees will have to change what they do? How will the employees find out, and what will that cost?

The above is not correct, clear or complete or concise. Hey, it’s just a blog! The point is to compare the above with the information in the cost justification last month

Which imperfect, incomplete example offers more guidance as to next steps? Which offers some hope of “stakeholder success criteria”? Which one suggests specific questions? Which one helps identify specific “gaps” in knowledge? Which one is more typical of “failure mode”, which one has a greater chance of consensus? 

Having kneaded the Business Need, and allowed it to rise, we are ready to continue with the recipe. Without a high quality business “knead”, there is nothing to cook.

NEXT TIME: Part 3: Filling the Gaps in Gap Analysis.

Don’t forget to leave your comments below.

Vision-Schmision, Where’s The Business Case? Part 1

Ferrer Feb26 Img01The first time I ran into a Project Manaagement Office (PMO) I was delighted! I loved the idea that projects might be researched and understood before the really big checks were written. The PMO Director explained: “Anyone who wants a project funded has to submit their request to the PMO. A committee reviews the submissions and decides which projects can be initiated.”

“What do the requestors submit?” I continued. “How much analysis is required for a given business case? What kinds of projects get funded?”. The PMO DIRECTOR beamed as she explained “We are using a software to manage the PMO, and requestors have to fill in all required fields, including a cost estimate and projected benefits.” We both looked over the screen as he went on. “This is the information that is used by the committee. They use it to choose a mix of large, medium and small projects.”

The answer to my next question woke me up: “I see the cost field and the benefits field, but where is the business case that calculated the costs of the changes and how those changes result in benefits?” The PMO DIRECTOR replied dismissively “Oh,  this software has a place where you can attach anything you want. We don’t require the attachments, as long as everyone agrees that the project is justified. You only need a detailed business case if people aren’t sure that the project is worth doing.”

Carefully, seeking greater understanding, I suggested: “How hard would it be to look at one request where people weren’t sure about a project?” “Sure”, came the quick reply. “When we needed to do document management, every department had to give estimates. At first, no one could agree on the right way to combine them, and we had meeting after meeting. Eventually the different approaches were reconciled and combined into one spreadsheet that showed we could put in a document management system for less than $3,000,000 and save more than $10,000,000.” As the PMO DIRECTOR navigated to the project in question I imagined that the involvement of many departments COULD mean a high quality business case. It would be natural for there to be disagreement with so many “first drafts” in play by so many different authors. I figured this disagreement COULD result in discussion and refinement and improvement of the different departmental analyses and approaches. With luck the approach agreed on would align with and illuminate some of the changes* needed to achieve business goals and objectives.

“Here’s the project, and here’s the spreadsheet” said the PMO DIRECTOR. “I’ll open it.” Here is a slightly summarized, “changed to protect the innocent”, version of the information I saw:

Cost Benefit Justification for Going Paperless at Organization X 

The following are a consensus based on Sums and/or Averages of Dept Estimates:

Ferrer Feb26 Img02

The following are Dept Page Estimates: 

Ferrer Feb26 Img03

At this point I decided to keep my mouth shut. The project had been “justified” – 5 million dollars justified, and not a single requirement in sight (nor any NPV, IRR etc, but let us not go there – not just yet). Deals were going to be made, software and equipment was going to be purchased, and vast amounts of time would be spent setting it all up and outsourcing training, and replacing, etc., etc. Nothing would stop this juggernaut, and it was not in my specific scope, which applied to BA on future projects only.

Once I saw how “business cases” were built in this organization, I went back to basics in my mind (is there anything else?). It would take a lot of thought to explain the basics It was going to be COMPLICATED to explain the difference between justifying a vision (what the organization was doing) and creating a business case (a true cost-benefit analysis and a key guide to next learning steps). If I failed in making this point it would be hard to help future projects, since my assignment was quite temporary. 

I glanced at the business case on the screen one last time. WHAT IS the Business Need? Just saying MONEY doesn’t count as a useful Business Need. Everyone wants money (except that adorable little girl who thwarts Jimmy Fallon’s pitches on television). The trick isn’t wanting it, it is figuring out how to make it so. This is TRIPLY true in non-profit or governmental organizations focused on MISSION over money. How would scanning documents lead to the savings or the mission to be accomplished? WHAT WOULD CHANGE* and what would those changes cost? What if our ideas about what would change, could change or should change or did change? How can we succeed when so much could change? What will the potential cost of employee turnover be? What benefits are we prepared to work for instead of wish for? Why do so many Document Management Projects frustrate almost as much as they help, and sometimes produce only “spare change”? Why do documents need so much management in the first place – most get used once and forgotten, others are constant bottlenecks. AS-IS, or NOT-TO-BE, that is the question? How do people continue to avoid due diligence and the most minimal level of enterprise analysis?

When will Marcos stop asking questions?  Feedback welcome, I can take it (cringe).

Next month (I trust my readers will forgive me) we will actually look at HOW to COMBINE THE INGREDIENTS listed at top, in order to “Cook the Business Case‘.

Have fun, and here is a hand picked link collection to BA Times Blogs referencing Business Cases (more available):

* CBAP 007 BA Tip – Use at Your Own Risk and With Your Own Style and Words

Whenever a stakeholder says they want a new solution for their problems, as long as nothing changes, just nod, say something like “I see what you are saying, no changes?”, and let them do most of the talking.
Don’t forget to work with many other stakeholders. Always end the statement with the “questioning inflection”, and hope they respond by saying “Yes, no changes”, and then leave you alone. Don’t think about it or even try to fix it unless you are tired of the BA job. To paraphrase Robert Heinlein “Don’t try to teach a duck to sing. It is a waste of time, and besides, it annoys the duck.” 
 
Don’t forget to leave your comments below.

2013: An Exciting Year For Business Analysts

If you ever watched the 1970s sitcom, “The Jeffersons,” you know the tune, “Now we’re up in the big leagues…” This theme song is making a comeback in 2013, but this time for business analysts (BAs)!

The new year brings new trends in requirements, collaboration, Agile, and the role of the BA, to name a few. Agile adoption and implementation will fall on the BA and user stories will be repurposed for BAs to use in an Agile environment. The role of the BA is expanding and their value is being recognized. Translation: this is an exciting year to be a business analyst!

Take a look at what is coming your way this year:

  1. The roles of the business analyst and product owner will be solidified and respected
    The BA’s role in an Agile project is to work with the product owner to help define the priority of the backlog to bring the customer the greatest value. Product owners make decisions about what the backlog is and which items should be developed first. In 2013 product owners will come to respect the role of the BA and better understand their own roles in the process, resulting in improved results from Agile projects.
  2. Strong user stories will be the force driving effective requirements analysis and product backlog prioritization. If a BA is working with a product owner, then his or her focus should be on eliciting and analyzing user stories, allowing for better prioritization of the product backlog. BAs will increasingly understand that successful user stories rely heavily on what they already know about requirements management and development (RMD). The BA’s RMD skills will be the foundation for successful Agile projects. Practice makes perfect, and in 2013 there will be a major push forward in better user story development.
  3. In 2013 it’s all about collaboration and convergence 
    The goal of Agile is to deliver a workable, usable product every four to six weeks. This goal weighs heavily on the role of the BA to help identify the “what” that the product owner needs, its value, and its priority. Consensus-driven approaches to RMD take longer and often do not achieve what the customer really wants. Accordingly, BAs will focus on elicitation skills that are based on collaboration and convergence of requirements to deliver working products on a regular basis.
  4. BAs will become the new PMs through Agile
    Regardless of title, “project managers” are not the only people who lead projects. In Agile, everyone, theoretically, is a “generalizing specialist,” meaning the Agile team has multiple, complementary skills to support the delivery of iterations on a project. In 2013 more BAs will take on this generalizing specialist role to help “manage” the iteration scope, develop better defined user stories, and prioritize the product backlog. As a result, there will be an uptake in training for BAs in core project management skills such as planning and estimating, risk, and team collaboration.
  5. BAs will be seen as the keystone to adopting Agile
    Since the BA’s core focus is on gathering requirements, organizations will realize that if they are to be successful in their Agile projects, they need highly trained professionals able to map out the AS-IS, define the TO-BE and work with the project owner to make it happen. Requirements gathering is the core function of the job and the people assigned to this important role will be seen for what they are: the keystone of success. Will this new appreciation for BAs mean an increase in IIBA’s CBAP® certification? Not if organizations don’t know about it or realize its value.
  6. The U.S. federal government will slowly recognize the value of business analysis as it becomes more Agile. Requirements management is a recognized problem within government, but, the federal government has been slow to embrace the BA title and role. However, the role of the BA has not been diminished. In fact, better RMD is a key driver for Agile in the government space, and as Agile is used on a greater number of projects, the value of business analysis as a separate discipline — practiced by highly qualified professionals — will become more apparent. With shrinking budgets and fiscal cliffs, Agile, and the BAs who practice it, just might be the extra “fire power” the government needs.
  7. Strategic enterprise analysis will become the foundation of business architecture
    Strategic enterprise analysis focuses on defining the value streams of an organization by analyzing the impact of core business processes and business capabilities to achieve strategic goals. Business architecture leverages the skills of the BA to create and maintain a set of business-owned information assets that serve as a blueprint for planning and execution of strategy. The purpose of business architecture is to define the “what” of a business, such as what it does, what it needs to meet goals, etc., which perfectly aligns with the skills of the BA. More companies will be looking to senior BAs to step into the emerging role of business architect.
  8. BA Centers of Excellence will focus on proving their worth and driving innovation
    In 2013, the BA COEs will concentrate on staffing (with senior BAs to fulfill the role of business architect) and on establishing a common, enterprise-level business language and framework for documenting how the business is structured. This will set the stage for defining the “what” of a business as it relates to strategic project investments. This trend goes hand-in-hand with the 2013 PM trend of project management offices focusing on proving their worth and driving innovation.
  9. Modeling skills take precedence in business analysis training
    Modeling techniques will be a key focus area for BAs in 2013 as these tools will become critical in depicting the impact of solutions on the business. As such, the written word will continue to slowly lose its appeal and significance when describing solutions and impact to customers.
  10. Communicating “up” will become critical to articulating requirements’ impact on a deliverable.  In most cases, BAs understand the effect a requirement has on the solution, as they are intimately aware of the needs of the business. However, many BAs struggle to communicate the impact of these requirements to a broad spectrum of people, especially those at higher levels in the organization. BAs will recognize that their careers will be limited if they cannot have these crucial conversations and, consequently, they will concentrate on how to communicate “up” through practice, training and mentoring. In doing this, the BA will be viewed as even more of an invaluable resource and a main point of contact for business capabilities.

Every new year, in every industry, change is inevitable. In 2013 business analysts have many challenges to face, but also many exciting changes to look forward to, including some well-deserved acknowledgement. Prepare yourself for what is around the corner: more responsibility coupled with more respect, a bigger burden to prove the worth of the BA and a bigger realization of the BA’s expertise by the organization. This is an exciting year for BAs in general; make it a meaningful and successful one for you.

Don’t forget to leave your comments below.