Skip to main content

Tag: Career

The PMI’s Professional Business Analyst Certification: Competition or Collaboration?

Written by Steve Blais on . Posted in Articles.

There is a new certification in town.* The Project Management Institute (PMI) has announced a certification for business analysts called the PMI Professional in Business Analysis (PMI-PBA)®. The reigning business analyst certification, at least in North America, is the Certified Business Analyst Professional (CBAP) from the International Institute of Business Analysis (IIBA). Does this set up a showdown at High Noon between the two organizations or perhaps the two certifications? Or is there some kind of collaboration between the two organizations? Can the business analysis world support two certifications? Or will the certifications battle it out to the finish because, as they would say in the old Westerns, “this town ain’t big enough for the both of us”?

As might be expected, there is consternation in the ranks of business analysts about this announcement, especially those who already have the CBAP certification. Questions abound:

  • Will the PMI-PBA devalue my CBAP?
  • Will I now have to make a career-defining decision on which certification to get?
  • Will employers who are now requesting or requiring a CBAP also request or require a PMI-PBA, or will they request a PMI-PBA instead of a CBAP?
  • Why does the business analysis arena need two certifications?

In a never-ending effort to seek out “truth, justice and the American way”** I engaged in conversations with people from PMI involved with the certification and people at the International Institute of Business Analysis (IIBA) to get their reactions. Not being a professional journalist, (or for that matter, a professional Superman) I can’t really say that I discovered either truth or justice, or the American way. However, I did discover some of the differences between the certifications, which I’m sure many of us have a vital interest in.

I will attempt to employ the journalist’s (and business analyst’s) six questions (though not in the order Rudyard Kipling introduced them), to discern the differences between the two certifications.

Why?

The most common question, of course, is why is PMI doing this? Why is PMI seemingly venturing into new areas that are considered to be outside the venue of project management?

First, this is not a new area for PMI. Defining requirements is a longstanding area of focus at PMI and one of the first organizations to embed requirements within its practice standards and professional certification exams.

Brian Weiss, PMI’s Vice President, Practitioner Markets, answered the question of “why?” this way: “It all has to do with organizational success and positive business outcomes. The PBA is just one of many things PMI is working on in this area – others include things such as a Knowledge Center of Excellence on Requirements Management or critical documents like a Requirements Management Practice Standard and a Business Analysis Practice Guide. The main reason behind developing these products stems from our research – PMI’s Pulse of the Profession illustrated for us that when projects fail, inaccurate requirements gathering is often the primary reason (32% of the time). Poor requirements management practices are the second leading cause of project failure. There is a clearly a problem here and no one is doing enough to solve it, so PMI has made a commitment to do so.”

Weiss added that “None of this is really new – Requirements have always been a component of project management. I think as the focus and importance of requirements management grew over the years that [focus] was accordingly reflected in PMI’s PMBOK® Guide and the creation of the Requirements Management Community of Practice which has over 18,000 registered users. I would characterize it more as an evolutionary process that has grown and will only continue to grow.” Weiss finished with, “PMI’s focus is on making sure organizations complete more of their critical initiatives, more often. This takes many different roles and people being successful, the business analyst included. Unfortunately, we have seen a growing divide or tension between project managers and business analysts, which is detrimental to organizational success. PMI’s efforts here are intended to help bridge that divide through greater understanding, support and integrated community.”

So the PMI-PBA is not a bright idea that occurred to a PMI official last year, but a progressive elaboration based on market research which has occurred over a number of years.
In short: the business analysis arena is so large in scope that multiple certifications may certainly be called for. After all, once getting their “certification” to practice medicine, many doctors then go on to get additional certifications for various specialties, all of which are hung proudly from their office or waiting room walls. But then I also believe that all CEOs should spend a couple of years as a business analyst to learn the fundamentals of business analysis; after all, the CEO is simply an experienced strategic business analyst with authority.

What?

First of all, let’s talk about the benefits of certification. While there are many who decry certifications, let’s focus on the positive aspects.

  • Certifications demonstrate (not prove) a prescribed level of knowledge and/or skill in a particular field of practice. Certifications are used by many industries and professions to separate the ‘amateurs,’ those that perform the role solely for the paycheck or are only temporarily playing the role, from the ‘professionals,’ those who take the role seriously as a career, whether the role is considered a ‘profession’ or not.
  • Certifications, like college degrees, demonstrate certain amounts of perspicacity and dedication. The recipient has taken the time and put forth the effort to study and practice the role, learning and experiencing the techniques and tools to be successful in that role. When considering a certification or actually pursuing it, the applicant has a greater focus on all aspects of the role being played and, therefore, based on the principle of mindfulness, learns and absorbs more about the intricacies and subtleties of the role.
  • Certifications are goals — targets to achieve — and as such provide motivation to many to burn the midnight oil and learning how to play the role better.

So what is the PMI-PBA? The PMI-PBA certifies competency and knowledge levels in the area of business analysis. PMI’s Global Product Manager for the PBA, Ms. Simona Fallavollita states, “the PMI-PBA recognizes and validates the critical role that business analysis plays in programs and projects.”

Who?

PMI suggests that candidates for the PMI-PBA certification include “anyone focused on evaluating and analyzing business problems and anyone managing requirements with a project or program.”

Anyone is eligible to take the pilot exam for the certification. PMI has not stated how many will be selected to take the exam, and is leaning toward a larger pool of exam takers— “the more who test, the better,” said Ms. Fallavollita. The pilot will be run in the same manner as other certification exams for PMI credentials. There will be an application to fill out detailing experience, specific hours and education

Of course the pilot is not free. The submitted application will be reviewed by PMI and those who are approved will pay for the exam. The PMI website quotes US$405 as the cost for a PMI member to take the computer-based test, and US$250 to take the paper-based test; however PMI is offering a 20% rebate for anyone who takes the exam during the pilot period. For non-PMI members the cost is higher. Once payment is received, the candidates are authorized to schedule their test appointment at their local test center and take the test. PMI states that the main difference between the pilot and regular exams is that the exam takers will not see their pass/fail results immediately after the exam, as is the case with other certification exams. “One of the key purposes of the pilot is to collect data on the exam and see how items perform,” stated Ms. Fallavollita. “Items” refers to the questions on the exam. That information will be used to establish the scoring for the exam, or what the pass/fail line will be. PMI expects to notify all of the candidates a few weeks after the pilot closes.

When?

The exam period began on 12 May 2014 when the applications for qualification became available and ends on 4 August 2014. During that time, those who are qualified and pass the exam will receive the PMI-PBA certification.

Coincidentally, the IIBA is also released Version 3 of the BABOK for public review on 12 May to all IIBA members for comment. The review period extends through 12 July 2014. The BABOK is the basis for the CBAP certification. The IIBA previews version 3 with: “The BABOK® Guide v3 reflects the evolution and expansion of the business analyst role, and outlines the skills and knowledge business analysts need to create better business outcomes and drive business success.” The CBAP certification exam will reflect Version 3 of the BABOK approximately six months after the release of Version 3.

Where?

Where does the PMI-PBA fit in with the current landscape of the business analysis community led by the Toronto-based IIBA?

The statements made by PMI above and elsewhere suggest there is a significant hole in successful project execution and that hole is called “requirements.” Before you jump to the conclusion that PMI is throwing bricks at the IIBA for not filling that hole, the IIBA appears to be moving away from project oriented business analysis and more toward a strategic role. Kevin Brennan, Chief Business Analyst (CBA) and Executive Vice President of the IIBA responds: “Is business analysis equal to requirements management and change control (or better, governance, since “change control” implies a specific approach to organizational change, one rejected by the agile community among others)? No. Those are things that a business analyst has to do but aren’t the center of our profession, although they appear to be very heavily emphasized by the content of the PMI-PBA. The core purpose of business analysis is to identify and define changes to an enterprise that deliver value to its stakeholders. Business analysts should be focused on business success, not project success. Project success is the consequence of effective business analysis, not its purpose.” (Emphasis mine)

This statement stakes out an area of business analysis that some business analysts might be uncomfortable with. Those who are focused on solution requirements, as opposed to the overall solution itself, might find that emphasizing business success over project success is daunting. Many might be uneasy with the movement of the business analysis profession toward a more strategic role than the tactical role business analysts have been filling for years.

David Barrett, a founding member of the IIBA looks at the issue of a space opening up a bit differently in his blog on the PMI-PBA: “For 10 years the IIBA has struggled for recognition within the main stream of our organizations around the world – public and private sector, small and large. The recognition they (we) strived for did not happen as predicted. The certification program has struggled and unbelievably, we still have very few project managers working with BAs.” (1) Mr. Barrett’s suggestion, in tune with many others, is that PMI has stepped in to fill the space still unfilled by the IIBA. He further suggests, however, as do many others, that there is plenty of room in the business analysis space for both organizations and both certifications.

One might conclude that one difference between the two approaches to business analysis and the representative certifications might be the difference between strategic business analysis and tactical or project business analysis.

What’s in it for Me?

(This is not one of the journalist’s questions, but this question is certainly on our minds)

The big question, at least for business analysts, is: What is the difference between the two certifications?

The primary difference appears to be in the focus of each. The PMI-PBA and its associated materials focus on the practices and principles of business analysis and requirements management in a project or program orientation, whereas the CBAP and the BABOK have a broader focus on business analysis in general. This focus will be made more apparent with the upcoming version 3 of the BABOK, which somewhat reduces the emphasis on the business analyst being a requirements manager or involved in projects at all!

And the primary difference between the forthcoming version 3 of the BABOK from the IIBA and the new practice standard for business analysis from PMI is again the focus. The BABOK describes what someone performing business analysis should do for acceptable practices. PMI’s Business Analysis practice guide, on the other hand, will address the “how” business analysis is practically applied in projects and programs. This “what” and “how” discriminator fits well with the general sense of the project space where business analysis defines what is to be done and the project manager and team define how it will be done. ( PMI states that the forthcoming PMI Requirements practice standard also describes what someone responsible for business analysis and requirements should do within the project or program environment and addresses the what in the context of multiple industry disciplines).

From this perspective, it would seem that all these documents may be necessary to fully realize the wide range of business analysis activities and practices. One can imagine using the BABOK and/or PMI’s Requirements Management practice standard to guide what must be done and the PMI BA practice guide to provide guidelines on how to do it. However, since none of the documents are ready for prime time, the final determination will have to wait until they are available to the public.

How?

The question is not how will it happen, but how will it play out over time? Or as a Manager of Business Systems Development asked, “I am studying for the CBAP from IIBA. Should I continue or wait for PMI? Which will be more valuable?”

While it may be too early to tell, certainly many in the business analysis community are logging their objections and expressing their indignation, or providing their support, and all seem to be making predictions. Some suggest a positive outcome of the PMI-PBA, which will provide wider exposure of the role of business analysis in organizations that don’t currently employ business analysts. This is good news for all business analysts seeking a larger opportunity pool. Kathleen Barret, founding president and former CEO of the IIBA, says “I believe competition is good. It is hard, but it will force IIBA to focus on its fundamentals. Why does it exist? What makes it special?” (2)

A cynic’s view of the future of the two certifications might see divisiveness in the ranks of business analysts between those carrying one certification and those carrying the other. This would generate millions of words of rhetoric on blogs and LinkedIn espousing the virtues and vices of the selected certifications. Confusion would reign among new business analysts and employers who are looking for business analysts until, eventually, those hiring business analysts ignore all certifications, and those business analysts considering certification to help with employment will abandon their aspirations.

On the other hand, we might see the clear distinction grow even clearer over time. The two organizations and their respective standards and practice guides might bring much needed clarity to the definition of business analysis and, in doing so, finally begin to define the professional business analyst. PMI certifies and focuses on business analysis working in projects and programs and the IIBA certifying and providing guidance to business analysts working at the strategic, non-project level. Both levels of business analyst can be recognized as part of the profession ***. Other business analysis related certifications and guidance may then be forthcoming (again, similar to the medical and legal specialties), such as user interface and human factors and business architects to round out the profession, and perhaps a business analysis-certified CEO.

Eventually we may end up following Principal Business Analyst Tina Underhill’s comment: “I am planning to do both! Why not?”

Don’t forget to leave your comments below.

* In 1950s television Westerns, such as Gunsmoke and Lawman, a common phrase to set up the plot was, “there is a new gunslinger in town” sometimes new “gunslinger.” This would be an adversary leading to a shootout on the dusty main street at the end of the episode, and sometimes the “gunslinger” would be a friend or end up being a compatriot of the lead character.
** “truth, justice and the American way” was the tagline from the old Superman television series from the 1950s, starring George Reeves. Superman and his alter ego, Clark Kent, a mild mannered reporter for a great metropolitan newspaper, were seekers of “truth, justice and the American way.”
*** My last two columns addressed the issue of whether business analysis is a profession or not. Responders made many great points to consider.

References:

  1. David Barrett, “PMI Announces Business Analysis Certification”, March 26, 2014 
  2. Kathleen Barret, “PMI Expands Offerings in Requirements Management”, March 26, 2014 

Business Analysis: Sharing Your Knowledge: Why and How

Written by Aaron Whittenberger on . Posted in Articles.

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

Written by Kupe Kupersmith on . Posted in Articles.

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

Written by Yvonne Harrison on . Posted in Articles. 1 Comment on 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

Written by Cecilie Hoffman on . Posted in Articles.

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.