Skip to main content

Tag: Business Analysis

Is Your Business Analysis Process Like Buying a Car?

Kupe_Blog_Dec_7This past weekend my wife and I bought a new car.  I was replacing my 14 year old Ford Explorer and had 3 cars in my sights. I went to 3 dealerships to test drive those cars.  What a nightmare!  I thought the car buying experience was going to be better than 14 years ago.  I actually think the process is worse.

With all the online tools available and my network of friends I did all the research.  I knew which cars I liked, what the dealers pay for the cars and what people in my area have been paying for them.  The first step I took was to submit my information on the dealership’s website, get a price quote and set up an appointment to test drive the car.  For each dealership I received an automated email stating I was a preferred customer and when I arrived at the dealership I would speak directly to a manager. The manager would work with me to test drive the car and settle on a price.  I was lead to believe I could expect to be in the dealership for 30 minutes to an hour.  With my preferred customer number the dealership had all my information.  What a great way to buy a car, right! Absolutely…if it actually went down like that. 

When I arrived at the dealership, I was quickly moved to work with a salesperson who started to ask me what car I was interested in. He broke out a form and began asking me for my name, phone, address, email etc.  I am a calm and patient person, but this set me off. This person knew nothing about me and it would take 30 minutes to explain what I already shared with the dealership online.  I left the dealership letting them know I was not planning on buying a car from them.  Could you believe 3 days later I received an email from the internet dept. of that dealership asking me if I was still interested in a car. Aah!!!! I was reminded why I don’t buy cars often.

Is your business analysis process like buying a car? I hope it is not close.  Your process needs to be customer focused.  I spoke with someone a few weeks ago and her organization was still in a “throw it over the fence” mode.  That fence was so high and thick that she never received a question from the developer and was not even sure what the implemented solution looked like until it was in production.  When she told me, the look on my face had to be saying, “Are you kidding me?”  I assume her business stakeholders felt like me when buying a car.  They shared information with the BA and then when the developer had questions they were probably asked the same types of questions..

At another company they did not throw it over the fence, but they still used a poor version of waterfall. The developers and QA team were not brought in at the beginning of the project.  The BA would review requirements with the tech lead and QA lead that would then estimate the build and test portion of the project.  If the high level estimate was approved developers and QA analysts were assigned.  You think they had questions? Even if the questions were not asked directly to the business stakeholder, their time and money was being spent on a lot of knowledge transfer.  

This extra time and some unnecessary back and forth with your business stakeholders does not help promote the value of Business Analysis.  As the BA you need to raise your hand and demand some change if your project lifecycle is not customer focused.  Your role is to help implement solutions to improve the business area you support.  Always make sure your process is geared towards that goal. 

 Always be easy to deal with,

Kupe

Business Analysis Love Fest at BBC

Kupe_Oct25I just returned home from the Building Business Capability conference in Alexandria, Virginia.  It was a co-located conference with the IIBA, the business rules community, and the business process community. A common belief among attendees was that the combination of these three communities was a marriage made in heaven.  At the end of the conference Ron Ross stated, in so many words, that we have to stop focusing on gurus of software development and start focusing on building business capability.  As you can imagine, all three camps are big believers in understanding what an organization needs to achieve its strategic goals. Software may enable that, but it is not always the main driver. I had the feeling we were at a Barak Obama campaign speech and the entire crowd was going to scream back, “Yes we can”.

There were three main points in time at the conference where I felt we were at a political rally.  The first was at a presentation given by Barbara Carkenord and Elizabeth Larson.  They spoke about a paper written in conjunction with the IIBA and PMI to highlight the overlap of the PMBOK and the BABOK.  The tone of the presentation was to show how the PM and BA can work together, not against each other.  The 100 plus in the crowd were ready to march behind Barbara and Elizabeth.  I could sense that almost everyone wanted to shout “Amen” at one point.

Next was a presentation on Enterprise Business Analysis given by Jason Questor.  He introduced us to the work being done by the IIBA on the subject.  Most of the attendees there were in alignment that our business analysis skills allow us opportunities in the strategy arena within organizations. These skills give us the ability to go beyond project work. Jason told a story about Kathleen Barret, president and CEO of the IIBA, letting an audience know that she believes business analysts will grow up to be CEOs. Talk about a rallying cry!

The third was at the closing panel, where a number of the audience felt the three communities should band together.  The IIBA viewed as the broader picture with specialties in business process and business rules.  Many attendees were thrilled to have learned more about each community and couldn’t wait until next year’s conference. I could tell many did not want to leave and go back to reality.

I was among those that thought how great it was to all come together, and I think a similar conference should happen next year and beyond.  We need time to come together and learn from each other. Now that we have all hugged and said our goodbyes the real work begins.  It was easy for all us who believe in business analysis, business rules, and business process to agree. 

But, why are there still so many individuals and companies not focusing on these areas?  If we want to make large wholesale changes in our organizations, each of us needs to perform better every day.  We need to continue to show our value to make the changes we all believe in.  Many of us at the conference walked away with ideas on how to improve and make that change. Mark Jenkins, KPMG, said you don’t always have to ask for permission, just do something…anything.  Gladys Lam, Business Rules Solutions, said “just do it”. She wanted to make sure we went out and tried some of the things learned at the conference.  She pushed us to not worry about being wrong and that we will improve iteratively.

What are you going to do?  Don’t stick with the status quo. I am hoping a year from now there are more stories of how our community has helped built better business capabilities.

Please use this as a forum to discuss stories of how you are showing your value.  We can all learn from each other.

Kupe

Don’t forget to leave your comments below

Terms, Terms, Terms. Clarifying Some Business Analysis and Project Management Terms

In order to clarify some basic concepts of business analysis and project management, we need to distinguish between terms that seem similar but are not. Below are some foundational terms and distinctions.

1. Project Management focuses on the work and methods to create new products. The Guide to the Project Management Body of Knowledge (PMBOK® Guide – Fourth Edition) defines project management as “the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”[1]

2. Process Management concentrates on the workflow and systems that recreate the products that sustain an organization.

3. Products. Throughout this article, we’ll refer to the end result of the project as the product. It can be a product, service, or any key deliverable that is produced as a result of the project. A few examples of products include a new bridge, a new methodology, landscaping, a project management office, a new car, a feasibility study, an HOV lane added to a freeway, a recommendation, a new or changed process, a new banking service, a new website, creation of a new agency, and a new marketing campaign.

4. Product Management uses processes and knowledge to manage product development, support, and marketing of the product. In this article, we cover the part of product management that occurs prior to deploying, selling, and supporting the end product. We focus on the work needed to define the requirements of the end product, to ensure that those requirements are built into the product and tested, and to ensure that the end product meets those requirements. Product managers exist in some organizations as the driving force behind new product development. They often define the high-level product requirements. In such organizations, this product manager often fills the role of project sponsor. See Table 1.1 for a summary.


Characteristic Projects Product
Requirements
Processes
Ownership Sponsor Sponsor Sponsor
Keeper or
custodian
Project manager Business analyst Business process analyst
Planning Project management plan Requirements management plan Documented processes
Execution Performing project
execution
Performing BA activities Performing the process steps
Closeout Project close and lessons learned Closeout of phase(s) & lessons learned Improved processes
Aligns with organizational vision and strategy? Must Must Must




Project, Process, and Product Requirement Characteristics

Projects are initiated in a variety of different ways, such as new government regulations, competitive market forces, and requests to enhance existing products. In other words, someone in the organization requests a new or changed product.

The person who initiates the request is called the sponsor. We’ll explain the full sponsor role later, but for now let’s think of the sponsor as the person who obtains the funds for the project and makes key business decisions.

Once the request has been approved, a project manager can be assigned to manage the project. Projects result in changed processes for an individual or group of individuals large or small. For example, a new bridge results in new traffic patterns and new processes for those taking the bridge. Landscaping requires processes to maintain it; the HOV lane requires new laws and new processes for use by drivers. A new computer system results in new processes for the end-user. Therefore, stakeholders affected by projects, processes, and products all need to be identified and kept informed of the project status. Figure 1 below shows the interrelationship of projects, processes, and products.
12-10-2010_9-44-10_AM

Figure 1: Projects, Processes and Product Requirements Interaction

Life Cycles, Phases, and Methodologies

Project Life Cycle. A project life cycle takes the project from its inception to its conclusion. In other words, each project is alive. It is conceived, born, it matures, and finally ends. Products have their own life cycles. Typically, product life cycles last longer than project life cycles, because in general the product outlasts the project. However, in the example of a lengthy feasibility study whose product is a recommendation, the life cycle of the project can last longer than the end product. Project life cycles are composed of one or more project phases.

Project Phase. The project phase,as described above, usually marks a milestone, at which point a deliverable is usually produced, reviewed, and approved. The business analysis phase(s), then, produces a set of requirements (features and functions) that must be reviewed and approved.

The names of the project phases do not have to be the same for each project. One organization may have projects in different divisions or business units or agencies, all of whom can have different phase names. Nor are there a set number of phases required for each project. For example, the number of business analysis phases for a software development project can vary, depending on the approach taken to business analysis and the phase-to-phase relationship used. The business analysis effort can occur during one project phase or over the course of many project phases. For example, iterative development of software projects occurs over several project phases, as could the piloting of new business processes. For a complete discussion of lifecycles and phases, please refer to the PMBOK® Guide – Fourth Edition, section 2.1.2.

Methodology. This prescribes how to get through the project life cycle, including the business analysis phase(s). It usually includes processes, procedures, forms, and templates for completing the project or project phase. Each project phase could, but does not have to, follow the same methodology. There are methodologies for completing business analysis, project management, product development, and testing to name a few.

Iterations, Increments, and Releases

These terms have created a great deal of confusion over the last several years. In the blog Don’t Know What I Want But I Know How to Get It, Jeff Patton uses art, movies, and pop music to explain the difference between “iterating and incrementing.”[2]

In a PowerPoint presentation, Managing Increments and Iterations with “V-W” Staging, Alistair Cockburn distinguishes iterations and increments by referring to increments as “build, deliver, learn, build, deliver, learn,” and iterations as “build, examine, learn, rebuild, ship.”[3] For another short differentiation, see Kevlin Henney’s article from December, 2007.[4]

Incremental development implies that new features and functions are added with each increment. For example, software can be developed using a plan-driven approach, with increments or new functionality added incrementally. Incremental business analysis implies that requirements are defined for an increment, and new requirements are added for each increment. Again, releasing in increments is appropriate for both plan-driven and change-driven approaches.

Iterative development implies planned rework. We expect the product requirements to evolve and change, so that change is viewed as part of the development process, not as a defect. Each iteration evaluates what has been built, and the product is rebuilt as needed. Iteration implies planned rework, because not only do we expect requirements to evolve, but there is a process to handle changes iteratively. Change-driven business analysis combines incremental and iterative requirements definition.

Product and Solution

Although the industry sometimes treats these two terms synonymously, we will use the term “product” for the end result of the project, and the term “solution” to mean the implementation of the requirements. The solution is a term used to describe a set of key deliverables that when taken together solve the business problem for which the project is undertaken.

Here are some examples.

  • The productof a project is a new marketing campaign. One solutionmight be to hire a consulting firm to produce the campaign. Another solutionmight be to have the advertising department develop it.
  • The productof a project is a new piece of software. One solutionmight be to build the software. Another solutionmight be to buy it from a vendor. Yet another solutionincludes new software, new hardware, and new processes.
  • The product of a project is a new order replenishment system. One solution might be the software, hardware, new and changed processes, and a recommendation on whether or not the organization is ready for the change. The requirements describe the features, functions, and capability of the new system. The deliverables (work products) from business analysis include a business requirements document, a recommendation on new hardware, a model of the future processes, and a recommendation on a new organizational structure for the affected business units. The order replenishment system alone will not solve the business problem, so the solution has to include more than just the system. This solution may involve many projects, each of which will have products.

Summary

Making distinctions in terminology is important for both planning and execution of projects, and common language can help reduce misunderstanding and miscommunication. When everyone understands the underlying concepts of business analysis and project management and uses the same terminology, they can complete the work more productively and with less conflict.

Don’t forget to leave your comments below


Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (http://www.watermarklearning.com/), a globally recognized business analysis and project management training company. For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (C BAP ) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK).


Management Institute. A Guide to the Project Management Body of Knowledge, Fourth Edition (PMB[1] Project OK® Guide). Newton Square, Pennsylvania: Project Management Institute, 2008. p. 435.

Patton, Jeff. “Don’t know what I want, but I know how to get it.” Agile Product Design. 21 Jan. 2008. <http://www.agileproductdesign.com/blog/dont_know_what_i_want.html>.

Cockburn, Alistair, “Managing Increments and Iterations with ‘V-W’ Staging.” <http://alistair.cockburn.us/>.

Henney, Kevin. “Iterative and Incremental Development Explained.” Search Software Quality. 3 Dec. 2007. 29 Jan. 2009 <http://searchsoftwarequality.techtarget./news/article/0,289142,sid92_%20gci1284193,00.html>.

Business Analysis May Be the Problem

Kupe_Sept14I recently ran across this quote from Marilyn Kennedy a leadership coach, “It’s better to be boldly decisive and risk being wrong than to agonize at length and be right too late.”

Taking a look at her site it appears she is not speaking directly to business analysts, but I can tell you this quote should speak to you as a business analyst. When I read the quote the first thing that popped in my head was “analysis paralysis”.

Often BAs struggle with determining when enough is enough.  Even with the great work many of us are doing to help improve project success and business improvements, the need for the right level of business analysis can be a tough sell. In our field, I believe the “Great Perception” is still alive…we don’t need analysis, we need development.  The quote got me thinking of a reason why this perception exists.  

The problem partly stems from our name.  We are business analysts and we perform business analysis.  Is that the best name to describe what we do?  My BA colleagues everywhere and friends at the IIBA® are probably rolling their eyes…please hear me out. In my opinion the word analysis is kind of fluffy.  A Merriam-Webster definition of analysis is, “an examination of a complex, its elements, and their relations”. I see why discussions continue about not needing business analysis.  Uninformed about the value of business analysis, managers and executives don’t want an examination of their problem or opportunity.  They want solutions.  The definition of develop according to Merriam-Webster is “to create or produce especially by deliberate effort over time”. That’s what I want.  That’s why development is a must. It sounds more concrete. Analysis alone is not concrete.

I suggest we describe ourselves as Business Advisors.  An advisor is someone that recommends, gives advice, and informs. My comparison is a financial advisor vs. a financial analyst. For my retirement fund I don’t want a financial analyst…someone that analyzes the market and trends.  I want a financial advisor.  I want someone who will analyze my current portfolio (AS IS), work with me to define how much I need to retire (TO BE), and then recommend options to fill the gap.  Doesn’t that sound like what we do?

Barring a major change like the IIBA® renaming itself to the international institute of business advisors, what can you do to change the perception? When working with team members and business partners that may not know the value of business analysis, you need make it clear that you are in the advisor or solution business. The best way to recommend solutions is to do the right level of analysis first.  This way they know why you are asking the probing questions.

In addition, this is a big reason I advocate for business analysts developing a business analysis work plan.  If you lay out what, why, when and how you will be taking on the analysis effort for a project, you now have a negotiation tool with real data to negotiate the necessary time and stakeholder involvement. Your work plan should include a:

  • stakeholder communication plan
  • list of deliverables
  • detailed task list
  • time and cost estimates for you and other stakeholders

By discussing your plan with your manager, project manager and business partners you can discuss how these activities will help develop recommended solutions that address the problem or opportunity the business is facing.

What do you think?  Are you an advisor?   

Happy Advising,
Kupe

Don’t forget to leave your comments below

The Business Case for Business Analysis

Apologies to any economists – the real value of BA is probably way higher than I could determine in 1000 words. There is probably a multiplier just from workers watching crazy process insanity disappear from their daily lives.

To see the big picture sometimes we drill down.  I give a specific example (completely fictional of course – this is not you, so don’t call please).  In this project BA 007 was asked to help introduce BA practices into a water utility’s IT project practices.

The usual “fire hose” of information was sprayed on 007 for the first weeks.  As 007’s intelligence base grew, one of his early questions was “How much money is currently spent on IT projects and infrastructure per year?”   The response was:  “Oh, we have that, it’s around $3,000,000.00”.  No documentation available, but, what the heck, eh?

So 007 continued to analyze the information he was getting, patient and secure that his question had been, or would be, answered.  As an initial business case for implementing BA for IT projects began to emerge, it became apparent that the out of pocket costs looked something like the following:

  • 12 SMEs on staff acting as BAs
  • 8 person team doing requirements for ERP enterprise project
  • 100 stakeholders engaged part time at any given time (about 10 full time equivalents)
  • 70 Contract IT personnel
  • Average IT Infrastructure investment of $3,000,000/year

Total 100 personnel out of 2700 employees @ $75K/year on average = $7,500,000/year

At this point, 007 starts to suspect that the $3,000,000 only covered total annual infrastructure costs (hardware, software, support and maintenance), and that the client was not counting payroll or overhead costs for projects (not unusual in a government environment).  Given the 35% failure rate across all water utility IT projects (we ignore those that were merely “compromised”), the “lost money” to failed projects seemed more like $2,625,000 per year, or $26,250,000 over 10 years.

The costs of BA (requirements) failure above are incomplete and incorrect – they do not include overhead like office space, supplies, PCs, office equipment and other resources wasted on failed projects (promotion of the guilty, punishment of the expert, rock bottom morale, employee turnover and more).

The cost of retraining personnel for improving the BA function at the water utility was calculated to be 20 BAs plus 20 IT personnel, Each receiving 8 weeks of training in year one, 4 weeks in year two, and two weeks per year in subsequent years.  Classes were estimated at $3500/week including travel, and salaries/benefits at $75K per year on average. 

It was also estimated that increased/improved BA activity would require twice as much involvement from stakeholders – 20 full time equivalents instead of 10. 

These costs to invest in BA came to about (40*(8+4+2+2+2+2+2+2+2+2) person weeks * ((75,000/52) +3,500) per person week)
= $5,536,385

PLUS 10 more full time equivalents @ $75K * 10 years
= $  7,500,000

TOTALING:
$ 13,036,385 

OK, those of you who do real business cases know just how flawed this is, but, as 007 likes to say, $26M – $13M gives a LOT of room for refinement.  Go ahead, add inflation to personnel costs, add in lost benefits to the “merely wasted” money, add any complexity you want – 007 defies you to show that BA investment can ever lead to a negative ROI.

Have fun, and I’d love to get your feedback! 

Don’t forget to leave your comments below