News

Are you wearing a Business Analysis Hat?

Are you wearing a Business Analysis Hat?

Business Analysis Hat
Business Analysis Hat

Are you wearing a “Business Analysis Hat”? You may still find yourself performing Business Analyst activities even when it is not your job title.

For a great deal of my career my job title has been “Something… Analyst”.  I have found myself performing analyst activities even when “Analyst” has not been mentioned in the job description. Lots of people tell me they have had similar experiences.

Rigid demarcation or flexible roles?

Some organisations have rigid demarcation between roles. In these organisations just reading someone’s job title tells you what they do: Business Analyst, Project Manager, Developer etc.

In smaller, less structured organisations, everybody “mucks in” to do the work.

Even in the more rigid situation, Analysis is an activity overlaps with others. Analysis clarifies what needs to be done. Business Analysis is not so much a question of who is doing it, as what they are doing and what tools they are using. Anyone can find themselves wearing a Business Analysis Hat!

What kind of Business Analysis?

One of the classic metaphors used for Business Analysis is a bridge connecting “Business” and “Information Technology”.  Business Analysts use metaphor a lot. We spend a lot of time saying:

  • “This is a bit like that”, or
  • “This represents that”

When we do this we are trying to “facilitate” communication between the two sides of the bridge and helping each side understand what effect they are having on the other side. “Facilitate” is one of the buzz-words you may hear a lot!

Business Analysis Bridge
Business Analysis Bridge

This facilitation role has several aspects, which are not mutually exclusive. Some of the activities I have seen are:

  • Managing “Requirements” – Put what “The Business” asks for into a formal structure. These “Requirements” are used by “Information Technology”. “The Business” understands the solution in terms of these requirements.
  • Encapsulating IT – Summarise the complexity of “Information Technology” so “The Business” can make informed decisions.
  • Working with Numbers – Use IT tools to understand aspects of “The Business” and present those insights to the business.

What kind of tools will you use?

Analysts use “soft skills” and “documentation skills” but they also make extensive use of “models”. You will hear mention of:

  • Process Models
  • Data Models
  • Use Case Models
  • and several more.

Understanding what the different types of model can give you and choosing the appropriate model for you situation can make communication more effective. I plan to explain some of the different models and notations in later blog posts.

Conclusion

Business Analysis facilitates communication between The Business and Information Technology. Analysis clarifies what needs to be done. Almost anyone can find themselves “wearing the Business Analysis hat”!

Communication is not only in one direction. Analysis uses many kinds of model and using the model which is appropriate for the situation can make communication more effective.

Working Procedures: Criticism and Objections

Working Procedures: Criticism and Objections

Working Procedures: Dealing with the Dark Side of Procedures
The Dark Side of Procedures

Last time I told you that I use Working Procedures to manage some of the processes in my business. In that post I touched on one objection to the approach, but there are others which I intend to address.

Common objections to using Working Procedures, and my responses

Here are the objections that were raised when I started using Working Procedures. I phrased some of them as rhetorical questions, and some were even raised by me!

  • I don’t have time to write it down – I mentioned this last time, but I’ll deal with it at more length here. This was one of my objections. I’ve found that I do have time. This morning I encountered a task which I only do once a year. I couldn’t remember the details. This time I wrote down what I needed to do as I did it and turned it into a procedure. The very act of writing it down reminded me of something I had overlooked. Job done!
  • You can’t think of all the procedures in advance –No you can’t and I don’t think you should try. I prefer to create the first version of the procedure when I need it.
  • You can’t think of all the exceptions in advance – Agreed! Instead regard the procedures as work-in-progress. Each time you use a procedure, you test it! If you encounter a problem, then look on that as an opportunity to improve the procedure. You are going to solve the problem, why not record the solution at the same time.
  • I don’t want to be “ordering people around” – And neither do I! I want to get things done. Sam Carpenter insists that the procedures should be developed “bottom up” rather than “top down”. That way they contain what “the user” needs, rather than what someone else thinks they need.
  • Won’t they get out of date? They won’t if you keep on using them, regard the use as a test and make updates as required. Of course, you need to have some sort of approval and change-control but that needn’t be onerous.
  • Won’t the maintenance effort become a burden? I haven’t found it so. I use a mixture of a wiki and a tool called BDS (Business Documentation Software) that Sam Carpenter promotes.  I’ve included a snap-shot of one of my procedures from BDS. I’m sure that having the procedures in more than one place violates some rule or another, but it works for me!
Working Procedures: An example procedure in BDS
Example procedure from BDS

Conclusion

Creating and maintaining written procedures has a cost, but I believe the benefits far outweigh that cost. Also, there are some things which you might call “objections in principle”. The secret is to think about what the objections tell us and manage what we do so that we use Working Procedures more effectively and actually gain more.

Working Procedures: Benefits of doing things consistently

Working Procedures: Benefits of doing things consistently

Working Procedure Diagram
Working Procedure Diagram

I’ve been busy. One of the things which got me through the busy period was that I have “Working Procedures” for some of the boring but important tasks I have to do. Having these things documented made it much easier for me to delegate them or simply tell myself to get on and do them.

“Busy-ness” can come about for all sorts of reasons, including distractions and interruptions from the outside world and higher priority project work. In my case it was a mixture of all of these and a few more too!

I’ve always been keen on writing things down, but I sometime last year I discovered the work of Sam Carpenter and his “Work the System”.  At first I thought “Work the System” meant taking advantage of the way things worked and “cheating” in some way. That was wrong. Sam’s point is that it is easy to spend one’s time in “crisis management” or as Sam puts it – “fire killing”. . Instead, Sam proposes that we invest time in writing procedures or “maintaining the machines”. That way, over time, we will perform tasks more consistently and our performance will improve. Reading Sam’s book (and I have no connection with Sam Carpenter. I don’t expect he even knows I exist) convinced me that this was something worth trying. I tried it out and I think that it is helping me and my business be more consistent and make progressive improvements.

Working Procedures: Benefits

The benefits of using a working procedure are:

  • Nobody has to remember or research how to do the task.
  • The task is performed consistently. The way it is done this time is the same as the way it was done last time.
  • If a problem occurs, then the procedure documents what was being done (and the expected outcome)
  • The Working Procedure creates a framework for documenting the solution to a problem and therefore incrementally improving the procedure and the way we work.
  • The Working Procedure forms the basis for delegating performing the task.

Working Procedures: Candidates

I’m not that keen on maintenance and administration. I don’t think I’m alone in that either! I know maintenance and administration tasks are necessary but I used to make excuses, and put them off till tomorrow. The trouble with doing that is that a backlog builds up, especially when I’m busy. That backlog gives rise to anxiety which becomes a distraction, that’s not a good situation.

One of my Working Procedures is getting my website backed up. It isn’t difficult but it needs to be done. Now that I have it written down, I just do the procedure (or even better, give it to someone else!) and it gets done – consistently.

Working Procedures: Getting Started

Snapshot of "Website Backup" Working Procedure
Snapshot of “Website Backup” Working Procedure

I think I can hear someone saying “but I don’t have time to write the procedure”. Well, I think you do. All I did the first time was write down what I was going to do and then check off the items as I did them (and make some minor adjustments). When I was finished I saved the check-list. The next time I did a back-up I got out the procedure. The second time around it was quicker and easier, because I didn’t have to think too hard about what I had to do. The third and fourth times the task got progressively easier and what’s more, when I needed to make minor adjustments, I already had the framework for recording them.

Conclusion

There is almost no downside to this. Having Working Procedures, especially for the tasks which we want to avoid helps get them done. It worked for me. Trying out the approach doesn’t have to cost anything at all. If it works for you, you can do more of it. If it doesn’t work for you then you haven’t lost very much.

Learn to read SQL Databases

Do you know how to read SQL databases? By “read” I mean really get the most out of the database. If for some reason you were presented with an unfamiliar database containing a lot of tables, would you know what to do? If not, then you are not alone.

Many people: programmers, developers and analysts are taught the basics of SQL, they know how to write a SELECT query and can even use JOIN to write queries involving more than one table, but relatively few are shown how to read SQL and interpret the database structure itself. This is a pity, because the structure of a database is often very well documented. What is more, that documentation is incorporated into the database itself. That means that it is available and it is up to date. The problem is, most people don’t look at the database in that way. They concentrate on the content, rather than the structure. When they want to know which tables to look at, they tend to ask the local “expert”.

Asking the expert is a good thing to do, but it has a number of problems. The first and most serious problem is “how expert is the expert?” and the second is the problem that the expert may be busy.

I was prompted to think about this problem a little while ago when someone asked about “How to ‘dig in’ to a large database” on one of the forums I visit. I gave an answer which several people found helpful and which I documented here in my blog.

Over the intervening period I have refined the method I described and reduced it to something I call “DOGI”.

The DOGI method
The DOGI method
  • D = Diagram
  • O = Organise
  • G = Group
  • I = Inside

I like simple acronyms. They make things memorable and aid learning.

The approach I suggest to read SQL is really quite simple. It starts by getting an overview of the database by using whatever tool you have and then organising the diagram in order to make it easier to understand. This “organised” diagram makes it much easier to recognise groups of related tables which can then be investigated in more depth. This approach makes the investigation process more systematic and easier to plan.

I have created a course which teaches this method. I’ve structured it as what I term “an extended tutorial”. I start with one of Microsoft’s example databases and then use the method to investigate it. I surprised myself with how much information I was able to glean.

This course is suitable for anyone how can write a simple SELECT statement. By simple I mean “SELECT * FROM TableName”. When you have completed the course, you will have seen the DOGI method applied to one of Microsoft’s databases and will be able to repeat this yourself. More significantly, when you have completed this course you be able to use the DOGI method to “read SQL databases” and make yourself “the expert”. You won’t have to ask which tables you need to look at, because you will know. You will know what the tables are doing and you will be able to relate them to what the application can and cannot do.

I teach using a mixture of lectures and demonstrations. I think you will learn best if you repeat what demonstrate for yourself, but that is entirely optional. With each step you see the DOGI method applied in practice and build your knowledge using what you have learned already. On-line courses set you free to work at your own pace and to review and revisit material, even after you have completed the course.

If I’ve got your interest, then I’ve included links so you can purchase the course at a substantial discount. Go on, have a look now! It’s all supported by a 30 day, no-questions-asked, money-back guarantee too.

Read SQL like an Expert - 50% Off
SQL: Read a Database like an Expert – 50% Off

Enrol in Read SQL like and Expert

50% Off! $10

Reward: Make it worthwhile and memorable!

Reward Package
Give them a reward

When you have done the “close-down” and “lessons learned” things I suggested last month there are a few more activities which I think are really worth considering at the end of a project:

  • Punctuation – Make sure people realise that this is The End.
  • Say “Thank you” – You might be surprised how much people appreciate it.
  • Give small gifts or mementos for people to remember the project by.

These things can be done by management roles, but they can be done informally within a team as well.

What to give as a reward? A little more detail.

Sometimes projects just “peter out”. The last person to leave switches off the lights. I think it is better to have a final social occasion – a project meal or something similar.

Saying “Thank you” costs nothing more than a little effort. People appreciate it and if you work with the same people again they will remember that you appreciated what they did.

Small gifts can be a nice gesture. I have been given some strange things over the years, ranging from the technical (a couple of planes of core memory, and a disk platter), through the practical (some coasters and a set of cuff-links) to the rather strange (a curry cook-book!). All of these things bring back pleasant memories about the projects in question.

Why bother with a reward?

As well as being pleasant, these things serve practical purpose.

  • Bringing the project to an emotional close is a good thing. It is time to finish what are doing and move on to the next activity.
  • You may find yourself working with the same people in the future. This can happen years later, and you may be in quite different roles. Parting company on good terms means that it will be easier to start the new relationship with a good feeling.
  • I think it is good for your reputation to be thought of as being appreciative. This does not mean that you have to be soft. There is no contradiction between being a “hard task-master” and saying “thank you” in various ways.

Think of these activities as being a small speculative investment in the future.

Two words of caution:

  • Do not be seen to be doing these things in a manipulative way. People do not like that and it is generally counter-productive.
  • Do not say you are going to do something (like hold an “end of project meal”) and then not do it. That is demotivating.

Enjoy a break before starting again refreshed!