Skip to main content

Tag: Career

Business Analysis: Sharing Your Knowledge: Why and How

Often, through their normal daily work the business analyst learns new knowledge about systems, business processes or the organization as a whole. In doing business analysis tasks on a daily basis, a business analyst investigates systems; whether through documentation analysis, interface analysis or interviews with system users or subject matter experts (SME), they learn how systems operate and how the business uses the system(s). Business Analysts are often called upon to document business processes, so they investigate those business processes through interviews or surveys of those involved in the process. Through Situation Analysis, Capability Gap Analysis, Feasibility Studies, SWOT Analysis, Market Research or Organizational Change Readiness assessment to implement a new project solution the business analyst learns about their organization and the business environment in which it operates.

All too often what happens when the business analyst leaves the team or organization is all that learned, and now tacit, knowledge leaves with them. Then comes the unpalatable task of replacing the business analyst and bringing the new person up to speed with the team. What can never be regained is that knowledge that left with the previous business analyst. Wouldn’t it be great to keep that tacit knowledge?

As the exiting business analyst how can you leave that knowledge with the team as you move on to other opportunities, especially when those opportunities are outside the organization? Do you want to spend the last two weeks on the team trying to hurriedly document all your tacit knowledge? Where do you store it; in what format? Let’s look at a better way.

An Internal Body of Knowledge

An internal Business Analysis Body of Knowledge is a centralized, electronic knowledge repository from which the entire business analysis team may draw knowledge. Centralized to one business analysis team or across the organization; who is this knowledge base to serve. Once you determine who your customers are, you can determine where to store this knowledge base to be centralized; and you can consider such things as security and access. You can determine if this should be stored on a shared network drive, SharePoint or another document repository.

Start from the beginning

Don’t wait until your final week or two in this role to try to leave all your knowledge with your co-workers. Start from your first weeks on the job. As you investigate and learn these systems, business processes and the organization start documenting what you learn about things. It is very difficult to document years of knowledge in your final week(s) on the team; so start soon after you join the team. Document as you learn. This also helps to ensure that important items don’t get forgotten.

Start Small and Grow

Egypt wasn’t built in a day, so don’t feel that you have to build an entire knowledge base in a week. If you start soon after you join the team then you won’t be rushed to build your internal body of knowledge in a week or two. You can build it over years of learning. Start from the first system or business process that you investigate. Document one system or business process and store that in your centralized place. There is your start. Add each system, business process or piece of organizational knowledge you learn while you are in this role and watch your body of knowledge grow. As the knowledge repository grows, you build the structure of the repository.

Start Yourself

You can bring the idea of a centralized knowledge base to your team and try to get buy-in; or you can just start yourself. You may have to determine what the team or corporate culture is to determine if you ask for permission or beg for forgiveness. As a consultant, it is my ‘value-add’ that I provide my clients. I build my internal body of knowledge and as I leave the team I show the team the knowledge I am leaving them.

Invite Others to Join In

Once you have the knowledge base started and others can see the value, invite them to add their knowledge to yours. This can grow the knowledge exponentially. Obtaining their buy-in is much easier when you can show them the value.

Get Started

So now you know what an internal business analysis body of knowledge is and have a concept of how to build one…get started. Determine who you wish the knowledge base to serve, determine where to store it and get started building it.

By building an internal business analysis body of knowledge for a team or organization that you will eventually leave; face it we all leave at some point whether by choice, retirement or other forces, you can leave behind business, systems and tacit knowledge you have built up over time. The great advantage of starting early is that you don’t have to hurry up, remember everything and build it all in a short timespan as you prepare to leave the team. For a consultant leaving a team, this is a great ‘value-add’ to provide for your clients.

Don’t forget to leave your comments below.

Business Analysis is Not a 9 to 5 Job

If you want to excel in your role, you can’t work 9-5 with an hour lunch and two 15 minute breaks. When business analysis is all or part of your job you don’t clock in and out. You can’t stop thinking about things when you are not at work. Many people are attracted to business analysis because there is an element of art and science. It is the art that makes your role nothing close to a 9-5 job.

Being an artist means being creative. You need creativity to figure out how to engage the necessary people to accomplish your team’s goals.  You don’t work with robots, so every project, every week, every day your team members have different attitudes and different motivation. That means you consistently have to adjust how you interact with them. You and your team has to be creative to take an idea and break it down enough, just to build it back up into a solution.  This creativity does not happen in a one hour meeting.  You need to have meetings where creativity is happening, and then give yourself and others time to think.  You have been in those meetings where people can’t make decisions or just don’t feel great about the results.  This is when you have to step away and give yourself and others time to reflect.  So when does this reflection happen?  You are in meetings all day or have other tasks that fill your plate, right?  Your thinking has to come while walking from one meeting to the next, it has to come during lunch, during your ride to work and home, and while you are getting ready for work.    When I entered in the BA space I realized this and started keeping notepads all over my house and in my briefcase.  When you start thinking outside of the 9-5 window ideas hit you when they hit you. (The idea for this blog hit me while I was online waiting to go into a Bruce Springsteen concert!) They don’t wait until you are at your desk.  You need to have a system for capturing these ideas so you don’t forget.  Allow others to share ideas with you outside of the prescribed meeting times to talk about the subject. To be successful you need to be creative and you need to spark creativity. When you have a complex scenario and need a decision, don’t wait until the last minute to get the team together to come up with ideas. When pushed for time creativity subsides and people go back to doing what they know. Know when decisions need to be made and work backwards to ensure enough time is given to maximize creativity.

In addition, part of your professional development has to come outside of the 9-5 timeslot as well.  Like an artist you are paid for results.  My kids are in a band.  No one pays them to practice.  Does an author get paid for a first draft or do they get paid to do the research to write a book?  You get paid for results and expected to deliver at a high-level.  Yes, your employer most likely pays for some training and development and gives you time during the work day.  This is most likely not enough. You also need to invest time in your development.  That means using lunch time, evenings or weekends. You can meet with a mentor, attend a webinar, and go to an IIBA or other professional organization meeting.  Instead of reading a novel before bed, pick up a Business Analysis related book.  While drinking your coffee in the morning connect with and learn from others on Twitter, Facebook, and LinkedIn. Read a blog or download a whitepaper. Get in the habit of continuous learning.  Keeping your mind fit is the same as your body.  You don’t go to the gym for a week once a year to stay healthy.  You go 3, 4, or 5 times a week for 30-60 minutes.  The same applies for your professional development.  Do something every day.  

There is a need for balance. You have to rest your mind. You can’t always be thinking about your job and how to improve. I’m not talking about dedicating yourself fully, 24 hours a day, 7 days a week. At the same time you can’t just think about work or focus on your development between 9 and 5. You should always have an open mind. When you have conversations with your friends, something they say can give you an idea on how to improve your work. While watching TV or a movie something may spark an idea for your project. Your work is not something that is on or off. When it is not your main focus it still needs to be running in the background.

All the best,
Kupe

Don’t forget to leave your comments below.

Data Migration – The Journey of a Thousand Miles

You’ve held workshops, you’ve consulted your stakeholders, you’ve written requirements, you’ve produced use cases, you’ve collaboratively designed the UI and everyone is happy. And then seemingly out of nowhere you find that the data from the old system refuses to fit neatly into your new system. Suddenly the project that has been going so well is plunged into chaos.

How the heck did it happen?

Data migration is typically the most overlooked component of a project that involves moving from an old system to a new system. (Note: I’m using the generic term system to cover everything from applications to websites.) While there can be many people involved in discovering the new business requirements or in designing a new UI, the data migration task itself tends to be either forgotten about or delegated to one person (typically a more junior member of the team). On the surface data migration appears to be one of the easier tasks to complete. After all it’s just transferring the data from one system to another. This perceived simplicity leads many project managers (and sometimes the business analyst) to think that data migration can be separated from the main body of tasks needed to deliver the system. Even the BABOK talks vaguely about this area in section 7.4 Define Transition Requirements. The task of data migration isn’t specifically mentioned. It’s framed as, “move information between the new and old solution” or in the case of the data itself, “Rules for conversion of this information will need to be developed, and business rules may need to be defined to ensure that the new solution interprets the converted data correctly.”

This impression that the task is small in scale typically leads to scheduling the data migration near the end of the project rather than at the beginning. Unfortunately, leaving the migration analysis until later or not understanding the full implications can have fairly devastating results. The project can wind up running late and the budget is blown. Even worse, the new system starts with bad data from the old system or no data at all. If a decision is made not to move the data to ensure the delivery date doesn’t shift then the data ends up split between two systems. The old system needs to keep going for longer than intended and costs balloon as two systems are maintained to do the same job.

Data migration typically goes wrong because of a misunderstanding of what it means to collect data. If you reduce a computer system to its most basic components a computer is merely a way to collect data, store data, perform an operation on the data, get a result from the data and then use that result to generate an outcome or more data. For example, in a billing system you collect data (the name of the person being provided with a service, the contact details for the person and the service the person is being billed for), you perform an operation on it (calculating if the person owes any money for the billing period) and then you generate an outcome and/or more data (you send a bill to the person and then receive a payment from the person or the person is still in debt).

How that data is collected and stored in the old system and how it’s collected and stored in the new system determines whether your data migration will be straight forward or difficult. In data warehousing the process of moving data from a source system to a target system is known as ETL (Extract, Transform, Load).

The key to understanding the difficulties you may experience with data migration is the ‘transform’ part of ETL. It’s highly unlikely that you are going to move from your old system to a new system and not have to transform your data in some way. For example, a typical problem is that the old system may store the address details in one field. The values are comma separated. This means the street number, street name, suburb and city values are contained in one field. However the new system now has a separate field for each of these values. You now have to figure out how to move the values that are sitting in one single field in your old system to the new system with multiple fields. If you’re very lucky the users have consistently separated each value in the field with a comma. If you’re unlucky then there haven’t been any rules. Or you have several users who have made up their own rules – instead of separating each element with a comma they have separated each element with a pipe (|).

To the inexperienced and non-technical project members on the team this type of problem can seem to be a mere annoyance and Project Managers can sometimes dismiss this as a technical person over stating their case.
However even the smallest data problem can start to quickly add costs and require the business to make some tough choices. For example, if the business wants to solve the address value problem and move the values to the new system correctly then this would require someone to write an ETL script to transform that data. And before the script can be run the data is going to have to be analyzed and cleaned to ensure that the ETL can execute without failure. If there are thousands of records (or millions) then cleaning the data to be consistent enough to transform and load to the new system may require hiring temporary personnel to manually correct the records depending on the state of the data. For example, if the address values have been entered in an unstructured manner and no transform rules can be applied then it can only be corrected using human intervention and judgement.

The seemingly minor technical issue of transferring data suddenly becomes a costly and time consuming task requiring temp workers and a developer to write the ETL scripts. Faced with rising costs and having to extend the completion date for delivery the business can start to panic and the subsequent decisions can result in the data in the new system being poorly structured before it goes live. For example, the offending values are simply moved en masse into a comment field in the new system with the intent that the users will correct the problem during their normal working day.

Other issues with the data result in the entire process being deemed, “too hard” and only the data that can be transferred on a one-to-one basis is moved. For example, only a person’s first name, middle name, last name, gender and date of birth go into the new system. Everything else is archived. Archiving data is perfectly fine if you never have to look at the data again. However this will be highly unlikely and having to search between two systems creates a less than optimal user experience.

Data migration tends to have five consistent factors that contribute to issues during delivery of a project.

  1. The person responsible for performing the gap analysis may not have a data background or has ignored the significance of redesigning the business processes in terms of data collection and storage.
  2. The data migration itself is left to the last minute and is assigned to a different business analyst or a tester. They are typically isolated from the business because the migration is seen as separate technical task. The task might also be assigned to the least experienced member of the team such as a junior business analyst.
  3. The business has decided not to collect certain types of data any more or they are unsure as to why they collected the data in the first place. The initial analysis fails to identify the other units or departments in the organization that may still have a use for the data.
  4. The migration takes far longer than anticipated. A data migration can turn into a considerable intellectual challenge that requires months of analysis. This is especially true for payroll projects that have to migrate an organization’s entire employee history including leave, over time, allowances and pay rates.
  5. No one has factored in the defect rate for the migration. Even successful migrations can have a small defect rate that needs to be addressed once the records are moved. Knowing whether the migration has to be started again or whether the defect can be manually corrected can make all the difference between a delay of days, weeks or months. It’s very rare for a data migration to achieve 100% perfection when moving data from one system to another. You should always allow additional time to review and clean data in the new system if it’s needed.

Considering all of the above points, are data migration issues solvable? The key is to start as early as possible, and make sure you consult with your development team.

Your first step is to talk to your Data Warehouse team or find a developer who knows ETL.

Depending on the complexity of your data migration you’re going to need help. You need to get that help from someone who knows ETL.

You should also have a clear understanding of what it means to Extract, Transform and Load.

Your second step is to construct a data model for both systems.

What does your current system do? With any luck there is already an existing model. What does your new system do? With any luck someone has already completed a data model in your team.

If you don’t have a model for one system (or it’s missing for both systems) then you need to construct one. It’s the only way you can compare the state of the data in both systems and check for gaps.

Your third step is to identify odd fields or problems with the way the data is stored.

When you look at your model do you have a one-to-one match between both systems? Or are there strangely labelled fields that seem to make no sense? Is it as per the example at the start of the article – you have values concatenated into a single field that must be split into separate fields in the new system?

Depending on how rushed your developers or vendors were when they developed the old system they may have cut some corners in terms of how fields were named ‘under the hood’. I recently reviewed a system that had their date fields labelled, “Date1”, “Date2”, “Date3” and “Date4”. The UI had date fields on different pages that had slightly different meanings (one was a create date, one was a modify date, one was a delete date and one was a create date for a separate record). However, when these dates were stored into fields in the database they didn’t have any context. For example, is “Date1” the date the record was updated or the date the record was created?

You need to have a good understanding of what each field means before you can decide how (or if) you can move the data to the new system.

Your fourth step is to look at the specifications for the new system.

If you can’t get a data model for the new system because it’s still being designed see if you can spot any obvious problems from the specification (if the project has one).

Look for things that everyone will have presumed is covered off but wasn’t. Is data missing? Is the cardinality (the relationship between the data) incorrect?

Any or all of these things could indicate that you need to re-do the gap analysis or begin a new gap analysis.

Your fifth step is to find all the consumers of the data.

Other units or business areas in your organization may consume the data. You need to find all the consumers of this data because even if the business no longer wants to collect the data the data may be very important to other areas.

For better or for worse someone asked for the data. It’s entirely possible that it was simply added for one particular person’s reporting needs at the time. However, you need to dig these facts out and make sure that if the decision is to ignore the data going forward, it won’t result in problems later on.

This seems another obvious step but can be accidentally lost if the new system is complex or there are many people involved in the project.

Your sixth step is to check your findings with the business.

After your research is completed you should be able to explain any anomalies with the business but more importantly you should identity the possible outcomes of any migration problems. Typically the lack of data in the new system may interfere with the user’s ability to complete their tasks. The business may not have been aware of this problem when specifying the requirements for the new system.

Conclusion

You should be prepared for your data migration to be more difficult than originally assessed and to be forced to make decisions in which the outcome is not always ideal. You should be prepared for the business to misunderstand the implications of what they’ve asked for or when they do understand they become overwhelmed by the decisions that need to be made.

Project pressures may result in solutions that are not only less than ideal, they also create problems from a BAU (Business as Usual) perspective.

Attempting your data migration too late in a project may mean that your journey doesn’t even begin.

A successful project will realize they must start their data migration analysis as soon as possible and use experienced analysts to give themselves any chance of completing a successful transition to a new system.

Don’t forget to leave your comments below.

Passing the Bad Ass BA Baton

In 2009 I started writing the Bad Ass BA articles (2009-2012) as a way to channel my frustration at work. With all the interesting problems and all the intelligent professionals, my impatience with mediocrity drove me to speak out about what we could better. I should say, speak out and act out; writing the Bad Ass BA articles was simply a chronicle of my constructively disruptive, actively resistant activities at work. Each article ended with short bio line about my professional passion, “ … to educate technical and business teams about the role of the business analyst, empower the business analysts themselves with tools, methods, strategies and confidence.” There’s no bad assery in that statement, in fact, as I re-read it now, I wonder, so what’s the big deal?

The big deal is how the passion manifests. It is one thing to recognize mediocrity and not be satisfied, it is another to speak truth to power, hold people accountable for their responsibilities and do the heavy lifting to generate alternatives. And it isn’t enough to do this by yourself. The big deal is getting other people involved to help, to do their work differently, to not be afraid to do what needs to be done. The big deal is, to manifest your core BA-ness, your agent of change-ness, and make the world a better place – you have to take a risk.

I haven’t been able to write Bad Ass BA columns for a couple of years primarily due to health. Discovering in middle age that one is allergic to gluten, soy and, because I’m lucky, dairy too, stands your life on its ear. I’m getting better but I need to focus on other things before I can write regularly again. At the 2013 Building Business Capability Conference, Adam Kahn, introduced me to a fellow badass – Bob Prentiss. You may know him as Bob-the-BA, teacher of hundreds of proud CBAPs, and bring-down-the-house conference speaker. What you need to know is, a mutual friend, gave both Bob and me our start speaking at regional conferences back in ancient history. I had been feeling guilty that I wasn’t doing anything with the Bad Ass BA platform, and now here was someone who had a burning flame in his heart to do what I could not. The “Bad Ass BA” moniker needed a new home. 

Over the past few months, Bob and I have been comparing notes on why it is important to us to be a Bad Ass BA. Bob says it beautifully, “give a name to cause, create a purpose in life, give opportunities to people who aren’t quite ready to seize it for themselves”. And what does a bad ass do? “Challenge for the right reasons, call bullshit on entitlement, question doing it because we’ve always done that way, get people to focus on the facts and the objective, set aside their fear-uncertainty and doubt (FUD).” Standing up to mediocrity means taking on risk, and that’s a scary thing to do if you’re a professional person who might be supporting a mortgage and a family. No one wants to find themself suddenly out of a job. Even so, for both Bob and me, because of who we are and how our brains are wired, the drive to make things better is so strong that we will speak out and act out. Bob and I were lime and tequila as we talked about the importance of knowing yourself, being aware of what makes you willing to explore the opportunities for a company, being willing to go where others fear to tread, being conscious of taking calculated risk, being willing and able to take on the big challenge and being determined to get people to walk along side with you. Time to pass the Bad Ass BA “baton”.

So, what is Bob going to do with the badass baton? Bob will be writing, blogging and presenting at conferences, small slices of big truths that represent the characteristics of a Bad Ass BA, and the journey that one can take on their way to becoming one. His message is for all levels of business analysis professionals; “find a better way” applies no matter how many years of experience you have. It is about the journey you take, the skills you acquire, and what you do with them along the way to make a difference. If you are a bad ass wanna-be you’ll find guidance and inspiration. If you are a bad ass already, and ready to take it to the next level, you’ll find validation and encouragement. If you are a kick butt consulting bad ass, you’ll have a reference to give others that will make you look even more brilliant.

Cecilie hopes to be back to writing soon with stories of making a difference in the realm of business analysis and business architecture. Meanwhile it is time to pour gasoline on the fire and give a fireproof cape to Bob Prentiss.

Bob: “Thank you Cecilie! So was I the lime or the tequila? I often think I am the lime, that sour, and sometimes bitter taste that compliments the salt, savory, and sweet. When these ingredients are left on their own, they are disconnected and lack harmony, but when combined together, complete the ingredients for that perfect margarita. One of my favorite Chinese proverbs actually explains my badass BA approach to life: “Eat bitter, taste sweet.” It is a road less traveled for the badass BA; a road of challenge, resiliency, adaptability, and a tenacious drive to make things better. We eat the bitter, taste the sour, we fight resistance, we speak truths, we influence and influence again, and we eventually add the salt, sweet and savory to push projects and organizations in the right direction for the right reasons. As I take up the baton of the bad ass BA from Cecilie’s very capable bad ass hands, I look to share the bitter and sour, share my experiences, failures and successes to help you on your journey to bad ass extraordinaire and of course, your perfect margarita! “

Bob and Cecilie send a beer and a chocolate-covered “thank you” to Adam Kahn.

Don’t forget to leave your comments below.

About the Authors

Cecilie Hoffman is a Business Architect / Analyst working for a Fortune 100 company in the San Francisco Bay area. Her professional passion is to educate technical and business teams about the power and value of the business analyst role, and empower business analysts themselves with tools, methods, strategies and confidence. Cecilie is a founding member of the IIBA Bay Area (formerly Silicon Valley) chapter. LinkedIn Profile: http://linkedin.com/in/ceciliehoffman

Bob the BA provides badass business analysis training, consulting and mentoring services. Bob is passionate about helping you learn differently; so that you can learn new things faster, and put into practice immediately. Bob is CBAP® certified with 25+ years of experience in corporate America; with a background in managing BA centers of excellence, assessing and managing BA maturity, quality, and competency. Bob is the developer of the PMI® 2011 Product of the Year – Project R.E.A.L. (Real Experience; Applied Learning). Bob has presented numerous keynote, workshops, seminars, conferences, and training sessions across North America. Bob is a founding member and past President of the IIBA® MSP Chapter.

The Road to Being a Business Champion is to Train Like an Olympian

Have you ever admired the strength, flexibility and endurance of an Olympic Athlete? It takes a lot of dedication to become a successful athlete. Olympians are at the apex of perfection. The fact that they get to go to the games is amazing, but to win makes them champions. There are secrets in training and preparations that Olympic Athletes have that increase their potential for success. As business leaders we can learn a lot from Olympic Athletes to help us become business champions.

Here are a few tips from the best of the best:

Have a Plan: It is amazing how many business leaders do not have a plan–they just wing it. The reality of being a top athlete is that you must have a plan. From diet, to workouts, to rest, there is a plan of focused intent. Know what it is you want to accomplish and why it is so important. Have a strategic road map for your business success.

Create a Routine: A routine is everything. It is part of your plan. Routines require an emphasis on high value activities. Focus on those things that will make a difference to you and your business. Schedule them in and make sure you do them.

Take Care of Yourself: Top performers usually have off-the-chart energy. How do they manage this? They take care of themselves through a healthy dose of proper eating and rest. Even the greatest boxer who ever lived, Mohammed Ali, ate well and rested. He took one day off a week to relax and ease his body and mind.

Proper warm-up and recovery: If you are going to work hard then you need to ensure you have proper warm up and recovery. This includes creating a natural rhythm to your business, as well as building in agility and flexibility. This is something that should be part of any good business practice. You and your people need to ensure they take the time needed to remain limber and prepared.

It’s all in the Head: Mental preparation is all about psychologically preparing for the big events. It is easy to get psyched out and think you or your people are not good enough. You need to tell yourself and your team they are the best at what they do. Create mindful rehearsals, read inspirational books, or count your blessings daily. Whatever it takes to build the mindset of a champion.

Consider a Trainer and Coach: Great athletes have coaches–we all know this. Business leaders who want to mix it up know they need help. From motivation to accountability, a coach can make a difference.
Be dynamic on your business: You can’t just focus on one thing in your business. You need to consider all the moving parts and train yourself in those parts. Olympic Athletes switch things up using fixed to variable equipment; they run, jump, throw, row, and do a lot more. The key, they mix things up.

Engage your People: Olympians have a team of engaged people who are rooting for them. It includes many key stakeholders including family and friends, sponsors and vendors, managers, coaches, trainers and peers. Engaging your team is important for your business as well. It is important you find a way to connect your people to what it is you want to accomplish. Engage the people that are in your corner.

Prepare for Heavy Lifting: All champions need to build their strength and endurance. Find ways to build your ability to deal with the events that are the heavy lifting of your business success. Build core competencies in yourself and those around you. Part of an Olympic Athlete’s heavy lifting ability is having a strong, engaged core. The same is true in business: businesses without a strong core tend to have more challenges. . Make sure you have engaged your core.

Train Early in the Day: Common wisdom says to train early in the day. Most Olympic Athletes do. Create an early ritual of getting focused, reviewing your strategic plan and the work plans that you have laid out. Focus on building up skills that will take you to where you need to go.

Build your Training Team: A dedicated team is everything for a Champion. You must have a team that will not only work with you, but also train with you. Olympic athletes are known to train together for years before they turn to competing against each other. Therefore, a training team can include your peers, your team and your competitors. Olympians train with their competition so they get better.

In business we ultimately want to be the best at what we do—we want to become champions. One of the best places to look for inspiration is at our Olympic Champions and the hard work and dedication they put into being the best at what they do. Like them, the first step to becoming the best is to think and act like a champion.

Don’t forget to leave your comments below.