Tag: Development

Being a Personal Business Analysis Center of Excellence

Written by Aaron Whittenberger on April 14, 2014. Posted in Articles. 1 Comment on Being a Personal Business Analysis Center of Excellence

I am often asked how to best go about a particular business analysis scenario; how to do a particular technique. Usually the person is asking more than just best practices, but looking for a short-cut or one-size-fits-all process to go about doing business analysis. I hate to break it to you…there is no such thing.

What I often find in the question is that the person is getting hung up on the process or technique and has lost sight of the ultimate goal…which should always be to add business value. So in attempt to answer the question for all business analysis scenarios and professionals, I will give you my personal operating goals when conducting business.

Remember business analysis is not just the IT Business Analyst or Business Systems Analyst that works on IT projects to deliver software solutions to the business. Whether you are an IT Business Analyst, Enterprise Architect, Process Improvement Analyst, Data Analyst or one of the other business analysis roles, you have to interact with and build relationships with stakeholders and your ultimate goal should be to deliver business value to those stakeholders. So these operating goals relate to you.

There is no one-size-fits-all way of doing business analysis

There are many areas of business analysis that cover many strategic, tactical and operational roles within the organization. There are 34 techniques defined in the Guide to the Business Analysis Body of Knowledge® (BABOK®) version 2.0, and will be more defined in version 3.0 when it is released later this year. With that kind of breadth of coverage it would be impossible to have one simple way to do things. Even in a requirements elicitation activity, what worked last time, with that set of stakeholders, may not work this time with this set of stakeholders. Experience is the best teacher. Go into each activity prepared, ready to do your best and flexible enough to handle the different alternatives that can be thrown your way.

Be proactive not reactive

The best way to be proactive is to plan ahead. There is a whole chapter in the BABOK® concerning business analysis planning activities. It actually speaks about planning the business analysis activities for a software project, but as a practitioner you must plan for each activity you engage on during your work, whether software project or more strategic or operational activity. If you are working with a new line of business or business process that you are unfamiliar with, learn as much about it as possible before you engage in your business analysis activities. There are many techniques that the Business Analyst can use to learn about a business process on his/her own.

Guide, do not direct the conversation

Never go into an elicitation activity cold, be prepared to facilitate the discussion; but realize that the Business Analyst’s job is not to direct the conversation to a preconceived end, but guide the conversation to ensure that it is productive. You may walk into the activity with a preconceived idea of the way the conversation may go, but don’t mistakenly think that is the only way the conversation can go. When the conversation takes an unexpected turn away from your preconceived idea don’t attempt to stop it, allow it to develop and see where it may lead and what can be learned from it. Guiding the conversation means making sure side conversations are kept to a minimum and that everyone’s voice gets heard. You should never walk into a facilitation activity with the goal of forcing all stakeholders to agree on a particular point. It is alright to walk in with the goal of trying to get buy-in or consensus on a point, but if you do not get that consensus that is not necessarily failure.

No one is perfect

Your requirements, process model or design does not have to be perfectly written before you share it with the stakeholders with which you are working. Building these things in collaboration with the stakeholders usually produces better results. Remember that the business stakeholders and project team members that you are working with are not perfect either. They may not articulate everything just perfect or give you perfect feedback on your requirements or models. Seasoned professionals will work through these difficulties.

Work collaboratively with others

As I just mentioned working collaboratively with your stakeholders usually produce better results. The days of the Business Analyst conducting elicitation activities, running off to write the requirements by themselves and then presenting them back to the stakeholders is quickly coming to an end. When possible, write the requirements, or build the process model, during the elicitation activity. Spend the time with the stakeholder and work together to produce the requirements or design. The good by-product of this method is a much easier signoff of the requirements or design.

Learn from past challenges

You are not perfect. The people you work with are not perfect. Don’t think that everything you do will be perfect or end in success. It was Colin Powell that said “There are no secrets to success. It is a result of preparation, hard work and learning from failures.” Failure is not a failure if you learn from it. When something doesn’t go as expected, take a moment to reflect upon the activity and your role in it. What could you have done better.

Learn from others

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, you can learn from others on the teams on which you work. Everybody in the organization may look to you as the subject matter expert (SME) in business analysis, but that doesn’t mean you can’t learn. If you are open to it, you may be able to learn from that Business Analyst that the company just hired last week. Look at the way other team members operate, what they do good and what they do bad. Incorporate the good into the way you operate. Also remember, you can learn from others doing activities outside of the business analysis space.

Always drive from the business need and the “why”

I have seen business analysts get so caught up on the particular activity or technique that they are doing that they forget why they are doing it. They may be trying to be so perfect that they lose sight of the goal. The Business Analyst’s ultimate goal should be to add business value, but they should know the goal of each activity that they undertake. Now that you keep the goal in mind, determine the “why”. When investigating a new area or business process, get to the “why”. Why do the people do it that way. What is the business value of doing it that way. I have heard it said to ask “why” five times (The 5 why’s). It may not need 5 times, but asking “why” multiple times is a good process to get to the underlying root cause.

Become the trusted advisor

The goal of your business analysis activities should be to add business value. The goal for you in the Business Analyst role within the organization should be to become the trusted advisor. You have to build relationships with all the stakeholders in the organization from your technical team members, project managers, business stakeholders, IT management and business management to build the trust so that these stakeholders will give more weight to your recommendations. When your business stakeholders see you accurately representing their points of view, when IT and business management see you working for the best interest of the organization and working to add business value, trust will grow and you will find your work easier to perform built on that trust.

Continuous Improvement

No matter how long you have been doing Business Analysis, no matter how “Senior” or “Lead” you think you are, learn from others and learn from past challenges and successes. Not only work to become the trusted advisor to everyone in the organization and to add business value; but work to hone your own craft. If you think that you’re so good that there is nothing more for you to learn, I would say to you “get over yourself”. The business analysis space is changing dramatically and will continue to over the coming years. There are new and better ways of doing things being discovered all the time. If you are not consistently working on improving the way you do business analysis then you are standing still and the world, and your organization, will grow beyond you. So continually look for ways to improve your own processes.

As you can see there is a lot to business analysis, inside and outside of software development projects. The Business Analyst cannot stand still in their way of doing things. The business analysis profession, the business environment and your organization are continually changing and growing. The only constant in the universe is change. The Business Analyst professional must change also. Grow in your understanding of business processes, your profession, your organization and the environment in which it operates. Stay up on the latest trends and look for ways to incorporate the way you do your business analysis activities.

Don’t forget to leave your comments below.

Filling your Toolbox: Factors that Influence BA Skill Development

Written by Angela Wick on September 17, 2013. Posted in Articles.

Everyone has a career toolbox—a collection of tips, tricks, skills and techniques. The tools accumulate over time:

Some tools come with the toolbox: innate gifts, talents.
We purchase tools: training, degrees, memberships in professional organizations.
Other people buy or donate tools: employers offer training, mentors, experience.
If we are inventive, we build our own tools.

Most BAs have a few standard tools they use frequently, but many of the tools just lay in the toolbox, unused. We don’t schedule time to check inventory, get rid of old tools, determine what is missing or anticipate future needs. We don’t fill our toolboxes efficiently or effectively.

BAs need to fill their tool boxes, but they shouldn’t fill them passively—just accepting the opportunities presented. Instead, BAs should choose, with intention, which skills they add.

Three factors influence this purpose-driven approach to BA skill development:

Awareness
Desire
Support

If individuals and organizations cultivate these attributes, BA skill development efforts will be effective, efficient and will provide lasting value.

Awareness

BAs can’t develop skills effectively unless they understand the strength and value of their current capabilities.

So, what’s the current state of your BA toolbox?

Do you know your strengths and weaknesses?
Which competencies have you mastered?
Which competencies are missing?
Which skills will future projects require?
Which skills will be required for career advancement?
Which skills are valued by your organization?
What business/technology/cultural trends will influence the value of certain skills?

Essentially, you need to be aware of your own capabilities, but also understand how external entities value your skills.

Here are a few ways to cultivate awareness:

Complete a BA skill assessment. You can do this informally by creating a comprehensive list of BA skills from sources like the BABOK and then rating your mastery of each skill on a scale of 1-5 or you can use the IIBA’s competency assessment tool.
Track stakeholder feedback. Make note of verbal and non-verbal feedback you receive from stakeholders. Find patterns and trends that indicate your strengths and weaknesses.
Maximize your annual evaluation process. For those lucky enough to receive meaningful performance reviews—take advantage of the opportunity—get honest feedback from your manager.
- Ask about your reputation.
- Define skill-related goals.
- Suggest new skills that would benefit the organization.
Evaluate training provided by your organization.
- Why is the training being offered?
- How can you apply the skills in your current environment?
- What are the expectations upon completing training?
Compare yourself to others. Choose a few BAs you admire or consider successful. Identify their strengths. Determine if developing similar skills would help you achieve your goals.
Review industry job descriptions:
- Which skills appeal to you?
- Which skills seem to be in highest demand?
- Do you have all of the skills required for your dream position?

Desire

Since the BA role centers on facilitating change in an organization, BAs need to be willing to change themselves too. BAs can’t develop skills effectively without the desire to learn, grow, experiment or improve. Without desire, BA skills get old and begin to lose value.

A BA with desire:

Advocates for training, mentoring or experiences that will bring value to the BA role and the organization.
Takes risks by experimenting with new skills and techniques.
Practices new skills until they see results—do not just try skills once with ho-hum results and not try again.

An organization wishing to cultivate desire:

Establishes a vision for the BA team.
Identifies and communicates the skill set needed to achieve the vision.
Communicates expected results.
Provides answers to: “How will new skills address my pain and challenges in my job?”

Support

Some BAs have awareness and desire, but find skill development limited by the leaders in their organizations.

Many BAs report to technical or business managers that do not have a clear understanding of the BA role. BAs in this position often struggle to obtain meaningful skill development opportunities.

In organizations where skill development is a priority, this is what you might experience:

Leaders encouraging the use of new tools and techniques.
Leaders modeling desired behavior by experimenting with new skills.
Stakeholders, team members, and peers accepting change and encouraging experimentation.
Skill development plans with flexibility to accommodate learning styles.
A strong team atmosphere.
A healthy respect for the lessons-learned from failure.

Can you think of other factors influence BA skill development? Please leave your comments below.

Don’t forget to leave your comments below.

It’s the End of the Business Analysis World as We Know it? Part 6

Written by Steve Blais on August 20, 2013. Posted in Articles.

Being the serialized story of Brian Allen and Ann Brady, business analysts, and their Adventures in the New Oder of Agile

Excerpted from the forthcoming book from John Wiley, The Agile Business Analyst due out the end of 2013

Chapter 6: Wherein Verna addresses the business analysts and their final fate is known while Brian searches for the right theme song.

Brian saw Ken and Sandra walking slowly toward them from the end of the corridor with measured pace. He and Ann were walking toward them with the same measured pace. The corridor had emptied out. Brian heard the whistling trill from the theme song to “The Good, The Bad, and the Ugly” echo in his head as they approached each other. He immediately thought that he was at a disadvantage since he still had his backpack slung over his shoulder. “I got my updated resume in my backpack, just in case,” Brian whispered to Ann as they walked. She nodded.

Then Ken and Sandra turned to their left down an intersecting hallway. Brian and Ann turned left seconds later to follow them. Still no words were spoken. It was the way of Verna. The whistling in Brian’s head was now replaced by the bubbly, somewhat inane tune, “We’re off to see the Wizard…” and he looked at the floor to see if there were yellow tiles.

They turned left again and then right along passageways and halls that seemed to become narrower as they proceeded. Brian realized that he and Ann were in a sector of the Organization’s Headquarters that they had never been in before and didn’t even know existed. The theme song to :”The Twilight Zone” snaked into Brian’s brain replacing the jovial image of Oz with the dour visage of Rod Serling.

Finally they came to The Door. Sandra pressed a button and passed her badge over a green light and The Door opened. Inside was a large well lit antechamber with several desks with people busy doing things people do at desks, a couple of conversation areas and three doors leading to other offices. Brian wondered if he were going to get to pick which door Verna was behind.

Sandra led them to the left hand door and opened it after knocking. When the door opened everyone behind the desks stood up at attention. Ann, Ken and Brian entered the room. Sandra did not. She closed the door behind them. This was Verna’s office.

“Welcome, I’ve been expecting you,” came a disembodied voice that was strong and authoritative but seemed to carry with it a smile of understanding and empathy. The three looked around the large office, darkened by heavy drapes over the windows, and could not immediately see the source of the voice.

“Please, have a seat.” There were three chairs in front of the executive desk in the center of the room and an empty black executive swivel chair behind it. Then they saw Verna standing at the corner of the desk.

When Brian saw Verna he realized why she was rarely seen around the organization. She was 4’9” in height and was barely visible behind the large desk. He imagined her sneaking unseen around the corridors of the organization, and the theme song to The Pink Panther crept into his head. Verna pulled herself into the executive chair and they could see her clearly. She had short page-boy length hair and was of indeterminate age although her face spoke of volumes of experience in the corporate political wars.

“First of all,” Verna said. “I want to let you know that I am completely in favor of the entire concept of agile: agile software development, agile management, agile organization. I have been in favor of it long before it was agile. Back in the day being agile as you describe it now was just business as usual. We in the corporate world have lost touch with our ability to respond, to be flexible, to take chances and risks, and to make things up as we go. Management has a few set backs or failures along the way and suddenly we are all worried about risk management and making sure that there is a paper trail we call documentation to absolve us of blame. We all had the agile spirit at least once, when we were start ups – as organizations or when we first started up in the business field. But as things went on we lost it. So, now if we have to call it agile and take a slap in the back of the head or a glass of cold water in the face to wake us up, then I’m all for it. And that includes all of the precepts, such as removing the business analyst from between the business person with the problem and the development team with the solution.”

This pronouncement deflated Brian and Ann. Brian let his backpack slide to the floor next to his chair.

“You don’t need to pull your resume out of the backpack as yet, Mr. Allen,” said Verna with a smile.

Brian looked up and over at Ann. His face said “how did she know that?” Her faced responded with “Lucky guess, maybe?” He noticed out of the corner of his eye that Ken was smiling in apparent victory.

“I am talking about removing requirements as we know them: This absurd process of creating long documents followed by lengthy confirmation processes and approvals by executives who don’t even read the bloody thing, and then making changes which also require confirmation and approval are absurd. We need to be more flexible, fluid and responsive, and requirements documents do not get us there. There is too much time spent in arguing about how a requirement is written and the meaning of the words in the document than in defining what is necessary to be done to solve the problem.”

Now Brian could see Ken’s grin growing wider. Ann was looking down and nodding. Brian found that there was nothing that Verna was saying that he could disagree with. He had felt for a long time that defining requirements was a small and sometimes trivial part of his job, but he had always assumed it was necessary. After all, what is a business analyst without requirements? The Business Analysis Body of Knowledge seemed to be all about requirements as the Project Management Body of Knowledge was all about structure and documentation. And he knew; he had his PMP although he wasn’t sure anymore why he had it.

“But,” said Verna, interrupting Brian’s reverie, “That does not mean at all that we are considering eliminating the business analyst. The business analyst is vital to the success of this organization, more so than the technologists who develop the software solutions.” She aimed her last comment at Ken whose smile froze on his face and then fell into his lap. Ann looked up at Verna with a question on her face.

“Let me highlight the job you two have been doing for the organization. It hasn’t gone unnoticed,” Vern continued. “You have helped Marketing, especially Dmitri, many times over the past by ensuring that their initiatives mesh well with the rest of the organization and are aligned with our overall strategic goals. Marketing has a reputation for focusing only on what is necessary to achieve their goals without regard for the rest of the organization. And that is good. Without them we don’t go anywhere. But we need someone to provide an overall business view to what they are doing, and you have been doing that.

“The information you assembled and the analysis you provided on our strategic build or buy situation is going to save us a lot of money and contribute significantly to the success of Backbone. There will be less coding that has to be done…sorry, Ken…which means that parts of the overall system will come up sooner than expected giving us significant competitive advantage and return. And we thank you for those efforts.”

“We were just doing our job,” muttered Ann, still bewildered at Verna’s comments.

“And that, my dear, is my point, you are doing your job,” responded Verna. “I also personally like the way you keep asking questions, even in the face of rampant enthusiasm, especially on the part of Marketing. You also challenge the technologists’ assumptions and the ‘no problem syndrome’. You apply upfront critical thinking which has saved this organization thousands in miscommunication and rework costs. I know anything “upfront’ is considered suspect by the agile authorities, but I tend to be old school and believe that any process that makes things work more efficiently is worthwhile no matter where it occurs or what you call it. And I particularly like the way you do it without a lot of paperwork, overhead or ceremony.

“You facilitate meetings and get problems addressed and solved. You effectively deal with conflicts, especially between IT and the business units and between the business units themselves. Unfortunately many of those conflicts are about how requirements are phrased, but we may have eliminated that source of conflict with this agile product development approach. You seem to be able to get the best out of people when you are around, helping them achieve their goals. You were instrumental in providing the information and argument that convinced Carl that his precious system needed to be replaced and not maintained.

“You have taken the time to keep up to date not only on technology so you can understand the technologists, but also the business side so you understand business jargon. And I’ve noticed that you don’t spend time just translating one set of jargon to the other, but facilitate the interactions between the suits and the nerds so that each will become more familiar with the other’s domain. Very good. Of course, it has led to the current demand by Ken and his cronies that you be removed from the ‘middle’. So you unwittingly were part of your own demise in that regard.

“I also noticed that people around the organization seem to call on you when they have problems and you are able to help them define what their real problems are and help them come up with solutions, even when those solutions do not involve software development or even IT at all.”

“But they work for IT,” Ken pointed out. “They should be defining IT solutions.”

Verna affixed a withering stare at Ken. He seemed to shrink in his chair until he seemed to be shorter than Verna. “They do not work for IT, sir. They work for the organization.”

Brian and Ann shared glances. They never assumed anything else.

“The bottom line is that business analysis is here to stay. What you do is the real backbone of the organization. You provide independent and objective information to the decision makers, define and solve business problems, improve business processes and make a multitude of other contributions..”

Ken appeared to have one more protest up his sleeve. “I was given the direction by Vince and others that we all have to be agile. The entire organization is going agile.”

“Yes, I believe that is true, and as I clearly stated, I am in agreement with everyone going agile. But these business analysts, for all intents and purposes, sir, are already agile. They are responsive, flexible, focus on the problems of the entire organization, collaborate at all times and facilitate collaboration wherever possible, and work to get the business customers with problems and the IT or other teams with solutions together to add value to the organization. How much more agile can you get, sir? I believe if you go back and look at your recent history, you will see that business analyst laid the groundwork for successful agile organizations.

“I would say, Mr. Allen and Ms. Brady, that you are certainly agile as far as the organization is concerned, at least as agile as the developers working with Scrum. So, since IT has decreed that they don’t seem to have any use for you, replacing your requirements definition duties with the agile process, then what I want is that you work directly for me. You will remain business analysts. And your scope will be the entire organization. I envision an entire team of business analysts moving the organization strategically, tactically, and competitively forward”

There was a long pause as Brian and Ann let the directive sink in.

“I have spoken,” commanded Verna, ending the meeting. \

Outside in the hallway, Ken nodded to them and bid them well and said that it was clear that he would be working with them on upcoming projects, including Backbone. He did not seem to bear any ill will. In fact, Brian almost sensed that Ken now welcomed their participation in the agile community as business analysts. But then, that remained to be seen.

As they stood in the lobby of Verna’s offices, Brian looked at Ann. “Do you know the way back?”

Ann replied, “I left the bread crumbs.”

“Looks like everyone is safe.”

“Yes, we did it. And we got to meet with Verna.”

“Hey, did you notice? No strange silences and eerie feelings when you said her name.”

“Yes. I wonder if it’s just because we met her or because we now know her real stature. She’s small, you know?”

A disembodied voice came out of hidden speakers someplace near where they were standing in the lobby of Verna’s area. “I heard that, Ms. Brady.” It was unmistakably Verna. They looked at each other and scurried out of the area and through The Door.
“How did…?” whispered Brian. Ann shrugged.

“Well for one thing,” said Brian, still keeping his voice soft as they moved down the hall. “This is going to be really challenging and very interesting.”

“Yes. And we love it that way. We are, after all, business analysts.”

Don’t forget to leave your comments below.

Cycles of Change: Agile, Waterfall and Continuous Improvement

Written by Julian Sammy on August 13, 2013. Posted in Articles. 1 Comment on Cycles of Change: Agile, Waterfall and Continuous Improvement

When version 2 of A Guide to the Business Analysis Body of Knowledge® was released about five years ago, the Business Analysis Planning and Monitoring Knowledge Area discussed a spectrum of project types that range from plan driven to change driven.

Agile methodologies were not yet established, and were described as change driven. This was in stark contrast to traditional Waterfall projects.

Volunteers working on version 3 of BABOK® Guide – now undergoing a practitioners’ review and expert review — are using the Business Analysis Core Concept Model as a foundation. They found that approaches to controlled transformations of organizational systems had the same fundamental purpose: to manage the risks associated with the complexity of a change.

For logistically complex changes, longer change cycles are established, with up-front planning to identify potential problems, establish risk management practices, and then to take considered action. This is particularly useful for big, well-defined needs, and high-risk situations. It is very hard to build a dam using Agile.
For logistically simpler changes, rapid cycle times are established, with continual reprioritization to target short-term value delivery. This is particularly useful in unstable, dynamic situations. It is very hard to maintain a bridge using Waterfall.

This analysis led the team to generalize and refactor the spectrum of “change driven to plan driven” in BABOK® Guide version 3 The new text discusses three concepts: cycles, complexity, and formality.

Cycle durations describe the typical time frame for delivery of a solution to a stakeholder. This directly constrains many options for the business analyst, including the timing of business analysis work, which techniques may be used to perform business analysis tasks, the degree of formality possible, and the levels of complexity that can be addressed. The team found most changes deliver value in one of three ranges.

Value Delivered in Days to Weeks: Continuous improvement and Agile are best known for operating with cycles of this duration, but many support or maintenance changes also have short cycles. While Agile is focused on delivering working code in very small increments, physical objects can also be built in this timeframe, particularly with the advent of 3D printers.
Value Delivered in Weeks to Months: Iterative changes are common, especially as “phases” of a project. Phased projects have many small waterfalls, rather than one big one, and can be thought of as a program of many small projects.
Value Delivered in Months to Years: Traditional waterfall is most appropriate for changes that are logistically complex. Some complexities result from having long timelines built into the change, as is found in highly regulated industries (such as financial services, power generation) or research (such as pharmaceuticals and aerospace engineering). In these cases, there may be no “minimum viable product” that can reasonably be treated as its own change.

The Complexity of a Situation can drive the cycle duration that is appropriate for a change. Factors that can increase the complexity of business analysis efforts include:

number of stakeholders affected by the solution,
number of stakeholders involved in making the change (change agents),
number of organizational areas affected,
number of systems affected,
number of technologies or tools affected,
amount and nature of risk, and
uniqueness and uncertainty of requirements.

Agile approaches are most effective when the complexity in any single cycle is quite limited; there simply isn’t the time to communicate with a large number of stakeholders, or manage a large logistical effort. Agile tends to be more effective at making less complex changes, particularly when the situation is rapidly changing; course corrections are built into the short cycle time. Longer iterations increase the risk of irrelevance—but some changes take time to complete.

Agile approaches can be combined with longer cycles. For example, some aspects of a large, complex change may be developed using Agile approaches.

As the complexities increase there can be thresholds where the nature of the change transforms into something altogether different. This is a common experience in communications, where the nature of communication is fundamentally different at different scales; a message to hundreds of people cannot use the same tools as a message between two people.

The formality of business analysis work is also related to the duration and complexity of each change cycle. For a close-knit innovation team with six people doing everything in one room, requirements may be largely composed of diagrams on the walls, and pictures of those diagrams—but most situations demand more structure and consistency in the outputs from business analysis work. Templates, document repositories, and requirements management tools may all be used to increase the formality of the requirements. Approvals and commitments to act on requirements will be related to the formality of the requirements themselves.

In many cases, Agile development and Continuous Improvement work can be pursued with relatively informal requirements, and relatively informal approvals. Requirements still need to be complete—measurable, clear, traceable, and so on—and approvals must not be assumed.

Change Cycles and You

There are general principles for choosing the right cycle duration for a change:

Given the complexities of the situation, minimise cycle duration and formality of outputs.

In other words, shorter cycles are more likely to deliver more value more quickly, unless they deliver no value at all.

Don’t forget to leave your comments below.

Software Solutions – Should I Outsource, Buy or Develop in House?

Written by Tatiana Drapkin on March 19, 2013. Posted in Articles. 1 Comment on Software Solutions – Should I Outsource, Buy or Develop in House?

When it comes to software solutions there are usually three approaches a company can take to achieve the intended result. The job to develop the desired product can be outsourced to another company, the product can be bought as an off-the-shelf solution or developed in house. As with any solution there are pros and cons to each approach.

This article lists reasons why company might choose a particular path and provides guidelines to follow, when taking a particular direction.

Outsource Option

There may be different reasons for choosing this option.

The company may not have internal expertise to develop the solution.
The company may have the expertise, but all resources may be assigned to other initiatives and solution cannot be developed internally during a particular timeframe.
The company may have the expertise and even the resources to do the job, but cannot work on the project due to regulations. For example, to be self-clearing, a Canadian broker company has to become a member of various organizations such as CDS, CDCC, DTCC and Fundserv. All self-clearing processes need to be approved and then audited by IIROC. A company may choose to outsource clearing operations and lease all necessary software products from clearing companies such as Penson, NBCN, Fidelity.

There are common guidelines a Business Analyst will usually follow, when choosing the vendor for the outsourced solution.

Work with the Project Manager to establish vendor’s role in the project. Are they going to be involved in requirements gathering process? Are they going to be doing quality control, quality assurance and user acceptance testing? Are they going to be supporting the software solution, when it is released to production? Are they going to host the solution?
Contact multiple companies. Contacting more than one vendor gives you the opportunity to compare different parameters and to have more bargaining power, when negotiating costs. Do not go overboard though. Three or maximum four vendors will give you enough information and will not overcomplicate the analysis process.
When contacting companies, it is a good idea to provide them with template to fill out with all the questions in it. Otherwise you will get answers in different formats, which will complicate the comparison and decision making process.
Pay attention to vendor location. If vendor is located in a different country, ensure that they are able to travel to your site and ensure travelling costs are within company’s acceptable range.
Discuss with the vendor communication methods for day-to-day communication and meetings.
Ensure vendor is aware of your technology preferences. If your company is a Microsoft shop and vendor delivers solutions in Java, this may not be a good match. Ideally you want to ensure there is consistency in technology approaches, even when solution is outsourced.
Last but not least, get a feel of the company. How do they communicate? Are they bureaucratic and slow to move or are they energetic and open? Are they willing to work with you on initial stages of the project or are they pushing to sign the contract and then get to business? Have they delivered similar solutions before?

Buy Option

Buying of-the-shelf software product will work best if desired product’s features are very common and well defined. Development, maintenance and support costs will be significantly reduced compared to options of building the product from scratch or outsourcing the development. Advantages of lower costs may sound compelling, but because business needs are usually unique, it may be difficult or even impossible to find an off-the-shelf solution that would satisfy every requirement.

Listed below are guidelines to follow, when selecting off-the-shelf solution.

Off-the-shelf does not mean solution cannot be customized. Find out customization options. Are the flexible enough to satisfy business requirements?
There may be different licensing options and different modules to choose from. Ask for product demo. See it in action before making the decision. Not all of its components may be needed and there might be an option to exclude them, reducing the costs.
Off-the-shelf solutions most likely will receive upgrades. Be clear on upgrades schedule and on how they will be delivered and installed.
Ensure you understand how solution will be supported. Will there be a dedicated support contact? Will support be available 24X7? How quickly production issues will be resolved?
How long old versions are supported? Will you be forced to upgrade?
How much training users will need to start using the software and are there any training programs available? Are there user guides available?
The solution may start as stand-alone, but with time it may become necessary to integrate it with other internal systems. Understand if off-the-shelf solution has APIs to support the integration.
Get a buy-in from the sponsor and key stakeholders. They need to understand that off-the-shelf solution will never have the flexibility to have ad-hoc enhancements and fixes. It may be customized only to a certain point. Business processes should adjust to fit the software because off-the-shelf software cannot adjust to fit every single unique business requirement.

Develop in House Option

Developing solution in house is a great option, if the company has expertise and resources to do the job. Internal development will help achieve great control over product functionality as well as technology, development and QA approaches. The communication will be easier than with outsourcing option because all project teams will likely be co-located and may even already know each other. The training and support will also be less complex because of internal expertise. In addition, solution will be relatively easy to integrate with other internal applications because it will reside in company’s internal network and will most likely follow the same technology choices as other internal applications.

One con of developing the solution in-house can be the cost of labor. Offshore development companies may do the development for only a fraction of the cost. This being said, it is always important to take into consideration all costs. Offshore development may require extra management and communication/travelling overhead, which can quickly add up, making the overall cost higher than originally anticipated. It may be a good compromise to do the development in-house, but outsource quality assurance and support functions.

One obvious thing to remember is that there will never be a 100% perfect option. There are pros and cons to each solution. Initial project analysis is the key to success, where “success” is defined as selecting the solution (based on all the analysis) that will ultimately have more pros and less cons than other available options.

Don’t forget to leave your comments below.