A new article showed up the other day on our organization’s internal wiki. The topic was ‘The Role of a Business Analyst (BA) in an Agile project’. The content of the article is just starting to be developed, so I took it as an opportunity to add a comment in the form of a question on “the role of a BA in the management of our information as an asset”. My goal was to generate some discussion around this idea, to see what others in the organization are doing/thinking, and to start the process to perhaps develop some formalized responsibilities in this area.
No sooner had I hit the save button when BAM, there was a response that showed interest in the topic and asked me to elaborate! Exactly the response I was hoping for! Muwah ha ha! You probably should know that the person who responded is a very good friend of mine who is quite comfortable with social collaboration and if it wasn’t for her I probably would be having a discussion with myself…ok it’s not really that bad but why is it that some colleagues have no problem updating their facebook status daily but when it comes to collaborating in a wiki they are running for the hills?? Sigh…subject for another day…
So what is the role of a BA in the management of our information as an asset? A lot may depend on how your organization is organized, what the culture is, what types of resources you have ( maybe you have BA’s solely responsible for information management) and how mature your IM (information management) practices are. But let’s say for the sake of this opinion that you have a somewhat immature organization from an IM perspective, and you are just starting to organize Data Governance and MDM initiatives. This could mean that you are just starting to develop governing principles and operating policies around IM, and you may not yet have them ‘baked in’ to how you manage and deploy projects. Since some resources within an organization may not be familiar with some of the concepts, my approach will be to describe some of the key outcomes that result from not-so-good information management practices, and how a BA might help to resolve them, or ensure they don’t happen to begin with.
Multiple sources, conflicting rules and differing business uses of information
In order to resolve these types of issues you need to link the data to business objectives. This is standard stuff that I don’t often see. I’m not talking “here’s the data I need for this report”. That is not a business objective. The objective should describe the business decisions or triggers or changes that are the intended result. e.g. This piece of information is used to determine what type of industry our customer is in so that we may ensure that the best person is assigned to them to help them with their needs. When the business objective is clearly linked to the data, it helps IT resources determine how to best architect the data, and business leaders with the information that they really need. It also helps in the resolution of conflicting rules. E.g. while one unit may use the information to identify the appropriate account manager, another business unit may use the information to identify the total amount of risk they have in that industry so that they can ensure they follow regulatory rules. You cannot resolve conflicting rules without having a good understanding of what the information is used for.
Lack of common understanding of what the data means
Ensuring the data has a clear and easy to understand definition and communicating it broadly reduces errors when data is created, transformed and reported on. Eg. ‘Address’: describes the street location where the company physically resides. Although it looks somewhat self-explanatory, unless it’s clear and understood, what usually happens is you get all kinds of addresses: the mailing address, an email address [I kid you not], a city, etc.. You cannot assume that everyone has the same understanding of what a piece of data means.
There is a problem with the data but no-one seems to care
Identifying who will be responsible for business decisions on the data (and describing what that responsibility is) will ensure you don’t waste time when something needs to be resolved. This need not be a steward of the data as the organization may not be set up that way, but it could be a person or a role, and it should be written into the requirements that there is someone somewhere responsible for making business decision. E.g. The person (or role) responsible for making decisions regarding this data is XXXX. You may find that you are having difficulties getting someone to actually agree to having their name or role written down and being responsible. If this happens, don’t give them the data. Simple as that. No name, no game!
The data is in a mess (still….) and needs to be cleaned up!
Cleaned up to what? Including quality attributes as part of business requirements ensures that everyone understands how good the data needs to be and allows you to better manage keeping it that way. E.g. The address information must be updated at least one per year to ensure freshness. It cannot contain phrases such as ‘unknown’ and special characters are not allowed. Using the quality requirements allow you to either perform an analysis of the data to understand how bad (or good) it is, and you can also provide the business with a weekly, monthly or yearly report on the quality, so that they can determine if it still meets their needs.
Here’s the summary of my opinion on how a BA can help in the management of our information as an asset
- Link the data to business objectives
- Ensure the data has a clear and easy to understand definition
- Identify who (or what role) is responsible for business decisions regarding the data
- Identify quality requirements for the data
This is by no means a comprehensive list, but it does go a long way to helping manage information as an asset. And it’s easy peasy stuff! The hard part…ahhh…the hard part. Try telling someone a report is not really a goal and see what happens. Not really a good approach. The best way to go about it? Keep your rule/definition/goals antenna on at all times. Although it may seem hard to extract this information in a formal setting, most business stakeholders talk about this stuff all the time. In fact, that’s all they talk about! We just need to be really good at hearing it!
The role of a Business Analyst in an Agile Project while taking Information Management best practices into consideration (whew!)? That is a story that I hope we are beginning to work on!