Tag: Business Analysis

What the 2015 Trends Mean For Business Analysis and Project Management

Written by Elizabeth Larson on February 16, 2015. Posted in Articles.

In January we wrote an article like we do every year about the upcoming trends in business analysis and project management. In this article we want to discuss what these trends mean for practitioners of business analysis. Below are the seven trends we discussed in last month’s article and a short description of each.

Table 1 Seven Trends

Original 7 Trends	Short Description
Distributed leadership	Leadership will become more distributed and will be increasingly as much about tapping into the leadership of those around us as it is about a single visionary, decision-maker, and communicator.
Design	Organizations who start providing “logical” or “conceptual” design outputs as part of building apps and business processes will shrink the gap between business needs and functioning products and create better products faster.
Schizophrenic approach to certification	Both the trend to become certified and the trend to reject certifications will play out in 2015. With the increased popularity in MOOCs (Massive Open Online Courses), counterbalanced with the rise in the number of PMs interested in business analysis means that many practitioners will want certifications, while others will question their value.
Innovation and entrepreneurship	To go beyond mere process improvement, organizations will need to become more entrepreneurial. Innovation centers and hubs are on the increase, and companies are investing in their own incubators away from their main operations to help spur the creative process.
Changing culture through Agile team training	Agile training will be geared toward entire teams rather than individuals. Agile is going to drive organizations to seek more effective ways to generate a change in project practice. NOTE: we’ve expanded this trend to address the need to change organizational culture quickly. This is the focus of today’s article.
Balance in project governance	Organizations will continue to struggle to find balance between the extremes of project chaos and centralized project governance. Ultimately some projects will require more governance and some less.
Making Agile work for organizations	We predict that organizations will find a way to make Agile work for them by becoming more purposeful in how they choose to adopt it.

Helping organizations change – quickly. We believe that organizations are crying for new ways of doing things and that simply saying that they want to offer new products or services means ramifications greater than running a press release or having the CEO or agency head announce the decision. Many operational areas will often be impacted. People will have to learn new business processes, use new software, often buy new hardware, and sometimes report to new managers. They will have to learn how to sell, reorder, merchandise, and/or support the product or service. Often most challenging, though, is its acceptance, which requires changing the organizational culture.

Project managers will need to understand that the project’s focus has to be more than on implementing the new solution. Business analysis practitioners will need to help the organizations prepare for the change. They will need to work with affected operational areas to help them understand what the change means for them, the difference between their current world and how it will be different going forward. BAs and PMs have talked for decades about how slow it is to change organizational culture. We have used the analogy of trying to move a big cruise ship around in the ocean. Yet organizations need to find a way to change the culture more quickly.

Those who survive and thrive will have to be culture changers or contribute not just to helping organizations change, but helping them change more quickly. To help us understand this important concept, we have taken our 2015 trends and categorized them areas needed to enable change quickly. Those four categories are:

Distributed power. The first has to do with Power, the ability to impose our will—to get people to do what we want them to do. There are many ways people use power. We might threaten a punishment, offer a reward, or overwhelm them with what we know. We can use our authority, that positional power that comes from our place in the organization. (Well, some people can, typically not BAs or PMs). We can use all those forms of power, but none of them is affective as using our leadership skills, the power that we have within us to communicate our vision, to offer direction, and to have others follow us.

Distributed power means that organizations will have to accept that relying on positional power, in other words authority, will slow them down. The idea of power and decision-making in the hands of executives, directors, managers, or supervisors, or any one individual will cause delays. Going forward we expect that different people will take leadership roles at different times. Any individual might step up in a given situation, but not all situations. We’re saying that not only does leadership need to be distributed and more local, but power does as well. This might include, for example, the ability to reward people. Getting things done quickly will rely on decentralized project governance and self-organizing teams.
To use an Agile example, the scrum master might sometimes act as a leader. But if they do, it’s not based on their role, but on their ability to communicate with the team and the organization to remove impediments and resolve problems.

Practical solutions. Being innovative does not mean throwing out everything an organization does and starting over. Innovative solutions need to work. Organizations need to be able to implement them into their organizational cultures. Generally speaking, organizations are moving away from centralized project practices, one size fits all approaches in favor of choosing approaches best suited to each project. Top-down hierarchical communication is disappearing. Why? Because it takes too long to get anything done that way. Meetings need to be run more flexibly. Going fast are the old days of tight agendas where the meeting “leader” (usually us) controlled everything. Today’s meetings tend to be more informal, with neutral facilitators rather than meeting leaders, with participants scribing as needed, and where decisions are made more quickly.

Business analysis work is needed regardless of the project type. A rose by any other name is still a rose and business analysis is business analysis even if we call it systems analysis, business systems analysis, conceptual design, etc. We’re still doing business analysis when we manage requirements, do business systems analysis, design, logical or conceptual design, when we go about getting the detail needed, and whether or not it is done by BA, PM, designer/developer, part of the development team or someone else. And this work will not go away, regardless of the trend in development methodologies

Influencing without authority. Those who can’t influence will not add value and if they don’t add value, they will not succeed. Being innovative will require being able to influence those who don’t work for us. We will need to be collaborative and work through others to help organizations succeed.

The table below lists the seven trends and shows their relationship to the four categories. Each trend falls into multiple categories and each category contains multiple trends.

7 Trends	Distributed Power	Focus on the Practical	More Business Analysis Work, Less BA Role	Influencing Without Authority
Distributed leadership	X	X	X	X
Design		X	X
Schizophrenic approach to certification				X
Innovation and entrepreneurship	X	X	X	X
Culture changers needed	X	X	X	X
Balance in project governance	X			X
Anything agile	X	X	X	X

Summary. The key to being successful in business analysis and project management is to understand that business analysis is not going away, but how we do it is changing. To be successful we will have to offer quick, practical solutions. If our current job is to elicit and document requirements, it will decrease in value. If we’re project coordinators or schedulers, our jobs will also decrease in value. We need to get out of the business analysis and project management assembly lines. We need to spot opportunities and use our influencing skills to encourage organizational change needed to take advantage of those opportunities

So here’s the bottom line –we will have tons of freedom to be creative to do the right thing for the organization. It’s going to be easier for those of us who want to make a difference in our organizations and in the larger professional community to be able to do so. And this is very, very good news indeed!!

Don’t forget to leave your comments below.

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.

5 Considerations When Taking an Enterprise Architecture Approach to Core System Transformation

Written by Doug Jackson on February 16, 2015. Posted in Articles. 1 Comment on 5 Considerations When Taking an Enterprise Architecture Approach to Core System Transformation

Many financial organizations find that it’s easier to just keep patching old technology rather than to make the kind of major changes to their core systems needed to become the business they really want to be. So, they keep pushing major transformations off, until one day the risks of maintaining the status quo become overwhelming.

Unfortunately, when legacy/core modernization projects are under time pressure, they often fall victim to the very issues that their solutions are meant to address—inefficient business processes, redundancies, and information not getting to the appropriate people at the right time.

Ensuring that one of the most challenging initiatives an organization undertakes is done correctly requires a holistic perspective that considers not just the IT questions, but also addresses the processes, resources, and more.

Taking an EA Approach

Leadership at one insurance company came face-to-face with these issues when it identified the number one risk to its future: aging legacy systems supporting critical policy administration functions. Its enterprise analysis approach had five key aspects:

1. Architecture First

To enable business growth and change, the insurer established an enterprise architecture (EA) group. The EAs completed a comprehensive inventory of the various capabilities across the company, including those involved in policy administration. This let them focus on the aspects of the business that would be impacted by the change.

2. A Product Prism

Product architecture is often overlooked in discussions of systems transformation. However, when looking at its product offerings, the team discovered that two major divisions within the organization structured their insurance products differently and used the same terminology in different ways. If not corrected, or at least identified early, this situation could negatively affect being able to bring in a new policy administration solution created to unify the company’s work.

3. Business Processes

The inventory the EAs created allowed for the creation of a hierarchy of the business processes currently in place. A significant portion of the project was spent eliciting and documenting information about as-is processes and where they could be improved. This is an excellent example of focusing on process and using software as an enabler of process, rather than building your business around someone else’s code.

4. Attention to Systems

When an organization looks to retire legacy systems, there needs to be a clear understanding of the interfaces and interactions that the new solution will need to maintain. Those connections include the links both internal to the organization and external.

5 Tools to Use

The amount and critical nature of the information gathered in this process is difficult to track using such tools as Word or Excel. A relational repository is needed for all enterprise architecture artifacts as well as for documenting and managing requirements and tracing them to business goals.

Next Steps

Transforming an organization’s core systems is not an easy undertaking, yet a considered, thoughtful approach can mitigate the risks and help an organization take a significant step toward achieving its long term vision.

Don’t forget to leave your comments below.

Progress over Perfection: Should you embrace the 80/20?

Written by Bob Prentiss on January 26, 2015. Posted in Articles.

Have you noticed lately that there are a lot of industry “buzz words” and “phrases” that seem to be driving your corporation’s strategy and your every day approach to work? “Agile”, “agility-minded”, “progress over perfection”, “fail faster”, “do more with less”, and “get stuff done” are a few of the common ones these days. These are all challenges that are being issued on a daily basis. You know what? I don’t disagree with those challenges. I think it is a natural decision for leaders to make as they strive to make the bottom line or find creative ways to increase profits, but is it doable?

How does one measure the merit of progress over perfection? The idea that something does not need to be perfect, it simply needs to be good enough? The Pareto principle, also known as the 80/20 rule, states that 80% of effects come from roughly 20% of the causes. 80% of sales come from your top 20% of your clients. Even Pareto’s pea pods in his garden showed that 20% of the pods contained 80% of the peas. One can look at this as you should not be working harder, you should be working less. Notice I did not say “smarter”? That is a given. Working less, is not, and will take some convincing on your part to get your leaders on board. What if you started employing the 80/20 rule and adding the concept of progress over perfection, and recognize that you don’t need to be 100% perfect to achieve superior results? For me, I became convinced when I recently did a stint of 36 hours in hospital isolation, along with 9 doctors, 6 RNs, 4 technicians, 2 floor monitors, 14 vials of blood, 16 needles, 6 doses of blood pressure medicine, 1 CT scan, 1 set of x-rays, $15,000.00 of medical care, and some morphine.

The following is a true story of how my hospital visit showed that progress over perfection, and the 80/20 rule, can be a very valuable practice indeed. On Sunday, November 29th, 2014, at 12:15 AM, we were packing for our 7 AM return trip home from a very relaxing and fun “avoid the relatives at Thanksgiving” weekend. If you have not had the opportunity to do this, I highly recommend it. Chicago has a lot to offer Thanksgiving weekend and a little less holiday dysfunction is sometimes just what the doctor ordered. However, at this time, I felt a rattle in my chest. My first thought was “Chest cold? Figures.” One minute later, when I started to cough up blood, (and not just a little mind you – 1-2 teaspoons per cough) I had a sinking suspicion that the night was not going to go well for me. Now, you would think that the obvious decision to go directly to the emergency room (without passing Go!) would have been an easy and smart decision. Instead, when it appeared that the bleeding had stopped, I rationalized that the incident was akin to a “nose-bleed” and the need to go to the ER had surely passed its time. Two hours later I had a similar but more defining attack, and yet I still did not go to the ER. Why? Because I can rationalize anything and I loathe hospitals (c’mon, I know I am not alone on this one)! Three hours later, when I was having a third, and much worse attack, watching my vision decrease to a pinpoint, recognizing that I was in fact, drowning in my own blood and was potentially going to die, I somehow made a large effort to relieve my lungs at the last second and somehow did not pass out. Third times the charm, to the ER I go.

Immediately upon entry to the emergency room, I was given a mask, ushered into an adjoining area away from people, asked a few pertinent questions about Ebola, Tuberculosis and how I felt, then within two minutes escorted into a temporary isolation room. First rule of thumb, don’t worry about perfection, remove the patient from 80 percent or more of the population. The needs of the many truly do outweigh the needs of the few.

I then met my first two doctors, who gave me morphine to calm and suppress my cough, and hopefully stem any bleeding that might be happening. My blood pressure was a calm, cool, and collected 221 over 117. Yes, it is a minor miracle I did not also have a stroke. Their goal? Rule out the most infectious diseases that are problematic right now; Ebola and Tuberculosis. Did they really need to ask me questions about Ebola? Well I do travel a lot. I had been to Victoria, British Columbia, but surely it was not the hotbed of Ebola everyone thought it was, so ruling out Ebola was pretty easy. That and I had no other symptoms. This is where their 80/20 rule and deductive reasoning got bogged down. I did not fit the stereotype. I did not have the symptoms they expected. They were not going to get perfection here so forge ahead they did.

I was moved to a more permanent isolation room with a negative airflow venting system – that does not allow the air from my room to get out to the rest of the hospital. There was a room to actually get into my room. Which can be disconcerting as you watch a hoard of doctors outside your door in their private room, clearly conjecturing about their “flavor of the month” patient. They all wanted a piece of me, it was quite clear, especially now that they did not have Ebola and Tuberculosis to throw around. Having said that, I must say, if you really have to be in the hospital, this is the way to go. The room is huge, extremely private with no roommates, and the negative airflow venting system was a lovely white noise to doze off to. There were some other perks too but bragging about a hospital room seems awkward at best. Doctors 3, 4, 5, and 6 enter into my room looking just short of a HAZMAT team out for an evening stroll. They start in with 20 questions, ordering lots of blood draws for testing. “Hey guys… I already lost a pint, take it easy okay?” Their goal? Rule out autoimmune diseases so no one can give anything to me and make my lungs worse. Doctor 6 insists the blood came from a cut in my throat. Really doctor 6? Really??? Well, this is progress over perfection.

Doctors 3 and 4 were joined by doctors 7, 8 and 9. Doctor 3 tells everyone that they can finally remove their masks. I am not contagious, and I have no autoimmune diseases so I won’t catch anything. For some reason they did not believe me and relied on the tests. The doctors remove their masks and look less HAZMAT ready. Doctor 9 tells me that in a certain number of people that have digestive problems, they develop blood vessels that can explode in their esophagus or stomach. In less than 1% of those individuals, they have blood vessels that explode in their lungs. Now I do not have digestive problems, but if the shoe fits Cinderella, it fits. It is progress after all. And it seems to be the only thing that makes sense given how high my blood pressure was. Their 80/20 goal? Stabilize the patient, get my blood pressure down and send me home. I am not in danger of bleeding anymore, or infecting anyone, so I can be seen by a specialist at home. The problem? The blood pressure would not go down. They can’t let me go. I am still their “flavor of the month”. It took 6 doses of blood pressure medication in a 24-hour period and three different approaches before they made a tiny dent in the blood pressure. It was not perfect, and they kept trying. Let me out!

The doctors were struggling with all of the things that we do on projects every day. Lack of definition of the problem, defining scope of the effort, getting buy-in from stakeholders, figuring out who makes the decision, who is accountable, even how detailed the requirements need to be. Everything they did in the hospital was 80/20. The 80% most harm came from the 20% most damaging, so they ruled it out. Each step of the way was to work less. That is why they had 9 doctors. Each one brought something to the table (even doctor 6). Rather than try for perfection with one doctor, or try for perfection to rule out all 100%, they exercised progress over perfection. If they had done all of the things in the hospital that they could have done, needed to do long-term, I would have been there a week and the bill would have been over $60,000. So do I believe in progress over perfection and the 80/20 rule? Yes I do. The doctors used deductive reasoning, went after the 80/20 that made sense, had a decision maker that was accountable but also okay with if it was not the right decision, and kept trying to get it right.

So how can you apply the Pareto principle and progress over perfection to your work today? Make a list, check it twice, and decide that most of it is naughty and not nice. Focus on the 20% of the work that will actually add value to your day. Working overtime on minimal-value adds is a waste of time. You will notice I said “minimal” and not “non”, I think you are smart enough to realize that you need to constantly look at your work and chuck out “non-value added” work. However, most of us still try to do the “minimal-value added” work too. Why? It is MINIMAL. What will it really get you? I have just completely reprioritized my life. I am changing my business model, and I am changing my life. Why not help out yourself and help out your company by not doing more, but by doing a lot less? By the by, I completely agree that there needs to be a change in how management looks at progress over perfection without punishing the people when/if it fails (but that is another topic for another day).

For those of you wondering how it all turned out… I was sent to a pulmonologist to have another CT scan and a bronchoscopy. The latter procedure is not pleasant. Tests were run, biopsy done, and tests came back with no cancer! In the end, exploding blood vessels in the lungs is the only answer I will ever get. I now take blood pressure meds every day; I have curtailed caffeine and alcohol and will be starting to work on that Paleo-like diet. I have been given a second chance and I am going to do a lot more looking at the Pareto principle, and striving for progress over perfection in the coming months. So do you have any stories of success where you have succeeded in with the 80/20 rule and progress over perfection?

Don’t forget to leave your comments below.

Why Do We Need Business Analysts?

Written by Jeffrey Davidson on January 19, 2015. Posted in Articles. 1 Comment on Why Do We Need Business Analysts?

It’s easier to defend Business Analysts than it used to be. Part of the reason is because I am defending the role in general. My job isn’t on the line any more. For other people this is a much more immediate concern. Still, it brings back memories. I hear the question at a conference or networking event and my heart shrinks. “Why do we need business analysts?” No matter how the topic comes up, it always makes me sad*.

I used to think other folks didn’t get it. The significance provided by analysts was obvious and self-evident to me. How could managers, executives, teams, and developers not understand all the value BAs add? Can’t they see BAs are the glue that holds these projects together? What would a project be without the contribution of a good business analyst?

Here are a couple important things a BA does on a project:

BAs break down the work in small chunks. This makes work easier to understand and confirm. It also makes developing and testing easier.
BAs document the scope and keep the project on track.

This is difficult stuff. Take a look at results from the Standish Group’s Chaos Report. I’ve put the success rates they measured for software projects into a graph below. We deliver projects on time, on budget, and as expected we only meet those goals about 1/3 of the time. Our success rate is terrible!

Compared to 20 years ago we have made huge strides. Project teams and tools are improving. Failures are trending lower. The project success rate has doubled over in 2 decades! Despite this headway, more than half of all software projects are failing or challenged. Why are there so many struggles? According to a recent Chaos Report, here are the related reasons for our problems. (Hint: You, my fellow BA, are part of the solution)

Failed Project Factors:

Incomplete Requirements – 13.1%
Lack of User Involvement – 12.4%
Lack of Resources – 10.6%
Unrealistic Expectations – 9.9%

Challenged Project Factors:

Lack of User Input – 12.8%
Incomplete Requirements & Specifications – 12.3%
Changing Requirements & Specifications – 11.8%

Do you see what I did there? I bolded some of the key reasons for breakdowns. They are the exact areas where a good business analyst is making an impact. For years I listed all the problems and said, “Look—this is why we need BAs. Analysts help solve all these problems! Our specialty is requirements, specifications, user input & involvement.”

—

I would draw on a whiteboard or give a presentation when I had more time. (See the graphic for a handy example!) I explained the result of few documented requirements was wasted work and missed opportunities. I said how we helped the business explain their needs today. I painted a picture of our goal, requirements maturity.

I would talk about the process of analysis. I spoke about understanding the big picture and little, tiny details. I ranted about tools, the details, and the conceptual steps in between them.

I could pontificate for hours about what we needed to do and how projects would benefit. If all projects had a BA, then we would answer the challenges of the Chaos Report with better documentation.

—

Sometimes I would add more items to the list above while sitting around with trusted colleagues. “Why else do we need business analysts?”

When a project manager is overwhelmed, then BAs are great providing support to the project team and sponsors.
When communication breaks down—and it does all the time(!), then BAs fill in the gaps.
When there is confusion about the scope, requirements, or testing, then BAs are ready with an explanation and helpful hand.

These three items are samples of the other services BA provide project teams. BAs are grease in the gears of the project, allowing it to move forward when it might stick or stall. Many people think project managers handle these responsibilities even when they are overloaded with budgets, schedules, and reports.

Ensuring everyone is working well together and has the same understanding is a great function to have on the team. These things are not a given or automatic response from putting individuals onto a project. These things are . . . squishy.

I know soft skills are the hard skills. I think good managers realize this, also. It is difficult for a Business Analyst to say “I keep things on track.” First, no one believes you. Second, this is not in your job description. Third, this stuff happens behind the scenes and under the radar; not everyone sees it. Spending time making sure teammates get along can lead to people wondering where you add value.

—

Unfortunately, I was answering the wrong question. Sure, the software industry needs better analysis. Yes, 50% of software built is rarely or never used(!). Yes, we had huge gaps between the original goals and delivered software.

So what? Who cares? While interesting to researchers and academics, the topic isn’t about the industry. It isn’t even about your company. It’s about you, the Business Analyst.

Which leads to the central question needing an answer. What do people want to know when they ask, “Why do we need Business Analysts?”

They are politely asking, “Have you been a key reason why this project succeed, or didn’t? Where did you add significant, game-changing value?” Or maybe, “What have you done to justify your salary?”

On the bright side, this set of questions means people expect something from you. They think you can make a difference. This is great news. You have a chance to shine, to excel! When you get this question, share what you have done and how made the project a success. Let them know about your contribution and how it made a difference.

On the other hand, if your team, or boss, or executive is asking this question, then you might be too late. It means people may be questioning what you do and if you can make a difference.

—

Through out the coming year, we will be exploring what it means to add value as a BA, from simple techniques for capturing elicited requirements to the squishier skills that make a difference. So stay tuned and come back.

In the interim, please do me a favor. Do it before you are again asked, “Why do we need Business Analysts?” Evaluate how you are making an impact. Come up with the answer that will let people know you understand their real concern and how projects are better with you involved. And while you’re at it, tell them what you need to make an even bigger impact?

* I see this frequently in environments with a traditional or waterfall SDLC. I do not see this in companies using Agile methodologies. We will talk about his in the coming year, also.

Don’t forget to leave your comments below.

CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

Written by Marcos Ferrer on January 5, 2015. Posted in Articles. 1 Comment on CBAP Was Always ‘UnPretty’ – Do You Have the Courage to Embrace Synthesis

“Certified Business Analysis Professional” (CBAP) always seemed a little awkward for a professional designation. Those of us who got it early actually worked directly with people to take the test (no on-line then). I had some low fun teasing the exam team (Cleve Pillifant and team, thank you again) about the acronym. It was low of me since the exam team was available and the decision makers were not (shout out to Kathleen Barrett, hope you are doing well). To those whose eyesight is fading, the “B” can even be mistaken for an “R”. This is no big deal and is common enough (case in point “PMP”).

Now things change, because it is increasingly obvious that ANALYSIS (breaking into parts) is only half the battle (the easy half). The harder “half” is business SYNTHESIS. * Synthesis means taking the parts stated by stakeholders (requirements [stated]) and organizing them into possibilities by reducing confusions and artificial constraints (“but we built what they told us to build…whimper, snivel”).

Modeling IS simplifying. Simplifying requires doing something MORE, NOT LESS. Some of you will understand the statement “If you want it shorter it will cost more.” We know this is true because stakeholders are very reluctant to “simplify” the information they can offer. We also see this is true because we must reconcile wants across silos – often very committed silos.

Simplifying includes breaking concepts down (user friendly means more than a smiley face on screen) with analysis. It works by re-assembling concepts into understandable high quality summaries (models) with synthesis. More than ONE synthesis will be needed. One is for people who will read and follow the complexity. One is for people who won’t be able to pretend they are following unless the words are put into polygon shapes. “I’m visual” is the refrain, but more than four or five polygon shapes quickly reveal that the shapes have “words” anyway, and confusion reigns among the “visual”.

For productivity the experienced analyst understands that working in text can be faster than working in diagrams (at least for analysts that like working in text). An ideal situation is one where a technical writer engages the stakeholders in diagramming simple text while the analyst produces complex text.

Many diagrams are just fancy vague lists. Perfect examples are Visio and PowerPoint “flat” diagrams). As a productivity technique, drawings are easily outpaced by anyone who can create or follow an indented outline.

Here is a sample text “analysis” using the puzzle from the last blog (Everything We Needed to Know We Learned on Sesame Street):

Business Requirements
1. Business Goals / Objectives
  1. We want to increase sales
  2. We want happy customers
  3. We want to get rid of old technology because…
  4. More?
2. Business Needs
3. Capability Gaps
4. Solution Approaches
  1. We want to buy this in ONE software package
  2. We want to outsource all software configuration and maintenance
5. Solution Scope
6. Business Case (what matters, how it matters and why it matters)
Requirements [STATED]
1. Every want is stated only, not modeled, verified or validated.
2. All are vague – unspecific – need improvement
Requirements [ANALYZED / MODELED]
1. No want has been analyzed / modeled
2. Even business objectives are unclear –
Business Analysis Plan
Solution Requirements
1. Functional
  1. We want users to have the freedom to override business rules
  2. We want the system to pick the best approach
  3. We want to capture name and address and contact info everywhere
  4. We don’t want managers interfering with our work (micro-management)
  5. We want to reduce data entry errors
  6. We want direct access to the database
  7. We want users to write their own reports and not wait for IT
  8. We want easier, better scheduling with fewer disruptions
  9. We want large monitors, aluminum cases and wireless keyboards on our PCs
2. Non-Functional / Qualities
  1. We want easy to use
  2. We want a consistent high quality customer experience
  3. We want reliability, maintainability, scalability and no irritability
  4. We will know it when we see it but no sooner
Transition Requirements
1. We must have everything built before release
2. We don’t want to change the work or conditions

We may not agree on whether the above is “correct”. I think we CAN agree that it is not useful, complete or free of conflict. There are unspoken relationships (e.g., relation of “solution requirements” to goals / objectives). There are potential conflicts right next to each other. One example is when stakeholders want direct access to the database vs. fewer data errors.

What can fix this? SYNTHESIS! Are you a business analyst only, or a business synthesist* as well? Creativity isn’t just gums bumping – talk is cheap, watcha got that a project team could follow, that could make sense to those who cannot code ambiguity, confusion or wishful thinking? Most importantly – which statements deserve more focus, and which less? Which statements represent the highest requirements risks? What is missing for effective objectives? What would your process model begin to suggest?

Can any of my readers write a single paragraph describing a workable approach? Can anyone resolve the apparent conflicts by addressing high-level business issues? What do the stakeholders mean and can it be built to the joy of all? Hint: Start by synthesizing “bottom feeding” requirements into “top priority” business needs related to goals and objectives.

And remember – you can’t skip any steps in BA world for true enterprise systems. Pay it now or fail it later. Think of all the BA work (yes, its hard, that’s why stakeholders don’t do it) as leading to a quality groomed backlog. Good process, followed by good interface design followed by quality development is unbeatable.

When we “do what stakeholders want” we are not serving their goals. Not unless they happen to be information systems experts. You might as well try to build a skyscraper for a toddler – “I want the 50th floor to be ALL ice cream” they scream.

Remember to say yes, and to place ice cream fountains everywhere on 50. Make it the centerpiece of the project, so no one will forget which stakeholders insisted. Allow all the stakeholders to pick flavors for prioritization. Above all synthesize the other 99 floors with FAST elevators to 50.

Mo’ later, thanks for reading, don’t get lost in the trees OR the forest.

* Do I have to spell it out for you 🙂 ?

Don’t forget to leave your comments below.