Saturday, October 3, 2015

Questions to ask at a requirements elicitation interview.

When I was an 18 year old trainee analyst I had to do my first requirements interview. I met with this old guy, who frankly would probably now be to me a young guy, in his office. “Tell me about your job” I said. “I’m like a mushroom” he said. “Kept in the dark and fed bull****”. I didn’t know what to say.
Don’t be caught out like I was. Here are some questions you need to ask when eliciting requirements by interview. Take a deep breath. Here goes:
  1. What is your current job title?
  2. Who do you report to line?
  3. Who do you report to functionally (dotted lines)?
  4. Briefly summarize your responsibilities.
  5. Do you have any accurate and up to date documentation that describes your responsibilities? If so, can I have a copy?
  6. What are the triggers that cause you to start the tasks for which you are responsible? Can I have copies of any associated documents, screens or reports?
  7. What do you do in each of these cases? What are the key steps you take? Who do you work with? What systems do you use? How do you know when you are done? What deliverables do you produce? Can I have copies?
  8. What works really well in your current job? Why?
  9. What works less well? Why?
  10. What happens when things go wrong?
  11. What happens when things go well?
  12. What suggestions do you have for improvements?
  13. What is your greatest challenge? How do you overcome that?
  14. If you could make just one change that will bring about significant improvements, what would it be and why?
  15. Can I have a copy of any remaining forms and documentation that you use?
  16. Can I have examples of any remaining system inputs and outputs that you use?
  17. Can I have a copy of your job description?
  18. Who reports to you? What are their titles and responsibilities? Can I have copies of their job descriptions?
  19. What training is required for your position?
  20. What training have you attended in the last two years?
  21. Who else should I speak with to obtain more information?
What do you ask? What are your favorite questions? What question do you most regret asking? Comment below!

Be professional and human: practice situational evolution!

As a practicing business analyst you are in a position of trust and privilege. You help organizations identify and solve business problems. You help to bring about change, and can have an impact on the lives of many employees, and the whole enterprise too. Professionalism is key; you want to be seen as an objective and trusted partner who gets things done. But if you remain aloof or detached you will undoubtedly miss opportunities to get the most value out of your stakeholders. So we practice situational evolution, so relationships start off on the right foot, and develop effectively.
So what is situational evolution and how do I do it?
It’s all about timing really. Imagine you are about to be interviewed about your current position by someone you don’t know (a business analyst). If that business analyst walks in and says “Hi, how you doin’? Went to a great party last night and boy am I hung over. OK let’s get down to it. Tell me about…”
Doesn’t create a good impression does it?
Consider a different situation. You have been working with business analysts on a project for six months full time. It’s the end of the project and one of the business analysts says “Our project is finished on time and on budget. I will see you at the presentation. Thank you for your exemplary efforts”. You ask the business analysts if they’d care to join your department for your next lunchtime pot luck, and you are told “thank you for the offer but we have work to do.”
You would probably be a bit hurt that your offer of friendship was rejected.
And that’s why we need to understand situational evolution.
At the start of a project, err on the side of formality. But as you get to know your stakeholder colleagues, start to drop some of the formality and interact with them in a lighter way. Now, care is required to time this correctly and not commit any social mistakes. And I would always recommend erring slightly on the professional side of things if there is any doubt. But your stakeholder relationships, and the quality of your work, will improve if you allow your relationship situation to evolve as you work together.
A major issue with this can be if you are working with a group of stakeholders with which you are very familiar, and where the situation has evolved to one where there is some joking and social activity. But then someone new joins the group. Remember that the new person’s situation is yet to evolve from the “professional” start point. So fall back to this until the new person “warms up”. It usually only takes a few days.
Have you ever been bitten by an error in situational evolution? Do tell – post a comment!

Just say “no” to requests for confidentiality.

When eliciting requirements you may sometimes be asked if you can be told something in confidence. There’s a great temptation to say “yes”. After all, you are a professional business analyst who can be trusted, right? But “yes’ is the wrong answer. Let’s see why.
You are in a somewhat privileged position when you are meeting with a stakeholder. It’s not often that an employee has a chance to provide facts, details and opinions about their work, and you are enabling that to happen. It will sometimes be the case that an employee will have something in mind that has never been shared, and perhaps they want to, but are fearful of doing so to their colleagues or managers. That fear may be real or not.
We want to avoid the observer effect; that is, where we measure something and measuring changes it. The professional business analyst wants facts, and also opinions, providing they are understood to be such. By taking on confidential information, whether accurate or inaccurate, real or perceived, we are in danger of allowing our elicitation process to change the environment. What expectation are we creating in the confider by allowing them to confide? And more important, what are we expected to do with the confidential information? We certainly can’t pass it on: it’s confidential!
A derivative of this is when you are told “this is confidential. You can pass it on but don’t attribute it to me”. All findings from elicitation must be reviewed and signed off by the providers of the information. This has to be done in writing. So you have to make a written record for validation, which thus becomes attributable (unless you try to keep everything anonymous. But anonymity betrays the value of the information elicited. And you can be sure it won’t stay anonymous for long!)
The bottom line: if asked if you can be told something in confidence say no. Otherwise you can end up making yourself the office gossip.
But can we do more than say no?
Of course! Encourage the would-have-been confider to bring the issue up to a supervisor or manager. A person in this role is the best person to deal with any confidential issues, and their reality (or otherwise). And get to know the current state of your domain well. Observe what really happens, and incorporate your observations in to your findings. These observations will mention situations and individuals. And that’s OK. You are not breaching any confidentialities.
So, do you agree? Are there any circumstances you have encountered where you have accepted confidential information? If so, what happened?

Business analysis myths.

  1. A business analysts can act as a proxy for a subject matter expert.
  2. A business analyst must have business knowledge of the enterprise in which the analyst is working.
  3. You can become a business analyst without formal training.
  4. Business analysts are not needed on agile / lean / … projects.
  5. Business analysis slows down projects.
  6. Working code is needed, not documentation.
  7. Upfront planning is not needed; architecture emerges.
  8. Subject matter experts must work with developers, not analysts.
  9. Modeling tools generate poor code, so don’t try to use analysis models (or any models) for this purpose.
  10. Software quality is a job for QA; requirements is a job for the business analyst.
Any more? Disagree? Post a comment!

Get better at buying stuff (Part 2).

If you haven’t read part 1 already I recommend you do so first!
So now we know we need to acquire something. And we know the relative importance of the features we need. What next?
There are lots of organizations out there clamoring to meet your needs. The key is to hook up with the right one. The key to success is to understand what you are really buying. Maybe it’s obvious. Maybe it’s not. Let’s think about it.
Say I’m buying a vacation. My needs for the vacation are focused on the vacation itself, with the hope of a great time and happy memories. The life of the product I am buying ends at the end of the vacation. Now say I am buying a washing machine. The feature themselves are really important, but the life of the washing machine is going to be longer than most people’s vacations. So over that life you are buying a relationship with the vendor from which you made the purchase, and to some extent, the original manufacturer of the washing machine. After all, you will usually need parts and repairs at some time. So see the acquisition as being not just the washing machine, but the relationships. It’s the same when buying new kitchen equipment, and a car, with each requiring progressively more rigor.
Now imagine needing to acquire something really important and / or complex. Say a brand new house. Or a computer system for a large enterprise. You know what is essential and important and you are ready to assess what is available. Unless you only intend to keep your house for a very short time, or if you are desperate for a house, then relationship with the vendor is really critical to manage the risks of your acquisition. You must realize you are buying a relationship as well as product. And further, you need to be very, very careful about customizing your acquisition. More on that later.
So with our essential, important and desirable features (that I will now call requirements) in hand, you can start on the acquisition process. In summary, what you need to do is find out what options are available in the market place, assess how well each option meets your requirements, and then decide on the option you prefer.
You’ll start by doing your research. At this stage you are not buying, all you are doing is seeking information. Use the Internet to obtain information, and be sure to consult independent reviews of the products. Obtain brochures. Visit the companies who supply the products you are interested in, but don’t reveal that you are buying (yet). Ask questions and assess the answers. Seek out anyone who already uses a product you are using and record their experiences and opinions. Write it all down. Ignore “buy this quick / special offer today only” unless you want to risk making a mistake or you are absolutely certain that all of your essential and many of your important requirements are being met at a realistic price from a vendor with which you are confident you can will have an excellent relationship. And even then, think twice at this stage.
When you have completed all your research, lay it all out and review it. Then look at your requirements and assess the extent to which each option meets your needs. An option is rejected if it doesn’t meet all your essentials. After that it is rejected if it does not meet any important requirements. Hopefully you have some options left! If not, you will have to either compromise on one or more of your essential requirements, or do more research.
Hopefully you have at least two options left. And no more than three. Now you can scrutinize the remainder to make your decision. Consider first the number of important requirements, and then the number of desirable requirements, that are met. And be sure to consider all of the relationship factors for important acquisitions.
Now let’s come back to customizations. Providing you don’t compromise the integrity of the original product, customizations can be ok. A different color on a car, a new type of entertainment system offered by the manufacturer, are all reasonable examples. But changing the engine to a new, third party product may not be the best idea, unless you really are looking for something special. Because if the engine is non-standard maybe the hood has to be non-standard, and that makes more work. And if you are in a wreck and the body gets damaged, getting the hood replaced will likely be problematic. If you are going to buy a standard product it is better to adapt your needs to the standard product, rather than having it tailored. And this is never more true than with computer systems. Never tailor the standard product, because computer systems (almost unique to computer systems products) can be upgraded (on some occasions they must be upgraded). And if you have moved from the standard there is a very high chance you won’t be able to upgrade. With computer systems and products like them that can be tailored and upgraded, never do customizations to the product to meet your needs. Adapt your needs to meet the standard. And remember you are buying a relationship as well as a product.
Now you are in a position to buy. I’ll leave the commercial aspects to someone else, or maybe a later blog. What do you think/ Do you instinctively do this? Or something else? Have you used this successfully? Let us know – comment below!

Get better at buying stuff – why keep doing it the wrong way?

So you might say “I’m great at buying stuff, I don’t need any help”. You might be more likely to say “my spouse / significant other / child is great at buying stuff and I need them to do it less!” Either way, with a little learning effort you can improve the way you decide what to buy. Read on to find out how.
But it’s all a question of scale. The bigger the purchase or its impact, the more this applies. For smaller, low impact purchases, this is usually not appropriate (but some of the underlying principles may fleetingly apply).
Getting it right goes like this: What do I need? What are the options? Which is best? Decision. Sounds simple. It is.
So how do I get to what I need? First let’s understand the difference between “want” and “need”. The best way to describe the difference goes something like this. I want a Ferrari. My wife says I don’t need one.
But seriously, a want is an idea, possibly an impulsive idea, which is often an emotional reaction to a perceived need. Maybe advertising generated your want. Maybe a perception that things are stagnating and you need to keep up. Maybe excitement about a possibility or idea you have had. Maybe even envy. Maybe even genuine consideration that something new must be acquired for real benefit.
The key at this stage is “why”. Why do I want this? What benefit am I really seeking to achieve with this anticipated acquisition? And this requires honesty and self-awareness. Not just domestically, but at work too. In large, global enterprises. Really.
A great way to do this is to list the consequences of not buying what you want. And all of the negative consequences of buying it. For example, if I don’t buy that new car I will have more money for my vacation. And if I do buy the new car, rather than keeping the old one, I will have to take greater care about where I drive; no more charging around muddy country lanes!
So now you’ve decided that you really do want this new thing. So we can now say that you need it. I wanted my Ferrari, but it couldn’t take all of the clothes my wife likes to buy on shopping trips, so I know I need a new car, and I know I need a capacious trunk.
It’s time for more detail. What are the features you need from this new acquisition? Start by writing down as many features as you possibly can. The more the better. Ask others to help. We are looking for quantity of features here! Don’t worry if you think the features are not relevant or may not be needed.
Then, for each feature in the list we come up with a rating. The ratings go like this. Essential. Important. Desirable.
  • Essential means “I will not acquire the item unless it has this feature”.
  • Important means “I am prepared to acquire the item without this feature, but it will be inconvenient”.
  • Everything else is Desirable, which basically means “don’t care if it has this or not”.
If what you need to acquire affects more than one person do this activity together (even consider doing it independently first, and then having a debate). Do you think this could help with planning your next family vacation?
And now you have an objective assessment of what you need. So the next step is what is available to meet your needs. We’ll talk about this in part two of this blog (coming soon!).
REMEMBER: when you want something, try to focus with objectivity on why you think you want it. If it passes your objectivity test, the chances are you need it. And to get better really quickly, consider signing up for our Software Acquisition Service.

What skills do you need as a Business Analyst?

You are just starting to embark upon a career in business analysis. Where do you start? What do you need to learn?
Let’s uncover some of that information for you, and point you to some resources that will help with your research. First off, let’s look at a definition of what a business analyst is. This comes from the 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.”
One of the first questions I often hear is something like “do I need domain knowledge (that is, knowledge of the business area in which I will be a BA) to be a business analyst?” The answer is no. I suppose a little knowledge may help, but your job as a BA is to elicit the domain knowledge from subject matter experts (those who know the domain because they work in it, and are experts). Almost by definition, you cannot be a subject matter expert and should not be a subject matter expert in anything other than business analysis. For some reason this is a controversial statement; reasoned arguments welcome in the comments for this blog!

So what qualities do you need demonstrate to be a successful business analysts?

At the most important level it all comes down that which it is difficult to quantify:
  1. Excellent interpersonal skills.
  2. Clear thinking.
  3. Confidence.
  4. Determination.
  5. Critical thinking.
  6. Objectivity.
  7. The power to inspire and win confidence.
  8. The resolve to see the big picture and deal with ambiguity.
  9. A love of simplicity.
Getting more specific; an ability to know how to:
  1. Facilitate change
  2. Interview
  3. Lead
  4. Communicate verbally, in writing, and in pictures, with clarity and authority
  5. Organize
  6. Plan
  7. Measure
  8. Present
I am sure this sounds like a lot! And it probably sounds intimidating. But don’t be put off. Because business analysis can be a lifetime career in to which you gradually grow from beginner to expert, from dealing with well defined, simple issues to the most complex business problems imaginable. A continual challenge, gradually building on past experience, the experience of others, and always learning.

 So where to start?

A course in Business Analysis is a great place, especially those offered with an IIBA endorsement. I know this is a good one (disclosure: I am one of the three lecturers!) Take a look at Purchasing Therapy for advice on the right way to go about finding what you really need before acquiring any of the materials recommended here.

What else can you do? And what if the expense of a course is beyond your financial budget right now?

Read. Look at these great resources, both books and web sites, free and paid
Join a local BA User Group. Seek out a mentor if you are currently employed, who can help you learn and apply analysis skills.
Carefully consider the qualities of a BA listed above, and if you feel you are a good fit for the role, persevere!
Also, look at finding training courses based on the “abilities” listed above. Classes are easy to find in any of these categories, and are generic, and easier to justify with your current employer.
And by the way, we also so have some information on starting your BA job hunt.

Why every business analyst should be a subject matter expert.

This blog entry is targeted at practicing business analysts who believe that expertise in the business domain in which they are working is essential.
Recently on a social networking site I have seen much discussion on whether a business analyst can fill the role of “SME” (Subject Matter Expert). Almost everyone said “yes, of course, it’s part of the role…”. I definitely agree that a business analyst can be a subject matter expert: on business analysis. But nearly everyone participating in the discussion expressed a view that the business analyst can be a subject matter expert in the business area under study (the domain). I call someone in this role a subject matter expert proxy.
We need a definition here. From the Business Analysis Body of Knowledge:
“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.” (source

A business analyst does business analysis. A business analyst needs to be a subject matter expert in what is defined above.
Now someone who fills the role of a business analyst may also fill a separate role in the business, in which they are also a subject matter expert. But the roles cannot mix. You are either the business analyst or the subject matter expert. It is not acceptable for someone who is a business analyst to be a subject matter expert proxy, for two reasons:
  1. The real subject matter expert must be available. They have current knowledge of the domain, and are in a position to understand their needs. It is dangerous to use a proxy, because they can only think they know the domain. It’s not their core skill area. Expert is a strong word. And even more importantly:
  2. If the real subject matter expert is cut out of the project, then is it because they don’t have time (and if they don’t, what makes anyone think they will have time to implement the new system?) Is it because someone thinks they are not needed, and that IT knows best? And most important of all, if the real subject matter expert is not involved in the project they won’t feel any ownership, and when the going gets tough there is a high risk they will walk away and any project deliverables won’t be used.
Imagine you go to the ER with a serious wound. The nurse isn’t available quite yet. But along comes the hospital business analyst who works on the health management system and says “I am a subject matter expert in nursing; I’ll help”…

Based on my experience and opinion the real subject matter experts are the people who know best. Business analysts need to know how to elicit information from them. The Body of Knowledge may not be perfect, but it does make the definition of analysis very clear. By all means call yourself “SME”. But don’t kid everyone that this is business analysis.

Dealing with software acquisition related problems.

Buying vs. building systems to meet your needs is a difficult decision, with traps waiting for the unwary (and even for those with experience). If we assume that building a system is not going to be an option for you, then you have to buy. This makes perfect sense for commoditized, well defined needs (such as preparing your tax return, email, bookkeeping, spreadsheets, word processing, games, and so on).  You still need to understand the various different products that are available, and which you prefer, but building your own is not viable if you want something to use (rather than the questionable delight of building something!)
But what you may not realize is what you are really buying when you acquire an off the shelf solution. So let me explain.
It’s easy to think you are buying a system that you can tailor to your business. But that is completely the wrong mindset. While some form of limited customization is always needed, anything that moves you away from the standard product must be avoided. Why? Because then the system either can’t be upgraded at all, or can’t be upgraded cost effectively after such changes. Maybe you think you can live without all the cool features the vendor will add. But what about security updates, regulatory changes, and all that sort of thing. You will be on your own, or at the mercy of the vendor for expensive customizations for stuff that otherwise would have been available within the cost of your maintenance agreement. So you are not buying a system to tailor to meet your business needs. You are in fact buying a system for which you will change your business practices so that you can work with the system. And you are buying a relationship with a vendor where you can work together for mutual benefit in a jointly profitable relationship.
I have seen many, many projects fail because an enterprise didn’t really realize what it was buying when it bought an off the shelf system. Don’t fall into that trap! And don’t do unpowered change!
So what do you do if you are stuck with a system that doesn’t do what you need it to do?
Well, you could always purchase our Software Acquisition and Use Consulting service, designed to give one on one advice about a specific situation, either before or after acquisition. Ultimately, you will have to change your mindset, and you will have to develop exceptional relationships with the vendor (even though things may have got adversarial).
We are working right now on a software acquisition practices class. While it may be too late for this if you have an existing system with a problem, it’s never too late to learn how to do it better next time. Follow needpoweredchg on Twitter to hear an announcement when the class is ready.

Bring requirements to life.

Requirements by arborcide serves no useful purpose to anyone (hopefully I have painted a powerful case for that but let us know if not). We need to get people engaged, thinking about the real world, and what really needs to be present in a new system. One way we have managed to make the requirements process more real, more engaging, has been by using personas.
Now before I go any further, let me say that personas need to be written with care. I don’t care about superfluous detail, such as Mary is 42, has 4 kids and a dog and drives a minivan. But I do care about her characteristics that impact how she may use my system.
Personas set me thinking – could we extend this concept, and come up with something that could be engaging and useful for high level requirements. And here’s what I came up with.
I started by reaching the conclusion that personas are like role descriptions for actors in a play. So it’s not a huge leap to suggest that we describe the “to be” system in the format of a script. Keeping this at a high level, and describing a business process as a script, allows us to use tools (script writing tools and a proven approach) to document the new process. It also allows “actors” (i.e. the real business participants) to act out the script as a play, thus validating or testing the new process (especially with an audience present). And the play can be filmed and sent to others for validation and comment.
I already have a script writing tool, and am getting close to having something to publish. Some of the new animation software and services can also be used as a way to illustrate these ideas. Follow us on Twitter at needpoweredchg to hear news of when some of this work is published.

Why your latest requirements document is worse than useless.

I’m sure that last time you created a big, thick, detailed specification of everything that is needed in a new system it gave you a tremendous feeling of pride and accomplishment. And that summarizes the only value of that deliverable nicely. Because I bet no one read it. I mean, really read it. And even if they did, I bet it doesn’t reflect what was actually built. And even if it did, I bet that within months it was out of date. And even if it wasn’t I bet no one trusts it so no one looks at it anyway.
Arborcide is the murder of trees. An unintended but real consequence of a big, thick requirements document (OK, maybe virtual trees).
So what is the alternative?
Some level of documentation will always be required. Small, lightweight documents that describe the big picture and a cross reference to details are essential. But how do you document detailed requirements? And how do you make sure that the requirements are still valid and current?
The one version of the truth about the way any software system really works is the source code from which the system is generated. The problem is that there is a lot of source code and it is hard to see the wood for the trees. And you have to be proficient in programming languages to read the code. And that only tells you what the system does, not what it is supposed to do, and whether it really does it.
So, to summarize so far, the picture we are painting seems to indicate that we need to document the system in the source code, by showing what the system is supposed to do and proving whether it does it.
Can we do that?
It sounds a little bit like testing, doesn’t it?
Behavior Driven Development, sometimes abbreviated to BDD, allows you to do just this. The business analyst, or QA, or a developer, or even an end user, writes a user story using an intuitive syntax that reads just like, well, a story. Instantly recognizable. The story is written in any text editor (a word processor will do) and is then placed in a programming tool (note that tools are becoming available that allow users to create stories easily in the developers’ development environment). The story might look something like “As a customer I want to browse available products and if I see something I need request an order”.
The story is then elaborated to describe more detail, using 3 statements:
  • Given
  • When
  • Then
Given identifies a precondition; something like “given a customer wants to buy a product”
When identifies an action that is taken; something like “the customer enters product details and quantities and presses submit”
Then identifies the work the system does; something like “the system checks for available stock, and if available creates an order and prompts the customer for name and address”.
This can also be started by business analysts but can require developers’ help to finish.
All of this is written before any real programming starts. And at this point you can “run“ the above. And everything fails because there is no program!
But see how that tells you that there is some work to do. And the developers write the program in such a way that the result needed from the “then” can be verified by the system. So when the system matches the expectation specified in the “then” the functionality is complete. What a way to track progress! And look how the documentation matches the source code perfectly. And guess what – every time the system is built, forever, these test run. So if someone breaks something you find out right away because a test fails immediately. And the documentation can be trusted because it matches the system.
Is this real? Can it work? Yes it can! Organizations are doing this now.
I’m just sowing seeds for interest here. I will blog more about this, and give some examples of tools and books that can help you move forward on Behavior Driven Development. This is a great opportunity for generalizing specialists!
Follow needpoweredchg on Twitter to hear more news on this topic. And let us know if you’d like more detail, or even training classes on how to get started on Behavior Driven Development.

Stop focusing on projects.

The information technology industry is obsessed with building things. Projects are our lifeblood (whether “projects” are formalized or not). But projects are not even close to being the most important thing for a business to focus on (unless your core business is executing projects!) Projects are just a source of cost (from which, hopefully, value will materialize). The obsession with projects leads to agile development, rapid development, improved, faster tools, and on… When such methods are used to deliver value more quickly then all is well. But if projects aren’t the most important thing to an organization, what is?
The purpose of a project is to deliver something of value to an organization, such that the costs of the project are offset by the value derived in a realistic timeframe. Projects build products, or changes to products. The life of the project compared to the life of the product should be small to large. However, sometimes things are needed with extreme rapidity. Maybe a regulatory change or an opportunity to innovate creates a need for a new product that must be built rapidly. What does this mean to cost, value and project lifetime?
Initial thinking may say something like “build it as fast as possible and forget long term viability. Having it now is more important than having it later and better (– often with an implied hopefully!”) So in this scenario what we are saying is that it is worth incurring what is fashionably (and accurately) called technical debt for the sake of being able to deliver earlier. I guess the thinking is that the technical debt will be fixed later, or that version 2 will be a rewrite (assuming that the need for which the product was built does not go away). The project mentality wins again.
One thing is more important than a project. The product. One thing is more important than the product. Data. Nothing is more important than the data. And what this says is that you must focus on the longer term. Remember the iron triangle (faster, better, cheaper, pick 2?) Better is needed if you have a product and data mindset. So that means cheaper is not an option. You need to be prepared to pay for the best of the best, or else your product and data are sacrificed. That is not to say that faster and cheaper are never appropriate. Just realize that cheaper may only be cheaper in the short term if less than better is not good enough beyond the short term! Soda cans provide an answer.

Why teamwork is too often misunderstood.

We all participate in teams in all sorts of ways, and nearly all the time. Teamwork remains much misunderstood, despite Teamwork training and literature being oversold and overhyped. To me the acid test of the extent to which teamwork is understood by organizations and individuals is easy to assess. Then, if it becomes apparent that teamwork is not understood, you have a base from which you can help bring about improvements. So what is this secret?
“there is no ‘I’ in team”, blah blah blah. I get tired of hearing all that stuff. But one simple statement reveals so much about whether or not teamwork is understood. It goes like this:
When things go well, praise the individual. When things go badly the team takes the blame.
The reaction you don’t want to hear to this is something like “that’s ridiculous, people need to be accountable for doing their jobs. We don’t cover up failure. We hire slow and fire fast…..”.
I’ve heard that said several times and in the end I always disengaged from those employment situations. And yet you can sort of understand that lack of performance shouldn’t be hidden…
Of course it shouldn’t. But neither can everyone excel at everything. Effective teamwork, and effective leadership, is all about allowing individuals to use their strengths, and support them in their areas that need development. That is real teamwork.
So why is teamwork always misunderstood? Because we don’t take the time to understand each other better, or even recognize the need to do so.
When starting work with a group of individuals, how often do you discuss interests and disinterests? Like and dislikes? How often do you share resumes and experience? How often do you discuss who is best for which job? If the answer is always, great. If not, well, maybe you now know what to do.

What is the right role for a Business Analyst?

As a practicing business analyst the chances are you participate in a wide variety of projects, on many different teams. And usually, at the start of such projects, roles and responsibilities have to be discussed and agreed. Conflicts of opinion often occur, as business analysis, project management, development and quality assurance duties partially overlap with each other. This is not a bad thing. Instead of entrenching behind strict boundaries, all roles, and particularly business analysts, need to see themselves as generalizing specialists.
So what is a generalizing specialist?
As a generalizing specialist you must be experienced and knowledgeable in your own domain. But you must also have an understanding of the responsibilities of the roles with which you interact, and be prepared to take on some of these roles even, too.
I can learn a lot about the quality of my requirements by working with QA, and even helping QA to do the testing. But guess what? QA can really help me with my requirements. I focus on the common cases and the main exceptions. QA bring a different mindset – “what will go wrong?” – and this so often brings up all sorts of requirements discussions. Do we include validation to support this? Or do we handle it through documentation?
Some of the greatest opportunities for role generalization for me have arisen with developers. Design documentation of any type was not being produced and mistakes and assumptions were uncovered too late. So I offered to attend design meetings and take notes. Reluctantly the developers agreed. But then, as design progressed, the developers had all sorts of requirements questions and I was there to answer them (or find answers). And not only that, sitting and working together built up understanding and trust, and our working relationship improved. Finally, the development manager asked to come along to requirements meetings to help learn about the business needs. And the quality of delivered software improved because development assumptions became better aligned. And I learned how to document designs!
An even better example for business analysts related to partnering with business. If you are about to work in a new business domain (or even for a current domain in which you believe you are an expert) go and do the job for a few days. Really do the job, working on production business. You will gain a much better understanding of the requirements that way. And when, in reciprocation, the business folks help to write requirements, they will have a better understanding of systems too.

I want to get started as a Business Analyst.

A question I am often asked, particularly in my role as a lecturer in a university professional education program, is “how do I get started as a BA?” So I thought I’d write an answer down as a reference for people, and also to solicit further feedback from readers.
It’s a hard question to answer.
I think there a few situational patterns:
1. I am employed in IT (say in QA, or as a systems analyst)
2. I am employed in a department that uses IT services
3. I have a degree and no job experience
4. I have just left school high school / secondary school
5. I have / will have completed a BA certificate (IIBA, NCC, BCS etc)
And there are a few types of hiring companies:
1. Those that hire for experience
2. Those that hire for attitude
3. Those that use contract resources
I have been lucky enough to work for a company that hires for attitude, trains for skills. If you can find one of those, and there aren’t that many, then it really doesn’t matter which of the 5 situational patterns is applicable. Do your preparation as you would for any job, learning about the company and what a business analyst does, and then apply. An internal contact always helps, probably significantly, so if you know someone, use someone! I have been involved in hiring several BA’s from outside the company this way and it works out well. More on that below. And look out for intern positions to get your foot in the door!
Finding a company like this is the only realistic option if you have just left high school / secondary school. I started out this way at age 18, knowing nothing about business analysis and was very fortunate. I received over 2 years training and 3 qualifications all while getting paid. Such opportunities now are hard to find… try careers advice centers; that is how I found mine.
But there are some key questions you need to ask before accepting a job: Is there a formal training program? Does it include external training? Who pays? Does who pays change if I leave? How long does the training program last? Unless the role is formalized and you can see evidence of that then maybe you won’t be learning how to be a BA. Maybe you’ll be learning how to work at that organization “on the job”. Which may be OK as a way to get experience.
For companies that use contract BA resources, then to be hired as a contractor you need demonstrable business analyst experience, and since this is not the case (as you are starting out) then avoid these companies. Sadly, there are many of them about, particularly in my neck of the woods. It’s hard to get hired as a Business Analyst employee these days.
So, we have left the companies that hire for experience. Whereas I suggest that for contract positions a “starter BA” is automatically disqualified, I do not believe that is always the case when companies hire for experience. After all, business analysis is practiced by almost all professionals to some extent. What you need to do is identify which of those skills you have, and be able to describe how they were applied in your career to date. It won’t be easy, but if you try hard enough you may be able to get an interview. As always, don’t “invent” experience: be scrupulously honest. And provide evidence of the work you have done (but take care with confidential information – never leave materials of any sort with an interviewer if they are from your employment). Materials from a BA class are the best to use. And a BA class is a great way to consolidate your analysis experience if it has so far been gained while not employed as a business analyst. Take some of our classes (follow needpoweredchg on Twitter for announcements), and produce examples to take along.
Networking is a great way to get ahead of the pack in terms of job leads and prospective interviews. Find out if there is a local IIBA chapter and attend their meetings. Meet people and don’t be shy about sharing your job needs. And a BA class will help you meet other BA’s and develop leads. Of course, is also a great place to learn and meet other BA’s, albeit virtually. Having a LinkedIn profile and joining BA groups there is another great way to develop contacts.

One de facto IT standard.

Diagrams are great communication tools, but it’s too easy to draw awful diagrams. Consequently, I see lots of awful diagrams!. Such diagrams fail to get their message across efficiently, or in many cases, at all. 
The problem is that too much of the interpretive work is left to the many readers, when the author could have done the interpretative work once. The author can create a clear diagram, with few opportunities for errors of interpretation. It may be hard to create something simple, but that means it’s even more necessary if that something is to be useful.
There may only be one standard you ever need; one, truly universally applicable standard, but there is one other standard that applies in almost every company I have ever visited. I bet it’s a standard where you work to. It goes something like this:
“Decorate the walls of the data and process modeling departments with large charts that can only be printed on a very large plotter (or on smaller pieces of paper stuck together with tape).”
It’s everywhere. And it offers no value, other than a perceived and failed demonstration of modeling prowess (“look, I’m clever enough to produce these big diagrams that no one understands…”).
There is only one course of action: eliminate these useless paper and time wasters immediately.
So what happens when a diagram is too big to fit on a piece of paper? Well that’s going to be a subject of one of our classes, but here are some rules and hints:
1. Diagrams must always fit on a piece of letter / A4 paper…
2. … and be readable
3. Simplify, by summarizing and cross-referencing from high level to detail using business metaphors (that means death to the “off-page connecter”)
4. Place only around 7 +/- 2 artifacts on any one page
5. Only use color as a last resort, and if there is a plentiful supply of color printers
6. Summarize the key points of the diagram using supplementary materials
7. Use standard notations and diagramming languages
8. Invest in proper diagramming tools (not drawing software).
There are so many “yes, buts” to the above. I disagree with them all (bloggers are supposed to be opinionated, right?!). But seriously, this is really important stuff. Take a hard look at the diagrams you are producing with a critical eye, and make them easier to consume. And if you draw a blank, try our class (follow needpoweredchg on Twitter to be notified when it’s available).

Modeling languages make drawings superfluous (but not always).

Analysts communicate. We elicit requirements, test understanding and document our findings. A good command of spoken and written language is essential. And sometimes pictures can help. “Free form” drawings used to illustrate business scenarios can be very helpful (for example, if you are working for a jet engine manufacturer you could illustrate the complexities of tracking assembly parts using hand or computer drawn pictures, or even photographs. Truck routing optimization for a delivery company could be illustrated with nodes and arcs). As useful as these free-form illustrations can be, more help is available to analysts in the form of what are known as modeling languages. It is vital that analysts know modeling languages and can apply them effectively. Let’s learn more…
A modeling language is a set of diagram types, into which we draw symbols with special meanings. There are rules, often rigorous, about how these various symbols are used and connected. Learning modeling languages can seem intimidating (to prove this see this official reference). Modeling languages can be very complex (many of the diagrams and symbols look similar but have powerful or subtle differences.
But if you think about this is true of spoken language too! And more than 80% of the time you use a lot less than 20% of the modeling language “vocabulary” (also true of spoken language). Some very smart people created the modeling languages and diagram types, and by using the modeling language you can use their expertise to your advantage, as long as:
1.       You learn why, when and how you need to use them
2.       You learn the subset of the language that allows you to be effective rapidly, and
3.       You stick to the modeling language standards all of the time
One way to simplify modeling languages is to use special modeling software. Though this software is “special”, and may take some getting used to, there is a huge choice of such products, many at very cost effective prices for individuals (in fact, some are completely free, and are good too!)
So what should I use?
You will most likely need a process modeling tool (which uses a language called BPMN2), and an analysis modeling tool (which uses a language called UML). 
The really great thing about specialist modeling software, apart from the modeling language that is supported, is that the software “understands” the model, and either won’t let you make “grammatical” mistakes, or will highlight that something in the model is in error (kind of like a spell check). See our list of modeling software, with reviews to help you choose. See also reference books for beginners, and more advanced reference books).
Word of Caution.
Some analysts like to use drawing software products (often purchased as a supplement to office suites), some of which have UML and BPMN templates. I strongly advise against using such drawing software packages, because they don’t “understand” the modeling language and allow you to make mistakes. You also end up spending more time working out how to draw things, which distracts you from thinking about what you should be thinking about: modeling.

Have you met the employee with a form?

Sometimes the best possible intent leads to dysfunction and waste. This can happen when the big picture gets missed, and “systems” are designed without considering the users’ perspectives. Good analysts always consider their actions based on the “audience” for the results, and that way, build better systems.
So what does this have to so with the employee with the form?
Some people seem to see a form as a cure for something perceived to be complex. Examples I have seen include requesting services from an IT department, identifying an enterprise single source of lookup data, or for estimating the impact a system has on production. The recipient to-be of the form thinks of their own needs and then creates the form.
They may even create a “how to complete this form” document (never a good sign if it takes more than a few sentences to do this). In one job early in my career I encountered someone with a form creation form, which had to be filled out to be able to create a new form. How the owner got the form creation form created is something we leave to the imagination.
In the worst “employee with a form” examples the form becomes a place to document everything that the recipient feels the requester must provide in order to fulfill a request. In this case such forms never seem to solve problems; they create them. Here’s why:
1.  It’s poor customer service.
2.  It feels like bureaucracy.
4.  It probably is!
4.  It creates an impression of pass or fail for the requestor, rather than collaboration to fill a need.
5.  It wastes time and resources; the requestor is not in the best position to assess what information is required and either glibly completes the form, or goes in to too much detail.
It’s not that forms are always a bad thing. But they must be used correctly.
As a business analyst studying an “as is” process, learn to look out for this. Find out from the recipient of the form what the intent is. Find out from the requestor if the results of filling out the form meets a real need efficiently and effectively. And think automation – look how much easier TurboTax is than filling out a paper tax return.


So you need to measure something? There are some golden rules that you must never break.
  • Spend more time using the results than measuring.
  • Know your audience.
  • Gain top down support and commitment.
  • Don’t trust data too soon.
  • Don’t measure or publish in such a way that results can be attributed to individuals.
  • Build trust with your audience.
  • Remember that often low precision is more useful than high precision.
  • Avoid premature precision.
  • Understand that a measurement without an associated objective is not a measurement.
  • Understand that a measurement without a benchmark is useless.
  • Maintain balance.
Remember that you will get what you ask for (measure), so anticipate unintended consequences (follow needpowerechg on Twitter to be alerted when we publish our Effective Measurement class).

Soda cans set the standard approach for business analysis.

Analysis must be “right sized”. Too little analysis, and even too much, damages projects. Analysts must think about right sizing and work with all stakeholders to achieve this. And there is no better way to illustrate this than by using cans of soda. You can even use empty cans from the trash.
Suppose I tell you to make a tower from soda cans. You have three cans and the tower must be three cans high. Easy. Just stack them one above the other and you’re done. Not only easy, but there’s no need to think about it first.
Now supposing I tell you to build a tower from 300 soda cans. The tower must be at least 15 cans high. Not so easy. Do you approach this in the same way as the three soda can problem? Maybe. But if you do, chances are you won’t get it right first time. Avoiding wasted effort from failed build attempts will probably be of benefit. That is not to say that you won’t need to conduct a few simple experiments first (to learn about “safe building”). 300 cans requires more up front thought than three cans.
Finally, suppose I tell you to build a tower from 300,000 cans that must be at least 3,000 cans high. Not only that, but the tower must be adaptable to adding more cans in the future, and changing the overall shape of the tower. In this case some form of planned experimentation and research will be vital to success and avoiding lots of waste.
In each of these three cases we can launch in to building the tower. With three cans it’s not even worth thinking about it – the effort involved doesn’t warrant it. But for the other two options it progressively does. In fact, for 300,000 cans, and possibly even 300, there are other questions we should think about. Are soda cans the best thing to use to build towers? Is there anything better? What will the tower be used for? How long will it need to last? And so on.
This is where the analysis comes in. Analysis helps to ensure that we really need a tower, that the risk of the tower failing to meet needs is minimized, and that expectations about the purpose of the tower are clear and managed.
What is true for soda can towers is even more true for business change projects. Learn more about this from our coming analysis classes; follow needpowerechg on Twitter now!.

Conceptual, Logical, Physical: HELP!

Standard modeling languages give you too much flexibility, so you can all too easily start developing your own proprietary extensions. This should be avoided at all costs. Using the standard language features as intended is more productive, and makes things easier to learn and share. Introducing extensions in a language to support conventions commonly practiced in another language only causes confusion and wasted effort. Try to understand where languages fit and use them as intended by the language author. And understand that languages can be used to express different concepts to different audiences.
To illustrate these points I will talk about some time I spent a few months back at the DMZ (Data Modeling Zone) conference in Baltimore, MD. This is a conference targeted at analysts, specifically data analysts, and is very relevant to many of the Need Powered Change community. Much of the material below is directed towards more experienced analysts, but feel free to push on even if you are a beginner!
I attended a session led by the excellent Michael Blaha, someone whose published material I highly recommend (to a data modeling audience – see bottom of article). Michael was describing the benefits of using UML as a rich, business friendly notation to help elicit business data requirements, and explained UML to “diehard” data modelers very well indeed. One of the reasons I respect Michael’s work, especially over that of many / most of his peers, is that he does not misapply the UML constructs when data modeling. For example, others advocate role names to describe associations. <rant>This drives me crazy and confuses everyone. No “homemade” stereotypes either, except color (maybe). <end of rant>).
Anyway, we were shown how to use UML for conceptual and logical data models, with sound advice to consider moving to a dedicated database modeling tool when producing physical data models. This, it was said, means re-keying the data model, and “hard work” to keep the physical data model consistent with the upstream data models.
This started me thinking. If you need models, exactly what type of conceptual or logical data model would you want to model with UML? A data warehouse data model perhaps? Yes, I think so. High level enterprise data models? Again yes. But what about data models for transactional systems (the systems that do the work of the business, such as accounting, order management, and shipping)? Would we want to model their data with UML (especially as there are probably already UML models that show behavior and data for the developers i.e. class models)?  And when do we start physical data modeling – what is the transition point from conceptual to logical to physical?
To answer this we need to identify what conceptual, logical and physical data models are. Then their purpose becomes clear as well as when they are created. Here are my current thoughts:
Conceptual models of any kind are used when you are eliciting business strategy. They show the key subject areas in which an organization operates, and are likely to be static while an organization does not change its product and service offerings.
Logical models are used to show a relevant representation of the real world for a particular solution.
They may be described as “implementation neutral”, in that they contain no “implementation details”. The idea is that the logical model represents needs, not how the needs will be met by technology. In fact a logical model can ideally be implemented on any applicable technology, and applies to any type of need (transactional, reporting, analysis and so on).
Physical models show how technology will be used to implement the logical models. There should be bidirectional traceability between logical and physical models if both are to be maintained. However, a logical model may naturally evolve in to a physical model, and the logical model may be “lost” in the process. Therefore, all models must be versioned, with each version annotated with descriptions.
A really simple way to see the difference between conceptual, logical and physical models is that you need business knowledge (only) to produce conceptual and logical models. Physical models require technical knowledge.
Conceptual, logical and physical models can be produced for data and functional (class) models. Modeling artifacts must be traceable between logical and physical data models and also between logical (interface or API) and physical (implementation) functional models. Ideally (although it’s probably not possible) traceability should come from forward and reverse engineering between these models, but practically it’s probably through evolution, versioning, and hard work that this trail is maintained – again, if you really need to. Physical models and their associated implementations can be / should be forward and reverse engineered too.
All models of every type (where type is conceptual, logical and physical) must be consistent with each other (so that a logical functional model maps to a logical data model etc.)
So, any of the models can be produced in UML (well, physical models only at a pinch, and only in some tools). An essential point is that a UML logical data model is NOT the same as a functional UML (class) model used by developers. Also, not all of the models are required on all projects – it just depends on what you need.
That represents my current thinking. What do you think? Create a comment!