Tag: Training

Why Does my Development Project Need a Business Analyst?

Written by Stephanie Vineyard on July 31, 2015. Posted in Articles.

The short answer: Because you want a project delivered on time, meets your specifications, and works for the end customers.

The long answer: The following project is a real example to illustrate the missing pieces and how a business analyst could have made a huge impact. Do you see similarities with a project you have?

Background

A team member (let’s call him Guy) worked with the client managing multiple Excel spreadsheets. Guy saw a pain point and realized he could do something about it. He suggested building a web application with relational databases to help the team. The client liked this idea because they realized this new tool would impact forecasting and reporting – affecting the bottom line.

Guy set to work with the client outlining the project and developing the tool. A talented project manager (Pam) joined the project. Despite Guy’s knowledge of the business process and technical skills and Pam’s attention to detail, this product was behind schedule. The end customers found that this tool relieved some pain points but didn’t address all of their needs or use cases.

What happened?

Why did a product that started out so promising end behind schedule and not fully addressing the end customers’ need?
Simply put, because there was no business analyst. Guy spent his time working with the client to understand the use cases instead of developing the tool. Pam spent the majority of her time collecting the requirements from the client. No one talked to the end customers. The only requirements provided where the “Shalls” included in the contract that did not cover the full scope of the tool. And most importantly, no one ensured Guy spent his time developing instead of gathering user stories.

What does a business analyst provide?

The most important value a business analyst provides is getting the right information to the software developer in the right manner. The business analyst works with the team to make sure the product delivered fits their needs. In this case, a business analyst allows the developer to focus on developing code.

Business analysts bring:
• An understanding of the business needs and the client needs
• A full understanding of user stories and use cases for the end customer
• Detailed requirements translating the customer needs into technical tasks
• Clear communication with the developer to create the right tool
• Detailed work with the project manager to confirm deliverables are on time and meet the contractual obligations

Wrap up

So why should I spend extra money for a business analyst? Because omitting this crucial team player will cost me in time and quality of the final product.

Do you have an example of a project that succeeded because of a business analyst’s work? Do you have a project that could have been better with the help of a business analyst?

Better Tools: Efficient Table Management

Written by Martin Coomber on July 28, 2014. Posted in Articles. 1 Comment on Better Tools: Efficient Table Management

As a Business Analyst, I know that models and diagrams are the most effective way of expressing ideas, information, and outcomes. However, no matter how much I use visual content, I am often required to prepare text-heavy documents.

Whether it is requirements statements, business cases, service levels, project reports or dozens of other documents, sometimes I need to prepare written content as efficiently as possible.

To present written content, I try to maximise my use of tables, typically using Microsoft Word. I found the that the standard table tools in Word were not as efficient as I needed, so I set out to address these deficiencies.

This article outlines my thoughts on why tables are so effective, and indicates the improvements that I have made to Word’s table management features. I then describe the techniques I used to build them, and provide a link where you can find further details and copies of each of the tools.

What Tables Offer

From a BA perspective, I believe tables provide the following benefits:

Item	Feature	Comment
1	Conciseness	The limited space in a table drives a focus on recording key information. Unnecessary content is discouraged. Bullet points are encouraged. Short phrases, possibly ungrammatical, can be used.
2	Usability	Readers are much more likely to scan a table; large amounts of information can be viewed at a glance. Tables also allow the reader to spot patterns and search for detail that would otherwise be lost in regular text. Tables focus attention onto the key points on the page.
3	Context	The column and row headings provide context to table entries that would be lengthy and repetitive to record in regular text.
4	Structure	The order of rows and their presence in particular sections conveys important structural information. Numbering rows aids the review process and provides traceability.
5	Speed	Tables allow information to be captured and formatted quickly. This is important for BAs working to deadlines.

Renumbering Improvements

For me, the main issue with Word’s standard tools was the lack automated row renumbering. There is real value in having consistently numbered rows, but without some sort of renumbering, inserting a row into an existing numbered table of can be a real pain. For example, when creating a list of requirements, I need to add new entries and move items around. I then want the numbering to adjust accordingly.

In some documents, I need to build several lists, so I need the ability to add a prefix to the numbering in each table, so that across the document as a whole, each entry is unique.

Sometimes I need to reliably lock down the numbering in a given table so that new entries don’t automatically change those that already exist. I can then safely renumber the new rows manually.

Appearances matter too, at times I need to use different numbering styles, from the simple (1,2,3,…) to more complex formats such as (A.1, A.2, A.3,…) or (NF-01, NF-02,NF-03…) that involve different sections within a given table, and using different separators, with or without leading zeros.

Word does offer some basic tools for this kind of formatting. For example, it allows you to use outline numbered lists in the first column of a table. I have found these to be tricky to use, especially with prefixes, and it is hard to lock down the numbering at a certain point, so you can be sure that nothing changes.

To address these issues, I decided to write my own one-touch renumbering process.

Inserting and Deleting Improvements

One of my key requirements is the ability to quickly add new rows. I often need to record several new ideas in a table very quickly, for example, when recording workshop findings during rapid discussion.

Word lets you insert lines, but this can require several keystrokes, and you have to be careful how you do it. In Word, it matters whether you insert above or below the current line. I would often get it wrong, and end up with section or heading row formatting copied into the body of the table, and have to use even more keystrokes to correct this.

I decided I needed a one-touch insert function that reliably inserted (say) 5 blank lines below the current line and positioned the cursor ready for rapid entry.

Creating blank lines for quick entry means occasional empty, unused lines. I decided I needed a table clean-up routine to remove unwanted rows before the renumbering started.

Having a one-touch insert function suggested the need for a complementary one-touch delete, something that would delete rows if rows were selected, or regular text if that was selected instead.

Getting Started with the Build.

Microsoft Office comes with a development tool called VBA. You can get started with VBA by having Word record a series of keystrokes and then see how these actions have been converted into VBA code ready for repetitive use. There is a vast amount of information on the web about getting started with VBA, and most BAs will be productive in just an hour or two.

I decided that my table tools would be launched by shortcut keys rather than by using the Ribbon menu. Ribbon coding isn’t for the faint-hearted, and for speed reasons I wanted to keep my fingers on the keyboard as much as possible.

I needed a way of making the tools available to any document without having to load code into each. I found that Word allows you to load a template into its startup folder. This gets opened automatically and allows the code within it to be used by any document. In some environments, this code needs to be digitally signed, but there are simple tools available to self-sign the code for each PC you use.

My first major task was to prove the tools could be invoked correctly. I did this by creating some test routines, assigning them to shortcut keys and confirming I could use them whenever a I needed.

I then tested the basic table manipulation tools in VBA. These included stepping through each row, updating text, deleting rows and similar functions. Word has some quirky ways of marking the end of text in cells, so these tools took a bit of getting used to.

I also needed to store information about the tables. For example, which tables allow renumbering, whether a prefix being used, and what separator should applied. To do this, I decided to use custom document properties, and had to build a set of tools to read these values and update them when they were changed by the user.

The basic routines came together fairly quickly, but I did spend quite a while making the logic handle the wide variety of table manipulation tasks that a BA needs.

I also found that my use of tables really took off when I simplified the text styles I used for tables. I recommend taking the time to set up new styles for standard table text, table bullet points and table headers. Keeping these separate from the regular text styles allows easy change of the fonts to fit the changing cell space availability, and assigning these styles to shortcut keys means they can be used quickly and reliably.

Don’t forget to leave your comments below.

Data Migration – The Journey of a Thousand Miles

Written by Yvonne Harrison on May 12, 2014. 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.

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.
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.
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.
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.
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

Written by Richard Lannon on May 4, 2014. Posted in Articles.

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?

Written by Aaron Whittenberger on February 4, 2014. Posted in Articles. 1 Comment on Where is the Business Analysis Profession Going?

It 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.

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.

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.