Tag: Planning

How to get started with Business Analysis?

Written by Jai Manral on April 11, 2018. Posted in Articles.

As a business analyst you might have worked across different projects either from the inception or you might have joined the project in between, or it may have been a maintenance project.

The one question which we always have is – where to get started?

You might have read the arduous guides to figure it out, but it’s not only time consuming but pretty difficult to follow when you are looking for project specific skill sets. Well there are no specific rules to follow but a quick guide to check on some of the most important aspects of business analysis skills are below:

Know your stakeholders – it doesn’t matter what sort of project you are working on, you should always know about your stakeholders. Well there can be many stakeholders in a project and to identify them you can create a stakeholder analysis document. This is a simple excel sheet where you can list down the name, business title/position, department, project role and any other relevant details as specific to your project. This will come in handy throughout the project lifecycle and beyond.
Just knowing your stakeholder is not enough- Ok so now you have the list of all your stakeholder’s, you ask what’s next? Well not all stakeholders are important or influential in a project. The key here is to identify whom to listen to? For this you can create a stakeholder matrix mapping RASCI elements defined below against the names of stakeholders from stakeholder analysis document. Here RASCI acronym stand for
- Responsible – The one who owns the project/problem. Highly influential.
- Accountable – The one who acts as an approver. Usually signoff the work.
- Supportive – The one who is your friend. Can provide resources or help but may not be influential in a project. Kind of a helping hand.
- Consulted – The one who knows his stuff and you may require to seek his/her help often.
- Informed – The silent one, just keep him/her informed about the project.
Deciding on elicitation techniques – There are numerous techniques for electing requirements such as brainstorming, interviews, workshops etc. Well this is the time you can visits your stakeholder matrix to know about the stakeholder and his/her influence on the project. For example, a VP operations guy can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your TO BE application. You may want to interview him for his point of view, concerns and thought process but might not invite him for a brainstorming or workshops sessions which may consume lot of his time from his already busy schedule. You must check the availability, influence level, position, interest level before making the choice of elicitation techniques.
Doing your homework – Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of the them, if not all, improvement (aka digital transformation) projects do not start from the scratch in a way that, the business processes are already defined and followed, these are AS IS processes. For these projects, client may have the loads of documents depicting the process/ applications designed and other artifacts of the current application(s). Analyzing these set of documents, process flows, business rules is cumulatively referred to as document analysis. As a business analyst, you should have keen eye on details, and should note down any information which is ambiguous as any assumptions here may cause dearly in the future. So be prepared before getting out with stakeholders as this will save everyone’s time and you can decide better which stakeholder is required and what elicitation technique to use.
Are you sure of the requirements? – Well chances are that you may have heard this statement before from your team members. Now assuming that you have gathered the requirements, one of the most essential part of requirement management is to analyze them. Like document analysis in previous step, which may or may not be part of a project, this is a mandatory exercise every business analyst should follow no matter what kind of project he/she is associated with. Analyzing requirements means finding any anomalies, highlighting assumptions and constrains, decomposing requirements into functionalities, classifying the requirements and figuring out what is important and what’s not. The higher the concentration and time spend on this stage lesser will be the surprises at the end. So keep a hawks eye on it.
It’s time to prioritize the requirements – So you have analyzed and documented the requirements, now depending on the kind of project and SDLC you follow, you may have to choose between requirements. This is mostly part of AGILE methodology where we deliver functionalities of a product/ application in an incremental fashion. Though you will have sponsors/ product owners but as a business analyst you should be aware of each requirements, its implications and need to the business. A well thought out plan on requirements delivery in phases is as crucial as the whole project. For example, considering e-commerce website example, what will be the point of delivering a functionality where users can add products to shopping basket but can’t proceed to buy, rather giving user an option to create wish list in one phase and delivery shopping cart and buy functionality in another makes more sense.
Finally can you trace the requirements back– This is required during the testing phase as well when there are difference in the said requirements and finished product. As a business analyst you should be able to trace the requirement to its origin when required. The IT is ever-changing space and there might come a time when someone else will access your work to define a new change. So a well-documented and traceable requirements will save both time and energy and of course the frustration which we usually witness ourselves when going through missing/unambiguous requirements from others.

Artificial Intelligence: Send in the Analysts

Written by Peter Williams on April 5, 2018. Posted in Articles. 1 Comment on Artificial Intelligence: Send in the Analysts

Over the coming years, nearly all analysts across all sectors and industries will likely be involved in some capacity within an Artificial Intelligence (AI) or Robotics programme.

More businesses are now looking how their company can benefit from what this new technology has to offer, and it will be the analysts that will help in both the direction and strategy. One common mistake made by many organisations is viewing AI as a technology-led activity. AI is technology driven, but it should be the business that is pushing its adoption, as it is only truly effective if it is built on sound business knowledge and functional designs.

Whether a company adopts it now or later, the implementation is inevitable. Failing to do so over the next ten years will likely see those organisations lose any competitive advantage that they might currently have. Rather than seeing AI as something that will replace, I like to view it as something that will enhance or complement existing processes. Helping to free up valuable resources, by replacing tasks that are often simple, time-consuming or resource intensive with more efficient and cost-effective robotic operations. The newly found freed up time will enable key staff to refocus to do more and offer greater value within your organisation. Often competitive advantage comes from doing things differently from that of your competitor, so by having your staff focus on value-added processes, you will likely reap the rewards.

When implementing some form of Robotics programme, it should typically include two key ingredients; the first is that the programme should be business-led, as that is where the bulk of the work will be carried out and secondly that the analysts play a key strategic role from the outset. In the past, not all companies have followed this approach, as the allure of saving millions of dollars and large-scale headcount reductions, can get leaders excited, but this approach will likely end up being a costly mistake. With leaders rushing to get AI within their organisations, it is important that before engaging with expensive consultants or even investing in technology, that analysis is carried out around what technology is available on the market and how it could be used or effectively adopted within the organisation. Some of the common mistakes could be avoided by following five simple steps.

#1 Send in the analysts

Some robotics programmes are more systems led, meaning analysts may only be involved at a later stage in the process and often when the software and platform have already been selected. In my opinion, engaging with the analysts this late in the process is a big and costly mistake. Before even looking at the available technology, all of the processes across the organisation should have been identified, assessed and quantified. Nearly all analysts within any organisation, industry or sector will be able to quickly evaluate and structure the processes, identifying any potential problems and proposing viable solutions. All of which would save both time and money in the long term.

#2 Knowing what to look for

Knowing what to look for will depend on nature of your business. The most obvious places to start is with the areas that have the largest amount of resources and processes, most likely within your operational areas. Following what your people do, by going back to the floor and watching how things are carried out can help. Utilising your subject matter experts (SMEs) is a must, however by looking at the processes first hand, provides added benefits, as there might be some situations or elements that even SMEs were unaware had changed.

During your back-to-floor exercises, you will quickly be able to begin identifying potential qualifying processes. When doing this exercise, it is important that you categorise each opportunity into one of three complexity categories

Straightforward and easy to replicate – for processes that are relatively simple and follow a sequence or series of actions. The key factors are the inputs and outputs of the process. If for example, the inputs are digital, meaning that physical data (text) is entered into a system which can be easily understood by a computer system; then you will likely be able to do something with those processes very quickly. From an implementation perspective, any opportunities identified now would probably form your basic automation stage or phase.
Medium complexity and requires specific functionality – these processes may be straightforward, however, if an assessment or decision needs to be carried out that requires specific knowledge or experience, then it will likely take more time and effort to implement. Like the first category, inputs and outputs are crucial. If the process and decision trees are straightforward, but the process inputs are made up of scanned paper documents, then you will likely have to look into additional functionality such as Intelligent or Optical Character Recognition (I/OCR). OCR has a high extraction rate for printed text, as the text within the image will likely use a recognisable font face. However, you have also to consider other factors such any other languages and character sets on the documents your company receives. ICR has a lower success rate, as handwritten notes are harder for a system to interpret, but most organisations are seeing less written communications in this modern age. The last thing to consider within this group is the structure and design of the how the information is gathered. If it is a form, for example, you could redesign the structure to increase the I/OCR extraction rate by making it more machine friendly. Within your programme, the opportunities identified now would form your advanced or enhanced automation stage or phase.
Challenging and requires experience – the last category, will likely reap the biggest rewards but will also probably be the most difficult to implement. You are likely at this stage to be more within the AI space of development. Within AI, you would typically have to create a series of workflows, with decision trees. Once all built, you would need to run through (as many as possible) cases or examples, recording the likely outcomes or decisions. Based on these examples, the AI system will be able to look for the correlation between the outcome and the information provided and from that, create a probability for each scenario. You can define tolerance levels within the systems, however, should say, an assessment carried out that has a probability score of 90% or more, you could program it so that the robot would complete the series of actions or steps automatically. The opportunities identified would likely form that AI/cognitive stage or phase within your programme.

Whatever process you are looking at, it is important to write down your observations, whether the process is value added or not; if not, can it be phased out, how long on average does the process take, how many people are doing it and any associated costs

#3 Scalable and flexible

Once you have your high-level analysis, this is when you should begin looking at the various technology on offer, based on the requirements and functionality needed within your organisation. It is likely that the technology that you will use going forward will be made up of a series of software or applications. Whether you purchase it all from one supplier or use a variety of vendors, it is important that whatever the approach you adopt, that you buy a scalable and flexible solution.

By minimising your upfront costs for implementation, you will be able to create a Robotics programme, that is controlled, and that will reap sufficient benefits against any costs initially outlaid. It is also important that when you are negotiating with your technology provider that they are pricing from a strategical perspective, rather than a tactical one. You may only need a small amount of technology now, but the demand will grow as the programme implements each phase. The technology needs to be priced accordingly and flexible to allow for the growth, as and when you need it.

The risk you run by buying a technology platform that is more based on your future needs up front is that you will likely be chasing bigger benefits upfront to offset the costs and could ultimately result in delays, increased costs or even failure.

#4 Benefits based on the long, not the short term

By purchasing a platform that is both scalable and flexible, would likely mean that your costs are kept to a minimum, and any benefits you realise will be done in a controlled and organised manner. When scoping the benefits, it is important to be realistic, but also to factor in aspects such as dual running. Though most Robotics solutions are robust, there is always going to be teething problems and issues to iron out inevitably. If you extend your dual running period for as long as possible, then the new technology could be continually improved, and at the same time ensuring that your customers are not affected. Remember by keeping the technology costs aligned to what you need when you need it, means that you are not under pressure to make significant savings upfront.

#5 Phased implementation

By now you know your business needs and the opportunities that exist within your organisation. By purchasing a platform that is scalable and cost-effective, means it should not adversely affect your business case and as a result means that you can provide a more stable and controlled deployment within your business. Though the approach and analysis are sound, we need to now look at the phased implementation.

Basic Automation– this may not provide you with significant savings, but it will provide a small scale platform and a proof of concept. During this time, you should begin to hone the skills within your organisation with regards to robotics, and your employees will be able to interact and engage with the live processes. If the change is managed effectively, you will likely see staff advocating robotics going forward, even offering up suggestions for further robotics opportunities
Advanced or Enhanced Automation – at this phase your organisation would be getting used to robotics and automated processes. Adding new functionality and capabilities to your processes would enable significantly larger savings across the business. At this stage, if a review was carried out around improving sales and the customer experiences, you should have the opportunity to free up your experienced and valuable resources to help both enhance and create opportunities to expand your business.
Artificial Intelligence or Cognitive Reasoning – once you have workflows and processes in place, in theory, you can turn on the learning capability that exists within your AI programs. Allowing your AI to watch, observe and gather large amounts of data, will prove valuable in the long term, as the larger the data set available to the AI, the higher the probability success rate

Final Thoughts

The opportunities that exist through Robotics are not just for large corporations and can also be easily implemented within small to medium-sized businesses. Understanding your business is key, and this is where the engaging analysts at the right time, ensures a successful implementation or deployment.
Robotics or AI should not be seen as something separate and to be placed within a separate specialist area or function. Though you will likely have people that will become experienced in the implementation of automated processes, Robotics itself should be accessible and embedded across your entire organisation.

Though change can sometimes be daunting, Robotics, in the long run, will complement your existing processes and help you create differentiators within your business to build a competitive edge. For many the perspective of a robotic future is daunting though ultimately it should be seen as positive, rather than negative, as with it will come a broad range of benefits and applications that could make daily life much easier and simpler.

How to get started with Business Analysis?

Written by Jai Manral on March 29, 2018. Posted in Articles. 1 Comment on How to get started with Business Analysis?

As a business analyst, you might have worked on different projects either from the inception, or you might have joined the project in between, or it may have been a maintenance project.

The one question which we always have is – where to get started?

You might have read the arduous guides to figure it out, but it’s not only time consuming but pretty difficult to follow when you are looking for project specific skill sets. Well there are no specific rules to follow, but a quick guide to check on some of the most important aspects of business analysis skills are below:

Know your stakeholders – it doesn’t matter what sort of project you are working on, you should always know about your stakeholders. Well, there can be many stakeholders in a project and to identify them you can create a stakeholder analysis document. This is a simple excel sheet where you can list down the name, business title/position, department, project role and any other relevant details as specific to your project. This will come in handy throughout the project lifecycle and beyond.
Just knowing your stakeholder is not enough- Ok so now you have the list of all your stakeholder’s, you ask what’s next? Well, not all stakeholders are important or influential in a project. The key here is to identify whom to listen to? For this, you can create a stakeholder matrix mapping RASCI elements defined below against the names of stakeholders from stakeholder analysis document. Here RASCI acronym stands for
- Responsible – The one who owns the project/problem. Highly influential.
- Accountable – The one who acts as an approver. Usually signoff the work.
- Supportive – The one who is your friend. Can provide resources or help but may not be influential in a project. Kind of a helping hand.
- Consulted – The one who knows his stuff and you may require seeking his/her help often.
- Informed – The silent one, just keep him/her informed about the project.
Deciding on elicitation techniques – There are numerous techniques for electing requirements such as brainstorming, interviews, workshops, etc. Well, this is the time you can visit your stakeholder matrix to know about the stakeholder and his/her influence on the project. For example, a VP operations guy can be an influential person for a specific project but may not be the one to give you detailed process knowledge for your TO BE application. You may want to interview him for his point of view, concerns and thought process but might not invite him for a brainstorming or workshops sessions which may consume a lot of his time from his already busy schedule. You must check the availability, influence level, position, interest level before choosing elicitation techniques.
Doing your homework – Not all projects start with calling stakeholders for meetings, sending them surveys, or organizing workshops. Most of them, if not all, improvement (aka digital transformation) projects do not start from the scratch in a way that, the business processes are already defined and followed, these are AS IS processes. For these projects, the client may have the loads of documents depicting the process/ applications designed and other artifacts of the current application(s). Analyzing these set of documents, process flows, business rules are cumulatively referred to as document analysis. As a business analyst, you should have a keen eye for details and should note down any information which is ambiguous as any assumptions here may cause dearly in the future. So be prepared before getting out with stakeholders as this will save everyone’s time, and you can decide better which stakeholder is required and what elicitation technique to use.
Are you sure of the requirements? – Well, the chances are that you may have heard this statement before from your team members. Now assuming that you have gathered the requirements, one of the essential parts of requirement management is to analyze them. Like document analysis in the previous step, which may or may not be part of a project, this is a mandatory exercise every business analyst should follow no matter what kind of project he/she is associated with. Analyzing requirements means finding any anomalies, highlighting assumptions and constrains, decomposing requirements into functionalities, classifying the requirements and figuring out what is important and what’s not. The higher the concentration and time spend on this stage lesser will be the surprises at the end. So keep a hawks eye on it.
It’s time to prioritize the requirements – So you have analyzed and documented the requirements, now depending on the kind of project and SDLC you follow, you may have to choose between requirements. This is mostly part of AGILE methodology where we deliver functionalities of a product/ application in an incremental fashion. Though you will have sponsors/ product owners as a business analyst, you should be aware of each requirement, its implications and need to the business. A well thought out plan on requirements delivery in phases is as crucial as the whole project. For example, considering e-commerce website example, what will be the point of delivering a functionality where users can add products to shopping basket but can’t proceed to buy, rather giving the user an option to create a wish list in one phase and delivery shopping cart and buy functionality in another makes more sense.
Finally, can you trace the requirements back– This is required during the testing phase as well when there are differences in the said requirements and finished product. As a business analyst, you should be able to trace the requirement to its origin when required. The IT is ever-changing space, and there might come a time when someone else will access your work to define a new change. So a well-documented and traceable requirements will save both time and energy and of course the frustration which we usually witness ourselves when going through missing/unambiguous requirements from others.

Virtual Collaboration

Written by Poorti Mehta on March 14, 2018. Posted in Articles.

What are the major modules of any application development project?

Requirement Gathering (this one requires some rigorous re-iterations)
Approval from all stakeholders and drafting a BRD (Business requirement document)
Defining a Scope of Work for the project
Preparing other documents such as process flow diagrams, technical documentation, module trackers, reports etc.
Development activities
Performing tests on the UAT environment followed by bug reporting and bug fixing

And once all these activities are taken care of, there’s a production movement.

But it doesn’t stop here. There are change requests from stakeholders and thus begins the change management process which eventually ignites the version control process.

While we are on this journey, we face certain challenges. Some of those pictures look like this:

You get notified that there’s an external technical audit next week and you have to get all the relevant documentation sorted. Gosh where were the release notes saved? Are the documents in order? A change was requested on the home page 3 months back. Where are the details?
My system has become a warehouse of documents. I spend so much time organizing the repository that organizational skill should be included in my KRA.
Requirements for this project are changing at lightning fast speed. This wasn’t the case with my last project.
I don’t exactly remember the details of this feature. Wait let me check my e-mail from the stakeholder who had explained it to us. *About 150 emails later* Well, I will just ask him to forward that mail to me.

As a BA I have had my own share of experiences at every step of an SDLC. Over the years what I have realized is that organizations need to invest in appropriate tools and software for a smooth project execution and thus I can’t emphasise on the use of good project management tools just enough.

When I started out as a BA, I learnt the basic documentation that’s common for any software project. Just like many of us on this forum, I too didn’t completely understand the great necessity of documenting each and every step then. It wasn’t until after my first software project went live, that I could see the picture more clearly.

Change requests started pouring in quite frequently and we had some new developers absorbed to the project. And thus came more documentation, version controls, diagrams, trackers and so on. From just one folder, this project grew into 6 -7 folders on my system. Innumerable mails were exchanged to discuss even the smallest and yet an important aspect of the website (read – colour of a button on a webpage). When the new developers were to be briefed about the project, I spent a lot of time in figuring out the relevant documents to be shared with them. Documents that would give them clarity on the process and the progress of the assignment. Sometimes, the stakeholders would lose track of the progress or would misplace a document or go through an incorrect file. In this chaos I realized that a lot of effort was being wasted to maintain the Collaboration.

Collaboration – A significant aspect of any project and a key skill for a BA. Project management and collaboration tools and software are a great way to minimise this chaos and they do wonders for a project’s lifecycle. I learnt this the hard way.

For my next project, we made use of a leading collaboration software. Everything right from requirement gathering to scope of work to change requests, were captured in this application. There were a lot of advantages of using this software:

It could be accessed by all the stakeholders. Hence, whatever changes were made to the requirement or any other module, everything could be viewed by all.
All the relevant documentation was uploaded here. The changes were made online.
The project plan was chalked out smoothly with supported Gant charts.
Feedback notifications were received on real time basis and this helped in faster sign off of modules and requirements.
All the project essentials were stored at one place. Unlike the earlier project where everyone had to maintain a separate repository, the repository of this project was stored online. All the literature at one place – securely stored.
The developers were making notes hassle free.
The milestones of the project could be efficiently tracked.
Lesser emails were exchanged. I didn’t have to send that scope for sign off again or send the updated tracker over and over again.
I didn’t have to worry about the back up of documentation. Version controls were in place.
With a user friendly interface, it was fun working on the documentation and creating user stories. As I got to work on more documentation, I received some very constructive feedback form my immediate seniors and this helped me to improve my data capturing skills. It was here that I understood the importance capturing even the tiniest of detail related to a web page. As all my seniors were on the same project space (of the application) they could view the work I was doing and thus I had feedback from everyone.
Presentations to all the stakeholders became easy and necessary documents and reports could be extracted during audits.

With this change in the process, the first cut of the project was delivered in just 4 months (as compared to 6 months in the earlier project). This is how virtual collaboration helped us.

With such user friendly applications and so many of them in the market, organizations should not hesitate to invest in these applications for their projects. For small size companies, there are open sources available in the market too. Also with most of these applications offering a free trial period, one can explore the best fit for a project. Tools that ensure effective collaboration can make project execution easy. Making the best use of the cloud technology, these applications are a complete back up of a project’s records and documentation.

What tools / applications have you worked upon? Have you faced any similar challenges? Please share your organizational experiences and the challenges you faced that prompted your organization to implement a better architecture.

The Art of the Business Workflow Diagram

Written by Scott Silvestro on March 13, 2018. Posted in Articles.

In many organizations, a business analyst is often assigned to a project where they may have little to no background on the actual business process they are supposed to analyze.

The pressure to capture requirements quickly will mount as project timelines are often too tight. However, as a business analyst, carving out time to build a business workflow diagram will not only help with writing meticulous requirements, but will also enlighten stakeholders for more comprehensive requirements farming. Traditional business analysis calls for stakeholder engagement, planning and then requirements gathering. While most definitely adding more time sensitivity to your project plan, the business workflow mapping is integral to the quality of a project’s success. As BA’s, its not hard to see why a business workflow diagram is valuable, however this crucial step is often a ‘nice to have’ artifact or sacrificed altogether for the sake of the project timeline. Understandably the business workflow diagram is an easy target to trim the fat on a project time line, but I would argue that it is too critical to the quality of the success of the project to be brought to the sacrificial project alter.

The first step in solving a problem is to understand it. As I interview more and more stakeholders, I’ve realized that each person contains an understanding of part of the business process puzzle. Only when these pieces come together can you call a solution comprehensive. Creating this artifact early on in the project, will not only better flush out the problem, but will educate the entire project team on their own business process.

As a use case to support the critical value of the business workflow diagram, I was assigned to a project involving the replacement of a technology transfer application at a large academic medical center. Pre Google-search, I had never heard of “technology transfer”, so I started off trying to understand the business workflow. The business process diagram was particularly helpful in this example as many institutions manage their technology transfer processes differently. My customer had been working with a solution that was over 20 years old and their business process as a whole was in dire need of an update. After meeting with the stakeholders, a vision began to take form. I started using Microsoft Visio, adding in boxes, moving arrows, connecting the dots, watching this business workflow diagram grow and grow. Despite extensive workflow conversations, I often needed to circle back for clarity, only to hear “Oh yeah that’s right I forget we do send that out” or “Well yes, we do have to enter in those details, but that’s only when a particular type is selected.” Both of these instances illuminated a new part of the workflow which not only grew my diagram, but also the stakeholder’s understanding of their very own business process. After I was satisfied that I had successfully captured the workflow, I began circulating the diagram for sign off. I asked each stakeholder to review the workflow, respond with any edits or with their approval. Almost every stakeholder offered more edits, not because I had missed something per se (although admittedly that happened too) but because stepping back and looking at a comprehensive diagram made them realize something new. After a couple of rounds of edits, I finally received full approval from the stakeholders.

Now what? As I began the requirements gathering meetings, I presented my approved workflow on the conference room screen at every single meeting. Like a painting, I used the workflow as a talking point to guide the requirements construction for this new application. As we dove into the business requirements gathering sessions, we often took a pause to reexamine potential changes to our business model. As a business analyst, I welcomed the opportunity to reexamine current business processes and challenged my colleagues on their business process. As a project artifact, the business workflow diagram was memorialized in the appendix of the business requirements document and on some of the senior leaders cork boards.

Even beyond the project, the business can utilize the business workflow diagram artifact in so many other ways; from training, onboarding, reorganization and six sigma diagnostics. The artifact should be alive, challenged, changed, reexamined and updated whenever possible. The business workflow diagram not only enhances the quality of one project, but I would argue it will be a critical artifact for many projects to come.