Skip to main content

Free, Easy and Powerful Tool – the CBAP 007 Scope-O-Matic!

Written by Marcos Ferrer on . Posted in Articles.

Just in case any of my readers think I (yes, I am CBAP 007) am only good for political analysis, I offer a simple BA “tech” goodie (our tech is different from their tech – this one works with paper and pencil, in a pinch!).

If you have ever been in a project where scope keeps wandering, even after endless discussions, just use the 007 Scope-O-Matic to sort it out in your mind. Once this is done, it will be easier to sort it out with the stakeholders.

Don’t write me telling me that this is the project manager’s responsibility – the project manager doesn’t face confused stakeholders day after day. Sometimes the PM acts like another stakeholder, announcing scope as if no one else could understand or discuss it. Often it is not in fact understandable, usually because it is oversimplified, and discussion is not welcome.

The secret is in not oversimplifying the scope (“To do requirements for a new order entry system” is not clear at all) and putting good boundaries on the problem. It is not enough to say what is in scope – often what is in scope “implies” other issues, not made explicit, yet leading to multiple confusing meetings.

Now, with Scope-O-Matic, you can identify more detail in your scope, and you can identify what is out of scope, and what is ambiguous in scope, as well as what is in scope.

If you have never tried this, you are in for a treat. Even if those around you never do sort out the “true” scope, you will have a lens into the confusion, one that will help you keep your head, while all around are losing theirs.

Have fun, let me know what happens. Even five minutes with this tool will teach you things that you know but hadn’t articulated – it is a great “gap” analyzer – do it for your project today!

Keep the discussion coming, here is your free tool!

IN and OUT of SCOPE, with “Possible Ambiguities”

IN SCOPE ??? OUT of SCOPE
Build a Prototype system Creation of a Prototyping Demo Environment? Creating an application environment.
Creation of a Prototype covering Order Taking, Picking and Shipping Electronic orders or just phone orders? Faxes? None of the marketing that leads to a customer making an order
Elicitation of user interface and functional requirements using prototype Capture or dispose of business rules discovered during elicitation? Elicitation of software, security, reliability or any other non-functional requirements
Documentation of functional Requirements and user access privileges Are user access privileges a part of security requirements? User or programming guides, response time requirements, system uptime, system scalability, etc.
Screen shots (in documentation) The screens have over 15,762 permutations, if you count menu views – how many screen shots? Functioning code of any kind
Process (functional) requirements (use case model & text) Level of detail? Traditional FRD non-documentation
Assumptions made by requirements team How to bridge critical “unspeakable” assumptions? Assumptions that are “unspeakable” yet critical
THE REST IS UP TO YOU

Have fun!

Don’t forget to leave your comments below

Marcos Ferrer, CBAP has over 20 years experience in the practice of business analysis and the application of Information Technology for process improvement. Following graduation in 1983 from the University of Chicago, Mr. Ferrer joined IBM in Chicago, where he worked on requirements and systems implementations in diverse industries. His recent projects include working requirements for the Veteran’s Administration, introducing BA practices at the Washington Suburban Sanitary Commission, and creating bowling industry models for NRG Bowl LLC. In November 2006, Marcos Ferrer is one of the first CBAPs certified by the IIBA. He has served as an elected member of the DC-Metro chapter of the IIBA, most recently as President, and assisted in the writing of the BOK 2.0 test.

© Copyright 2010 Marcos Ferrer

Will the Real BA Foundational Skills Please Stand-up

Written by Kupe Kupersmith on . Posted in Articles. 1 Comment on Will the Real BA Foundational Skills Please Stand-up

An interesting discussion was started on a LinkedIn group a few weeks ago posing the question, “What would you think is the single factor that determines project success?” This sparked a healthy debate and made me think on a more micro level for business analysis. I asked myself what are the foundational skills needed by a business analysis professional? It did not take me long to answer my own question. Let’s see if you agree.

Let me start with what I think they are not. In our profession it has been discussed that at a minimum, BAs had to know the accepted techniques used in the role. Examples include use cases, workflow diagrams, context level data flow diagrams, etc. These are critical pieces to making an excellent BA, but not the foundation. They are interchangeable and new ones can pop up at any time. Did people not analyze before use cases became a standard format for analyzing and documenting requirements? Sure they did. These techniques are not a constant.

Analogy time! Let’s consider a house. The foundation is solid (hopefully). It supports the living space of the home. The living space is filled with appliances, furniture, art, rooms with doors, closets, windows, etc. Depending on what you are doing in your home at any time, you use some rooms, some furniture, and maybe an appliance. At the same time rooms, furniture, and appliances are not being used. Then there is the bread maker you were given for a house warming gift. That baby only comes out during special occasions. The rooms, furniture, and appliances are the equivalent to the techniques I mentioned earlier. The techniques are used when necessary. Every project does not require the use of every technique you have available. So then, what are the real foundational skills you need?

When I think of a foundation, I think of something that is constant, always there. Your foundation needs to be built with trust, analytical and problem solving skills, mixed with ethics, personal organization, business knowledge, and communication and interaction skills. These are often referred to as soft-skills, but these are nothing close to being soft. This is your foundation. From here everything is possible.

In the IIBA BABOK these skills are called underlying competencies. The writers of the BABOK define these as “the skills, knowledge, and personal characteristics that support the effective performance of business analysis.” The writers got it right by using the words “underlying” and “support”. Without these skills BAs cannot perform at their peak, just like a beautiful front door that won’t open or close properly because of a settling foundation.

Knowing the technical aspects of the techniques available to you is not enough. Even if you know the when to use an Activity diagram and all the symbol definitions, it is useless if your foundation is not secure. What good is that technique if you don’t have the interaction skills to elicit the requirements, or the communication skills to ensure you understood the requirements, and the ability to ensure the solution team clearly understands the need.

Take a few minutes and inspect your foundation. Is it secure?

Foundationly yours,

Kupe

Don’t forget to leave your comments below

Jonathan “Kupe” Kupersmith is Director of Client Solutions, B2T Training and has over 12 years of business analysis experience. He has served as the lead Business Analyst and Project Manager on projects in various industries. He serves as a mentor for business analysis professionals and is a Certified Business Analysis Professional (CBAP) through the IIBA and is BA Certified through B2T Training. Kupe is a connector and has a goal in life to meet everyone! Contact Kupe at [email protected].

What Every Executive Needs to Know About Hiring Business Analysts

Written by Keith Ellis on . Posted in Articles. 1 Comment on What Every Executive Needs to Know About Hiring Business Analysts

The ability to hire great people is one of those skills that differentiate hugely productive managers from the mediocre. When dealing with a specific project, it gets even tougher with the number of distractions, time sensitivities and need to fill head-count numbers on a project plan. It’s very easy to get sucked into short term thinking, and sometimes HR management practices get short-sighted as well. No, the probationary period of a new hire is not a generic safety net.

Here’s some fast thinking you can do in under 30 minutes to help you hire better:

Get away from hiring generalists

Rather than trying to hire people that are generally great at all things, focus on the areas of greatest value to the organization. Take a few minutes to jot down the services this person is going to offer the organization. Figure out where in the project cycle and which requirements definition and management processes will really impact your organization’s performance. Be brutal in your focus to get it down to one or two areas where this person needs to shine.

By getting ‘service focused’ (verb/noun pairs like ‘Facilitate Requirements Meetings’) you’re being blunt about the competency that is essential for success on the project.

List the Skills Needed

Most companies have defined templates used in their requirements definition and management approach. How many hiring managers look at that document and simply extract use cases, cross-functional swim lane diagram, etc from the template to get a list of techniques the analyst would need to know to be successful. How many people look at the services and say, what techniques would need to be known here to be successful? If you’re looking for requirements definition capability and “Facilitate Requirements Meetings” then you probably want someone who knows the techniques for facilitating a cross functional team.

Want a good technique for listing soft skills? Just list the things that annoy you as a manager.

Test Required Skills

I’m a huge believer in testing skills, before the interview and after the interview. It reduces your reliance on your first impression. It is way too easy to get caught up in thinking the first 30 seconds is the make/break part of hiring. I always end up reminding myself, I’m not hiring a politician. Put more weight on getting the person to do a pre-interview task, get them to do a post interview task and look at the judgment, work quality, and skills used in doing those tasks. Give a documentation focused person a requirements document and say, is it done? Have a facilitator run a simulated facilitation session. Nothing elaborate, just focused on the skills that are essential to success. You could even look to outside organizations that do skills testing (Inquestra, etc) if you’re not feeling particularly creative or need to hire dozens of people and don’t have time to administer the tests.

Get Away from Trying to Hire Industry Experts; Focus on Analyst Skill

Here’s a basic rule of thumb: your line of business managers are the subject experts that know the business. Analysts, need to know analysis. If the analysts are competent, they will function really well, regardless of the industry or position. Granted, if you want a systems analyst for SAP, you need to focus here a little more, but definitely not for business analysts. Let’s face it, the pool of candidates can get really small, really quickly. And chances are, if someone is emphasizing being an industry expert, I’ll bet they are not overly strong in pure analyst skills.

Be Happier

There is nothing worse than dealing with a bad hire. Well… I hate it! Not just the HR stuff, but also what it does to your good performers and the overall project. If your company doesn’t already have great role descriptions in place, try some of these techniques. Having a great team is just a happier place to be.

A Few Thoughts for Those of You Looking for a Job

Lots of folks are out looking for positions today. Here are a few thoughts on positioning yourself for something else:

  • Consider positioning yourself as a specialist. You do a few things really, really well.
  • Try putting more active tense “services” you provided to the organization in your resume. Hiring managers (and google) scan for keywords.
  • List proof of your skills as your accomplishments. (How about: ‘Lead analyst principally responsible for facilitating requirements meetings on over 50 projects’)
  • Make your expertise as an expert analyst come out

Trying these ideas means deliberately writing a resume that does not fit every opportunity for a contract BA. The idea is to position yourself for certain types of opportunities, and to be successful in landing a spot when one of those types appears. As an interesting side benefit, employers tend to pay more for someone they perceive to be a specialist than they would someone they see as a generalist.

I wish you all great success.

Don’t forget to leave your comments below

Keith Ellis is the Vice President, Marketing at IAG Consulting (www.iag.biz) where he leads the marketing and strategic alliances efforts of this global leader in business requirements discovery and management. Keith is a veteran of the technology services business and founder of the business analysis company Digital Mosaic which was sold to IAG in 2007. Keith’s former lives have included leading the consulting and services research efforts of the technology trend watcher International Data Corporation in Canada, and the marketing strategy of the global outsourcer CGI in the financial services sector. Keith is the author of IAG’s Business Analysis Benchmark – the definitive source of data on the impact of business requirements on technology projects.

The Importance of Collaboration with Business Experts

Written by Ross Wilson on . Posted in Articles.

importance1As business analysts we have a wealth of knowledge, information and experience to tap into. There are many different books on eliciting, documenting and managing requirements for a business wanting a new capability or a new product or system. There are numerous web sites that have articles and information for business analysts, plus many blogs discussing ideas and issues facing business analysts. There are many different techniques to use and methodologies to follow. And for projects where there are hundreds of requirements from many different stake holders we have Excel spreadsheets, and requirements management tools to assist with controlling and managing the requirements. So with all this to help us why do things still go wrong?

I was thinking about this the other day while riding my mountain bike through the forest. I enjoy mountain biking and I have an average bike capable of doing what I need of it. My requirements were simple when I started and have not changed much, I needed something that would go off road in a local forest area which had purpose built tracks and I was not into jumping so something basic but strong would do. I went to a local bike shop that had a range of bikes and I was then asked a lot of technical questions about the type of riding, brakes and suspension needs I had. Mountain biking is a very technical sport and although the bikes don’t look that different they range in price and specification greatly. As the store assistant was the expert I asked for his advice and then made my decision based on price and features. As usual I ended up spending a little more than I had intended.

So what has that got to do with business analysis? Well, in the bike shop the assistant was seeking requirements and was also the expert. He knew the products and could advise based on his expertise and experience. He knew the questions to ask and explained the terminology to me as he described the different bikes’ specifications. So, as business analysts we know how to elicit (ask the right questions), document (write the requirements down clearly and concisely) and manage requirements (store them and apply other attributes to them). But we are not always experts in the industry, or area of business, or product we are dealing with. So we rely on experts from the business, not only for requirements, but also for information and advice. If we have incomplete or incorrect requirements, do we as business analysts really know that this is the case, if we are not the experts in that area? And do the experts from the business really understand what the requirements are meant to convey and really understand how important they are?

In many instances we gather requirements and then get the business to review and sign off on them. But this is often after only a single pass over the requirements and may not be to an adequate level of detail. It is important that we involve business people in a more collaborative approach and expand and dig deeper into the requirements as we get closer to developing them. Having a key subject matter expert from the business working closely with the business analyst to help detail the requirements can stop issues with terminology and terms, and make the requirements more easily understood by the business. I have worked in a few different industries and have found each one has its own language full of acronyms and technical terms. It is important that this language is used in the requirements. Even if we know the subject area well, it can still be good to involve someone from the business to work with in detailing the requirements. After all they are the users not you, and the user experience and interaction with applications is so important.

I have also seen places where the business is only involved up front and then, as requirements are developed, the direction of the solution may change in isolation from the business. This may cause many problems further down the track when the business sees the solution as part of user testing or worse at implementation time. The agile way of developing does encourage greater closeness and collaboration between the business and developers. Thus, the inevitable changes can be discussed and agreed with the business as they are being developed. Even if you’re not using an agile approach, close collaboration between the business analyst and the business is very important, as is continuing that communication and collaboration through the development and testing phases.

No matter what technique or methodology is being used, the tools you have available, the industry you work in, it is more about people. Finding experienced and knowledgeable business people to work with and learn from is important. The can help with ensuring the right language is used, and agreement on requirements is reached. They also will play a part in developing the solution. Finding that expert or group of experts to help make the right decisions is truly worthwhile, even if you end up spending a little more time working on requirements.

Don’t forget to leave your comments below

Ross Wilson is a Principal Consultant with Equinox Limited in Auckland, New Zealand, specialising in business analysis, and training. He has been working in IT for 25 years and has a wealth of varied project experience in a number of different industries. For the last 14 years, he has focused on business analysis, training, project management, and team leadership. Ross can be contacted at [email protected].

Disassembling Your Cube

Written by Paul Mulvey on . Posted in Articles.

Most of us in Information Technology have seen the movie OfficeSpace. It’s funny because we can relate to the situations that the main character, Peter, faced. I’m sure that many of us have experienced a “Did you get the memo?” situation but I question how many of us business analysts have disassembled our cube wall? In one scene, Peter disassembles his cube wall to connect with the outside world, and I’m suggesting that as BAs, we do the same thing. Now before you all take out your cordless drills and start physically disassembling your cubes, I’m speaking metaphorically. We need to break down the walls around us and understand the business that is looking for solutions.

Break Down the Wall

Many of us who practice business analysis sit within and report up through the IT environment. We may even have a title indicative of that such as Business Systems Analyst. But just because we are in IT, we need to stop constraining ourselves with IT thinking and understand what it is that our business does and how their processes work. In this age of telecommuting, multi-tasking, conference calls, and webinars, when was the last time that you actually sat with a business person as they performed their job to truly understand what it was that they did, and why they did it that way? Get out of that cube, get into the business, and learn what your business does. Better yet – see if you can learn how to do it and you try and do the work. This may be more challenging than you think; we often think that someone else’s job is simpler than our own. For instance, you may be studying an easier way for a business user to produce a certain report. When you perform the steps that they tell you, you might get completely frustrated switching between three to four different computer systems, writing down information from one to enter into another, etc. By doing so, you experience the same frustrations that they do, and you will quickly start to think of a better way to do it. While not everyone can perform the work that they are analyzing (say, a BA designing flight controls systems for a military jet doesn’t get to fly the jet – but boy, wouldn’t that be fun!), if you are able to do the work it gives you great insight to the troubles that operators face daily. You start to see the world outside your cube, looking in at IT.

Looking at your profession from the outside is not easy. Be prepared to see things that you do not like, such as disjointed ways for users to interact with the software that your organization puts out. One example; most of us probably use Microsoft Office. This office suite of tools tries to standardize commands as much as possible between Word, Excel, and Powerpoint. Pressing CTRL+F in Word (or COMMAND+F for us Mac users) initiates a search, same as the other Office products. Now consider all the other applications that you use. Is CTRL+F the same in all? I can name a text editor that uses F3 as the search, another program that has no hot key for a search and in which I have to click a button. And that’s just off the top of my head. Does your organization roll-out different applications from different product portfolios that have the design of Office’s parallel commands? Do your accounting applications search in the same way that MS Office does? How about your other applications? By getting outside of your cube and looking in from the outside, you will increase your familiarity with the area that you support. The end result is that you will be able to see a lot more of the world by getting out into it than just looking at it from within your cube.

Don’t Just Accept the Solution

By getting into the outside world, you start to see how the business operates and can start seeing solutions that you didn’t previously know existed. Users may not tell you everything because they are smart and figure out ways to get things done either inside or outside the system (or problem area). What they may see within their span of control as a solution may be completely valid. Based on everything they know, they are requesting a change in the process, but what they are really doing is proposing a solution. It’s your job to get out into the business to uncover the problem instead of just accepting their solution.

Consider this; you, as a BA, have a request from the business to create an Excel-based report from Application A. In your cube, you do your job as a BA and ask what the business need is for this new style of the report. The answer is that the business needs to input this report into an Excel spreadsheet and they cannot do this with the current MS Word-based report. Requirement captured, right? Almost! If you had been outside your cube and in the business, you would have seen users outputting the Word report from Application A and manually entering the data from the report into an Excel spreadsheet in Application B. If your requirement was to create the Excel report, it would have made the key-entry situation easier, but you still have a manual process in place (export from one system and input to another). By getting out of your cube and into the business, you would have seen that the real problem was that the business’s process required getting data from Application A to Application B, and it was not the report format. Merely accepting the requirement at face value may have saved the business a little time, but in the long run, understanding the business problem by seeing it in action would have resulted in saving a lot more time, and would have been a better solution.

Partner with the Business

Because we are so comfortable in our cubes, we tend to stay there. Yeah, we do have nice chairs but we can’t sit in them all the time. We have to get out into the business areas that we support and get them to trust us. Trust us to the point that they know that we really are there to help; to help uncover ways to improve their processes, and to help make their lives easier.

If you can show the business people that you are not just there to “take their order” as I’m fond of saying (like a waiter/waitress at a restaurant), they will become your trusted partner. But, you have to show them that you can bring something to the table. To do this will require that you understand their problems and bring a solution that shows you understand. If all you do is write down what they request, you provide no additional value. They received what they asked for, and they will wonder why you are even involved in the process in the first place.

Consider the difference from their viewpoint; they may be asking for that new report, but you find a better way to fix their business problem and make their jobs more efficient. Now they will see you as the change agent and the person who understands the problems that they face. They will start to contact you instead of their normal channels because they have seen that you were the one who sought to understand their problem and that you solved it. Instead of just the solution that you delivered on the first project, they may well start to contact you and suggest other fixes that you could make. The business has seen that you, as the BA, are the one that solved the problem on the original project, so now you are a trusted partner. While not all of the changes that they suggest will be something that you can make (or even have the budget for), they are problem areas that the business experiences day in and day out. They can be logged as future projects, or if in an agile development world, onto the project backlog.

So go ahead and break down those walls around you, and not by disassembling your cube. And while I welcome e-mails, I don’t want to see any in my inbox from your management saying that I told you to take apart your cubes. Remember, I was speaking metaphorically.

Don’t forget to leave your comments below

Paul Mulvey is a Lead Business Systems Analyst at UPS. He has just completed creation of a BA Certification program within UPS and is sitting for the CBAP exam in March. He can be reached at [email protected].