Skip to main content

Tag: Training

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.

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.

Where is the Business Analysis Profession Going?

awhittenberger feb4It is customary that at the start of a new year people reflect upon the past and look into the future. I believe you will agree some people are better at both activities than others. In fact, recently Julian Sammy, Head of Research and Innovation at the IIBA® did both. In this recent article he takes a look at predictions that he and other members of the Senior Leadership Team of the IIBA® made in 2011 about what 2013 will look like. He then takes a look at what he thinks 2016 will look like for the business analysis profession.

So I will jump on the band wagon (because it is a popular thing to do and because I have something to say) and give you a look at what I think the business world will look like for business analysis professionals for the next couple years. Trends take time to develop and take hold so I will take a multi-year look into the future, and why I believe Julian looked three years into the future. You will see my analysis has a heavy tendency toward the tactical IT Business Analyst role because, well let’s face it, that is what I know best; and it is still the largest business analysis role in existence today. Maybe one of my trends should be a prediction of how that will change soon. Ok, I got my crystal ball out, are you ready?

Trend 1 – Agile is here to stay

There are those that still believe that agile is a fad, soon to pass. Sorry, anything that has been here for 10+ years is not a fad. Many fashions (remember bell bottom jeans) are a fad; agile is here to stay. Although acceptance of agile methodologies may stagnate a bit, many of the tools and techniques of agile will find their way into IT project work in many companies; further developing the hybrid project approach.

Resistance of agile acceptance will come from companies that “tried” agile and failed. Some will “try” again or for the first time, some will abstain; yet some will realize you don’t “try” agile, you decide to give it your “all” (all the organizational support it needs) or don’t bother. Further resistance will come from the idea of a 100% dedicated team to one project seems an unwise use of resources in today’s business environment; and agile professionals will struggle to answer that concern to the satisfaction of business management. Also, lack of truly effective Agile Coaches will hinder the willingness of companies to give it a go. This will become a valuable consulting role; if you’re looking to drive your career into a role of the future, consider this one.

Trend 2 – Business agility will demand greater collaboration on IT project teams

Greater demand for quicker IT project delivery times will continue to crunch project schedules and resources. The trend of doing more with less will continue. This will demand greater collaboration among the project team. The BA Team, QA Team and PM will give way to the IT project team; with the BA as the liaison to the business stakeholder. They will all merge into the “core” project team with the responsibility to deliver full functionality, on-time and on-budget. The “we vs. them” mentality will slightly diminish between business and IT, but it will drastically diminish among the IT team itself; gaining greater synergies for a more effective working environment.

Trend 3 – Resurgence of Strategic Enterprise Analysis

Continued dissatisfaction with dismal project success rates will bring about a resurgence of the strategic business analysis role. This role demands a whole different skill set than the traditional IT business analyst. Skills to do market research, capability gap analysis, SWOT analysis, benchmarking and feasibility studies will become in greater demand. The skill to create a bullet-proof business case describing the business value of IT projects will become paramount. This role will work with project approval committees to define for them the business value and risks of projects under review, thereby giving necessary support to project portfolio management.

Trend 4 – The Value of Product Vision gives rise to the Product Owner and Product Manager roles

Product Vision will gain wider acceptance as many will come to the realization that this means more than maintaining future enhancement and feature lists, and product roadmaps. System users will become greater source of future direction of product vision of systems development. Yes, these roles exist today, but primarily in large enterprises. We will see this role gain acceptance in Small to Medium Sized (SMB) companies. Even in large enterprises these roles will gain greater recognition with clear career paths. As these roles gain higher profile recognition, people in the role realize that their value comes in communicating that product vision to all business and IT stakeholders so that all have a shared vision of the future product. For business and IT professionals looking to drive their career, this is another good direction for the future.

awhittenberger feb4 2

Trend 5 – Requirements collaboration tools integrates social media and the desktop

With greater emphasis being put on business agility and greater collaboration on the IT project team, requirements management tools providers will jump on the opportunity, as these tools make the transition to requirements collaboration tools. Transparency of requirements during their development will become enhanced as other members of the project team, including business stakeholders will have that visibility. The requirements tool itself will become the accepted communication tool among the team, allowing them to interactively communicate about the requirements being developed. Yes, some tool providers have already integrated this capability, but organizations will integrate this capability into its business and IT processes, again due to gaining business agility.

The great enhancement in coming years in this area is that these tools will integrate to peoples’ desktop. Imagine being in conversation with a group and needing to schedule a meeting to continue the conversation. Imagine being able to scan everybody’s calendar and having a few suggested dates and times that everyone can make it to the meeting. Upon agreement of a good date and time, imagine everyone in the conversation receiving a calendar meeting invitation moments later; and all this happens right there in one tool. Now imagine that the conversation included vendor personnel who use Lotus Notes calendar while you use Microsoft Outlook; and some participants use Google calendar. Each recipient receives the proper invitation for their calendar.

Finally, the business analyst doesn’t rely on Microsoft Office as their primary requirements tool. Yes, some large, and SMBs, have been past this stage for a few years. However, this trend will become much more wide spread as more and more companies invest in these requirements tools; and those that have had them for a while will invest in the next generation of these tools to gain the benefits of the increased collaboration for their project teams.

Trend 6 – The Business Analyst as Proxy for the Business Stakeholder

In organizations where the Business Analyst reports to IT management and work on IT projects, the company will recognize the value of putting a Business Analyst on the business side to work as a proxy for key business stakeholder(s); this will be an additional BA role within the organization. This will free up the business stakeholder(s) to run the business while their proxy takes on the responsibility of working on IT projects to bring about the change that the key business stakeholder desires. This, of course, means that the business analyst has to not only share the product vision of the business stakeholder, but must understand the ‘what’ and the ‘why’ of all the business change requests with great clarity.

Trend 7 – Businesses increases its Investment in Training

Changes in the business analysis environment will increase at even greater velocity. That along with the increase need of collaboration with a lot of different roles within the business organization will cause business analysts to develop new skill sets. Businesses will continue to see the value in investing in the development of its people, but will look for greater bang for their buck when investing in training for business analysts and other project professionals. Training that take the people away from work for shorter time, allow more people to attend the training for lower cost will see increased utilization over the traditional classroom training class.

Education providers in the space will scramble to beef up their virtual classroom offerings with excellent content, while continuing to offer the traditional classroom training for those organizations that value the in-person interaction with the instructor and other students, and are willing to pay for it.

Local IIBA® chapter professional development days (PDD) will help fill this need as well. PDDs like WI BADD (Wisconsin), I-BADD (Iowa) and SO BARC (Cincinnati, OH) will continue to gain attendance over the next few years. Chapter’s that don’t yet offer this service will see the value and begin to provide this service to their business community. Likewise, local business education providers that have any capability in this space will beef up their business analysis offerings to leverage the opportunity of this trend.

awhittenberger feb4 3.jpg

Trend 8 – Business Analysis jobs will continue to be in abundance

With organizations putting focus on business analysis roles, additional roles will prop in those organizations. With the diverse skill set necessary to be effective, business analysis jobs will be in abundance. We will see an influx of people flowing into the business analysis profession from other professions including project management, quality assurance, business and operations. Now the flow will be both ways as people move from business analysis to project management and the other professions, but the flow into business analysis will be greater. Even with that inward flow it will not keep up with the demand for good business analysts, creating even greater demand for training.

Trend 9 – We will see a resurgence of Business Analysis Centers of Excellence

With all these changes in the business analysis space, organizations will also look inward for training for their business analysts and give them opportunities to learn from each other. Business Analysis Communities of Practice (BACoP) and Centers of Excellence (BACoE) showed rapid growth in 2011 and 2012, and stagnated a little in 2013. Organizations will see their value in training and incorporating best practices across lines of business. They will help ensure the same level of service across lines of business. We will see a slight uptake in BACoPs and

Trend 10 – Business Analyst and Project Manager roles will continue to Overlay

As the Project Management Institute (PMI®) continues to expand its teachings into areas like stakeholder management and collecting requirements they will lose focus on their core purpose and core audience. Businesses will realize that requirements, and stakeholders, need more than just management or documentation. They will realize the different skill set and focus (business focus, not project focus) needed to effectively develop requirements from the business and project management will give way to a project leadership mentality. Businesses will see that dual project leadership roles, one focused on the project and one focused on the solution, has greater probability to lead to increased project success rates.
The practitioners that perform these roles, through their professionalism, will find ways to work together for the benefit of the organization no matter the teachings of the PMI® or IIBA®. As for the IIBA® and PMI®; just like David and Goliath, David will

So that’s how I see the next couple of years for business analysis, and related, professionals. Now let’s see how I stack up to the ESI International’s predictions for the

So which do you agree with? What would you add or subtract from the list?

Don’t forget to leave your comments below.

How to Prevent the Negative Impacts of Poor Requirements

There is an abundance of stories of failed projects. Research has shown the reasons for IT project failure in the USA, indicated that project success rates were only 34%, with the rest of projects being either “challenged” in some way or failing outright.

The losses can be very significant. For example, British food retailer Sainsbury had to write off its $526 million investment in an automated supply-chain management system. The U.S. Federal Aviation Administration spent $2.6 billion unsuccessfully trying to upgrade its air traffic control system in the 1990s. Ford Motor Company abandoned its purchasing system in 2004, after spending $400 million. In the 8 years since, things probably haven’t changed much.

From the project management perspective, technology projects fail when they do not meet the following criteria for success:

  1. Project delivered on time
  2. Project completed on or under budget
  3. The delivered solution works as required by business stakeholders.

A number of factors are involved in any particular project failure. The most often quoted factors are listed below:

  1. Lack of stakeholder involvement
  2. Unrealistic time scales
  3. Poor requirements
  4. Scope creep
  5. Uncontrolled changes
  6. Insufficient testing.

The quality of requirements can have a lot of impact on the outcome of the project. One high profile project which was significantly affected by the requirements management process was the Chrysler Comprehensive Compensation System which was supposed to handle paychecks for Chrysler’s 87,000 employees but was shut down after several years of development.

The impact is magnified as the BA moves from high-level requirements towards functional and non-functional requirements. The cost of rework of functional requirements is the highest because these requirements define the technical specification and design of the solution.

Here is a visual summary of the impacts: 
korbanIMG01 April30

Project impacts 

Projects are undertaken by the business to satisfy a strategic goal. Poor requirements have the following effects on projects (and subsequently impact the strategic goals of the business):

  • Scope creep negatively affecting budget and completion time
  • Low utilzation of resources and higher overheads
  • Inadequate business process design (due to insufficient details about activities)
  • Poor design and ergonomics of the user interface, resulting in lower productivity
  • Inadequate software specification, resulting in lower developer productivity
  • Poor specification amplifies the negative effect of poor requirements when it comes to software testing, leading to higher costs and lower quality of the solution
  • Time-consuming and costly code rework
  • Difficulties in solution integration.

Business/organization impacts

More generally, the business as a whole is affected in many different ways by poor requirements through the projects that the business undertakes. Here is the short list of negatively affected areas that I have witnessed:

  • Lost opportunities for the business 
  • Lost advantage relative to competitors
  • Breaches of regulatory compliance
  • Poor stakeholder engagement and loss of trust
  • Reduced business process efficiency due to poor solution design
  • Negative user experience due to cumbersome UI design
  • Lack of cohesive IT landscape due to poor integration
  • Negative impact on the bottom line, generally speaking.

How to prevent poor requirements

In my experience, there are two ingredients in any given project which help me deliver quality requirements. One ingredient is what I know about the business and the project. The other one is the techniques I use to ensure that I deliver great results. 

It probably sounds quite vague at this point, so let’s dive into the specifics. 

Knowledge needed for quality requirements

The foundation for creating the future solution is a good level of understanding of the current state. Regardless of the methodology you are following, you have to start here. What do you need to know?

  1. Know the context in which the business operates

    The business operates in two contexts. One is the external context where market forces define how the business operates and maintains its sustainability. This includes regulatory requirements, competitors and partners.

    The second context is internal. It is actually more complex as it includes organizational structure, business processes, governance around the processes (business rules), people involved in the processes, internal politics, organizational culture and overall pace of changes within the business you work for.

  2. Understand the business problem or opportunity

    This is the actual driver for the project. Without knowing the real business need you won’t be able to find the solution that solves that problem. 

  3. Identify gaps to be bridged

    Once the business problem and stakeholder concerns are clear, you can draft the future state. When the future state has been confirmed with stakeholders, perform gap analysis. Your focus here is on what should be done within the project scope to resolve the identified problem. It is also good to think about extra value the business can get as a result of the project.

Extra value can be delivered when you have a clear understanding of changes going on in the organization, and how the project you are engaged in fits into the change landscape.

Techniques for better requirements

The techniques I’ve settled on in my practice enable me to use stakeholders’ time efficiently and get a clear picture of the current state. Let me share them with you. 

  1. Do your homework

    Before engaging stakeholders in requirements gathering activities, I read all available documentation on business processes, business applications in use, regulatory requirements (if any), internal communication about changes in the organization, as well as other projects that may have dependencies with the project I am in.

    I also explore information relevant to the industry as a whole to identify possible good practices that I can re-use. 

    I call this exercise my “homework”. The benefits of the homework exercise are that I know the “language” I will use when talking with stakeholders. I also know what to articulate to confirm information that is unclear. I feel confident about my part in the project and I know that I can help the business.

  2. Power up communication with visuals

    There is nothing better than diagrams to explore the current state and get an idea about the desired future state. The time savings due to using visuals can be enormous. How much time do you spend to define the future state? If you don’t use diagrams at present, you could probably save a significant portion of that time.

    Outline organizational boundaries, processes and data they use, add used applications, process and technology interfaces where required, and finally add roles involved in the processes. Now you have a snapshot of the current state.

  3. Use templates to support your work

    Any business analysis task has to be organized to save your valuable time. Templates are of great help here as they let you re-use the common parts of documentation, and customize as necessary. They also serve as a kind of checklist of required documentation, and ensure that you don’t miss anything.

    My favourite template is the Current State Analysis. It includes analysis findings, identified business need, visualized current state (including the external context) and recommendations on what the solution may look like in terms of capabilities.

  4. Avoid common pitfalls

    Requirements become poor and vague when they mix project related tasks, statements about the future state, applied rules and solution design.

    A good way to avoid these common project pitfalls is to plan business analysis, and to document the planned activities and deliverables in the Business Analysis Plan. It’s an integral part of the project plan. However, the Business Analysis Plan does not deal with project tasks.

    A hierarchical approach has to be taken to the future solution. Firstly, list the required solution capabilities. They can include both changes to business processes and technology services supporting these processes.

    Secondly, translate these capabilities into a business process design and business requirements for supporting technology services. You always need to tweak a business process if you change software used to support the process.

    Thirdly, add relevant business rules to justify future business logic. 

    Next, validate the business process design and specified business requirements with the stakeholders.

    Finally, transform the validated requirements into functional requirements. These will guide the development and implementation of the solution. Don’t forget to describe business data (along with data types) to be used within the solution.

Adding prototypes of the user interface will make the functional requirements more precise and also help establish new terminology to be used in the solution.

These steps are executed in an iterative fashion so they align well with modern “fast” methodologies such as Agile and Scrum.

Summary

Poor requirements may lead to project failure. Functionality that is poorly specified, implementing something that isn’t needed, poor processes, lost development time, missed project deadlines, poor quality of documentation – the list of impacts can go on and on.

I believe that we as business analysts can do our job well and contribute to business success. Sometimes we don’t have enough time to stop and consider why our requirements are poor.
In the article above I listed the key ways to improve requirements. I’ve tested these approaches in many projects and they always produce positive results.

I hope they will help you, too!

Don’t forget to leave your comments below.

The Bad Ass BA: How Do You Know When Business Analysis is Being Done Well?

FEATUREOct15thA senior manager posed this question at the end of an all-hands meeting: “How do we know when business analysis is being done well?”

If you are a business analyst, it is easy to answer the question, “How do you know when business analysis is being done poorly?” While it is likely that what this senior manager wants is success criteria, there’s a useful intermediate step, which is to identify the symptoms of success. Let’s assume this manager is getting ready to make changes in his organization so that defining business needs and recommending solutions that deliver value to stakeholders enable the desired organizational change. Moreover, the activities leading to and following from the change will happen in a predictable, efficient and, dare we say it, a manner that makes people proud to be part of the organization? Yes, we dare.

Try the following exercise for yourself. Fill in the blank: “You know that business analysis is being done well when _______________________.” Here’s what we came up with. We have included the perspectives of many different organizational levels.

  • The business’s “vision” is expressed in terms of a vision statement and a roadmap for how it is going to get there. The roadmap is updated frequently to reflect the progress of development programs and projects, and changes to the business vision as the market changes.
  • Product management teams understand the difference between a vision, a roadmap, a portfolio and a project pipeline.
  • After the agony of elicitation, modeling and analysis, the answer/solution/approach is obvious to all stakeholders (and they agree on which one it is).
  • Successful approaches are repeatable and results are reproducible.
  • An organization’s ability to identify the success criteria for a proposed new program or project includes meaningful metrics.
  • The enterprise has the habit of building in baseline measurement and trend analysis.
  • There is no resistance to measuring/monitoring the effect of change.
  • Time to create quality documentation is protected; historical documentation is valued for potential re-use and for use as a reference.
  • Junior and mid-level business analysts can connect their tactical work to their organization’s strategic goals and the enterprise’s strategic goals.
  • Senior business analysts know what their business customer’s 5-year business roadmap is and how that roadmap is supported by IT’s 5-10 year technology roadmap.
  • New-hire business analysts are given ready-for-them-on-day-1 materials, organizational charts, process map repositories, and BA best practices/templates repositories.
  • HR, product managers, project managers and line (organizational) managers understand the difference between the following roles: business analyst, application analyst, quality assurance analyst, UI designer, database analyst, developer.
  • Entry-level new hires are not given the business analyst title until they have demonstrated some if not all of the fundamental skills of a business analyst. This common practice devalues the role of the business analyst.

“But wait,” you say, “there’s more!” You are right, there’s much more, but let’s press forward past the symptoms. Let’s take an organizational perspective. First, we need some context.

Here’s the conundrum that line managers of business analysts face: business partners/clients/customers want a business analysis service that provides both a strategic partner and a faster-than-light order-taker. Many BAs begin their professional lives in order-taker roles. Over time, they develop their skills and chance upon a situation where their insight, experience and knowledge enable them to contribute at the level of strategic partner.  After the head rush and deep sense of professional fulfillment from receiving the first “Your contribution as our strategic partner delivered results far beyond our expectations” comment, few business analysts will be content returning to the role of an order-taker. A good manager understands that the BA as strategic partner vs. order-taker isn’t an either/or question, but is a question of organizational maturity.

Regarding organizational maturity, we need to remember the late 1980s when Watts Humphrey first published his Capability Maturity Model (CMM) as a paper, then as a book, Managing the Software Process. The 1989 model defined five levels that were points on a continuum:

  1. Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new or undocumented repeat process.
  2. Repeatable – the process is at least documented sufficiently such that repeating the same steps may be attempted.
  3. Defined – the process is defined/confirmed as a standard business process, and decomposed to levels 0, 1 and 2 (the latter being work Instructions).
  4. Managed – the process is quantitatively managed in accordance with agreed-upon metrics.
  5. Optimizing – process management includes a deliberate process of optimization/improvement.

According to the Software Engineering Institute, which sponsored the development of the Capability Maturity Model, “Predictability, effectiveness, and control of an organization’s software processes are believed to improve as the organization moves up these five levels. While not rigorous, the empirical evidence to date supports this belief.” That was the perception back in the late 1980s. Fast forward to 2012. We now have a variety of rapid iteration software development methodologies that have the intent of optimizing the software development process but, well, let’s be honest, are often misused to avoid doing the hard work up front of defining goals and success criteria.

As a result, we have this notion of “quick hits.” A quick hit is often a solution to a problem that everyone wants solved yesterday. Getting any form of relief to the problem is so urgently demanded that people adopt a just-get-it-done attitude and throw money at it. Quite often the quick hit is a short-term success, not because the effort in the spotlight and a few individuals’ careers are riding on a good outcome, but because the business analyst defined the problem so well that the solution’s objectives were highly constrained so that the requirements could be met with a minimum of design, which would mean that development was low risk so functionality could go into production like an arrow to the target.

While the quick hit model for projects delivers immediate gratification, anyone taking the long view realizes that the success of a quick hit is often counter-intuitive. Sure, the quick hit solution was speedy, and it met the letter of technical requirements but it isn’t extensible and it has few “-ilities,” namely, scalability, reliability, compatibility, manageability (four of the many “non-functional,” requirements for readers who aren’t business analysts).

Moreover, the more emphasis placed on quick hits, the less focus there is on strategic planning and understanding the big picture, that is, the business model and business architecture view of the business’s needs. People who are rewarded for putting out fires with quick hits are not receiving incentive for thinking about the long-term ramifications, nor do they feel at liberty to think strategically.

In 2010, Alexander and Osterwalder and Yves Pigneur published their handbook for visionaries, game changers, challengers and empowered business analysts called Business Model Generation. When there is no business model, an organization is low on the capability maturity model; development is chaotic, quick hits are the norm rather than the exception, and innovation is haphazard at best.

In 2011, Robert Strohmayer identified the business architect at the top of the list of the six hottest jobs in IT (“The 6 Hottest New Jobs in IT”, Infoworld, June 2011). Strohmayer quotes Alex Cullen, a VP at Forrester Research and the Research Director for Enterprise, Business, Application and Development and Technical Architectures, “Business architecture is about making sure the whole business holds together . . . it’s a role built around business planning, pointing out opportunities to utilize IT more effectively.” Simply put, business architecture model is a blueprint of the enterprise that provides a common understanding of the enterprise and is used to align strategic objectives and tactical demands.

When business analysis is being done well, the practice of creating and maintaining the business model and the business architecture is as deeply ingrained in the organizational practices as the tradition of the quarterly all-hands meeting. Not having the business model and the business architecture model as references would be unthinkable. After all, how will an organization know what it is doing and how things will affect it in the long term?

When business analysis is being done well, the organization values having the solution to a problem defined along the dimensions of the users, the interface, the capabilities that the users and the business will have, the data, the controls, the environment that the solution will deployed into, and the quality (those “-ilities”). If you want to know more about these seven dimensions, take a look at Discover to Deliver, just published by Ellen Gottesdiener and Mary Gorman.  Discover to Deliver articulates a methodology based on rapid iteration for ensuring that what gets built has long-term value and can be linked directly to an organization’s strategic goals.

When business analysis is being done well, business customers see their business analyst as a strategic partner, and they see an empowered business analyst who knows the business’s 5-year roadmap, not just their program portfolio, not just a project pipeline and not just the project in front of their nose. In our experience, business analysts who work in organizations that are not mature in the CMM sense are only as good as the managers who protect them. No business analyst who consistently takes initiative, challenges the conventional perspective, raises uncomfortable issues and brings transformational (disruptive) ideas to the table will survive without at least one manager watching their back and providing them with information about the political climate and budget sensitivities.

When business analysis is being done well, executives see the product managers as entrepreneurs, the enterprise architects as intrapreneurs, and everyone sees senior business analysts as brilliant strategic partners.

Don’t forget to leave your comments below.


Cecilie Hoffman‘s professional passion is to educate technical and business teams about the role of the business analyst, and to empower business analysts themselves with tools, methods, strategies and confidence. She works for a Fortune 100 company that is asking the right questions. [email protected].

Rebecca Burgess is a certified Six Sigma Black Belt and a business process analyst at Academy of Art University in San Francisco, California. After many years of uncovering problems and determining root causes, she is now applying her BA skills to strategic process design and improvement.  [email protected]