MoSCoW: Requirements Prioritization Technique

The MoSCoW prioritization is a technique used in business analysis and project management, commonly known as MoSCoW analysis. MoSCoW is a legitimate technique to categorize features (or user stories) into precedence order – a technique to aid teams swiftly comprehend the customer’s view of what is vital for launch and what is not.

Once the requirements get frozen, business analyst are required to rank those requirements. MoSCow Prioritization plays a significant role in Agile Project Management. In case of Agile projects, it is vital to fathom the importance of prioritization as time is fixed, so prioritization is applied to requirements, tasks, products, user cases, etc.

Its name is derived from the first letters of each of the four respective priorities.

MoSCoW stands for:

• Must have (or Minimum Usable Subset)
• Should have
• Could have
• Won’t have (but Would like in future)
               

 ‘Must Haves ‘– these are the features that must be incorporated prior to the product launch.  It is essential to have transparency on this before the project kicks-in as this is the minimum scope for the product to be useful. These need to be fulfilled for achieving the primary objective of project.

‘Should Haves ‘- these are the features which are not critical to be launched, but are considered to be vital and have immense significance to the user. These requirements are extremely desirable but have less priority than Must requirements.

‘Could Haves ‘- these are the features that are nice to have and might be effectively incorporated without incurring over-burdening effort or cost. Basically a few easily fulfilled Could requirements in a delivery can intensify customer satisfaction for a little development cost, but these features will be immediately removed from scope if the project’s timelines are at risk.

‘Won’t Haves ‘– these are the features that have been demanded but are overtly excluded from scope for the current release, and may be encompassed in a forthcoming phase of development.

This practice is suitable in business development and when the business analyst is sure about business needs. Prioritization is basically carried out by all stakeholders i.e. the project sponsor, the project owner, and the Analysts. When we gather the requirements both functional as well as non-functional requirements are considered but the most essential aspect is to keep in mind to prioritize the non-functional requirements independently as the abstraction level of these non-functional requirements is different from that of the functional requirements.

Benefits of MoSCoW technique for Business Analysts

• Helps in determining the project scope
• Helps to plan the project deliverables
• Helps in managing requirements and resources
• Helps to prioritize requirements and provide the essential rank
• Helps to save time

    Conclusion:

MoSCoW technique plays a significant role in the entire project life cycle as when requirements have been prioritized they can be compared against the other planning aspects of project, such as project scope, quality, timescale and resources.

About Author:

Gurpreet kaur Gaga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, She actively contributes to the areas of Technology and Information Security. She can be contacted at: gurpreetkaur.gaga@spluspl.com

Preparing for requirements gathering

One of the basic tasks of a business analyst is requirements gathering. As the saying goes “Well begun is half done” and a well conducted requirements gathering session will go a long way in ensuring smooth delivery of the project. Most of the requirements will come from the stakeholders. However a good business analyst will definitely have to do his / her homework before getting into requirements gathering mode. Some of the aspects to take care of prior to requirements gathering are listed below

• Domain Knowledge: This is the most important aspect to understand. The BA may or may not be an SME on the domain. However it would serve the BA well to read out as much as possible on the domain / industry for which requirements are to be gathered. This has multiple benefits. Stakeholders may be very used to using terms that is specific to the industry. It will help if the BA is already aware of the meaning and builds the confidence of the stakeholders. If the BA is a domain expert he can also suggest some additional functionality based on industry best practices which could be good for the business.

• Identify Stakeholders: Another important aspect to consider to identify who are the stakeholders who can provide the requirements. This is more crucial in case the requirements gathering sessions are going to be conducted onsite. Since stakeholders may not be available full time it is always a good idea to catch up with them (over emails etc.) prior to the actual visit and block times for meetings. It is also a good idea to have an agenda in place for the meetings so that everyone is clear on what is expected from the meet rather than to just leave it open ended.

• Predefine templates: Where ever possible have some pre- defined templates prepared and approved from the client. This helps to channelize the requirements gathering towards meeting a specific issues or addressing a particular pain point. Also sharing this before starting the actual requirements gathering will be beneficial. Not only can stakeholders provide their inputs on how the templates can be made better, it also helps them to be prepared with any extra information that may be needed for the requirements gathering sessions. 

• Review any material available: As part of preparation for requirements gathering, a BA should also request for any existing material that is available regarding the topics under scope. This could be in the form of training materials, user manuals, forms or process flows etc. A review of such documents should give the BA a good feeling on the sort of pain points the users may be experiencing and what direction the requirements gathering sessions will lead to.

• Understanding various techniques: A BA should be able to use all available techniques to gather the requirements. Not all requirements can be clearly spelt out. The key is to understand the unsaid word. The BA should make sure that they also notice user actions and identify issues / pain points that may need to addressed and get it confirmed from various stakeholders.

• Listen first, analyze later: An aspect that a BA should try to avoid doing is confuse requirements gathering with requirements analysis. Many a time the tendency is to start evaluating what the requirement means in terms of development / coding etc. Ideally the focus should remain on just understanding the requirements clearly and analysis of the requirements should be only from the perspective of getting clarifications or eliciting detailed requirements.

• Prioritize requirements: It is also a good idea to understand the priority of the requirements. Some requirements may be easily attainable but not a priority. In some cases, requirements may just be a nice to have feature but not really something that is essentially needed for a “GO LIVE” scenario. It is important that the BA is able to understand the requirements along with the priority and get it aligned with the stakeholders. This is an important aspect even from the overall project planning perspective.

• Conclude the session: The most important aspect of the requirement gathering phase is the conclusion of the phase. At the end of the phase, a clearly documented list of requirements should be agreed upon by the BA and the various stakeholders. This could be in the form of a simple excel sheet or a BRD / SSRS etc. Whatever the format is should be formally signed of and forms the basis of project scoping, effort estimation, timelines and not to forget costs!!

The above mentioned pointers are by no means exhaustive. Also these are just generic guidelines which can help a BA in gathering and consolidating requirements in a more efficient way. This can lead to significant reduction / savings in time and effort of both, the BA as well as the stakeholders. It can also ensure that all requirements get captured within a specified time frame. A well listed out set of requirements also helps developers, project managers and QA tests to ensure that the final delivery meets stakeholder’s expectations in terms of functionality and quality

About Author:

 Ashish Akulkar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: 

ashish.akulkar@spluspl.com

Project Management Tools- Agile

Project management software development methodology is adopted by companies world-wide. According to the surveys conducted recently, around 70% of the organizations have adopted agile practices. During the last decade, the agile methods have developed rapidly from nowhere to pinnacle. Such rapid revolution in technology demand new tools and innovation. Majority of the organizations are still using old-fashioned project management tools and generic tools like MS Project and spreadsheets for project planning and tracking.

The pie chart given below gives the percentage of types of tools used by organizations across the globe and companies still prefer using traditional tools for project management.

The question is, are these tools really the best of the choices when it comes to project management. In this article we shall discuss the different approaches for project management and give comparative analysis of the simplest tools, traditional project development tools, agile project management software and spreadsheets.

Need for a Tool

One cannot rely on ones memory for requirement gathering. To overcome the limits of retaining things in mind, it is essential that one has a tool at his disposal. This enables one to gather requirements, plan iterations, track the progress and report the entire process. A tool which works effectively and efficiently is required for this purpose which will give rise to no or minimum errors.

As said by Ron Jeffries “I think that people and how they interact on a project is the most important thing, and I think that they need to create a way of working -- a process -- that works best for them. Because their interactions are critical to project success, I suggest that teams begin the work with an approach that will bring them together as people, not one that will let them remain apart, communicating electronically”.

Project Management Tools- Pros & Cons

Index Cards

Index cards are cheaper, distinct and pliant to use. It is easier to understand the brief and overview of state of project and very effective for communicating information. At the same time they have the drawbacks of having remote access to data, reusability of data and backing up of data, doesn’t work for large teams.

General Software Tools

Wiki is a very versatile tool which can be used for any content management. There are project teams which use wiki for scrum development management. Wiki is cheap and easier in its usability. However, like cards, wiki doesn’t work for larger and distributed teams and time consuming.

Old School Project Management Tools

MS Project is the most commonly used traditional project management tool. The benefit here is, it might already be existing in companies and allows people allocation support. However, it doesn’t support agile development concepts and faces constraints when it comes to reporting.

Agile Project Management Tools

It is important to integrate the process of planning and development for having a versatile project management tool. Almost every development process involves activities like requirements gathering, planning, tracking, quality assurance and feedback gathering. To carry out these activities, several tools like Bugzilla, Test Run, MS Project, Requisite Pro, Support Forum, etc are used. Each tool does its job, but it’s a time taking process to export/import data between applications and often format it to get a complete picture. Hence, the need for a modern agile project management tool which combines the common activities and provides open API for advanced integration. It powers backlogs prioritization, low level iteration planning and high level release planning, progress tracking, tests and bugs management and customer requests management. In short, it gives an integrated process which follows Lean Principle. The other goal of agile software is to bring together several teams working on a single project which is possible only with the aid of web based software.

There are many agile software development tools like Mingle, Jira, AgileZen, VersioneOne, Rally, etc. Some of them are described below.

Mingle is designed for small, medium and large enterprises. Its key features are program management, project collaboration, project management, accurate defect and visual tracking, release and iteration planning and real time tracking and reporting. It is user-friendly and flexible.

JIRA is a project management, bug tracking and issue tracking tool used by thousands of companies across the globe. Also what makes JIRA more flexible is that more a general issue tracker than just a bug tracker.

Agile Zen is a visual tool. It has a tab based and colour coded interface. It is based on the Lean management principle. Instead of having a task-list, it has a story based work unit, wherein the details can be added and edited. The efforts spent are manageable and can be tracked.

The agile tools have their own better and the flip side. It works for bigger teams, it allows real-time reporting, gives integrated solutions, allows bug tracking, etc. However, agile tools are very expensive, significant learning time is involved, sometimes hard to apply for processes which are already in development phase.

Any project requires a good set of tools for its management. The agile software development tools will evolve with time. A trend that will continue to influence software tools is ever-tightening release cycles. Where releases once took years, an increasing number of software products will release new functionality to production monthly, week, daily, or even more frequently. The trend towards support more frequent transitions between activities will continue. More activities will be supported without larger changes of context. The use of effective project management tools will help in integrating several processes which are carried out by multiple set of tools. Hence, there is a need for the tools and technologies which will aid in faster deliveries and releases.

Devika Vaghela is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, She actively contributes to the areas of Technology and Information Security. She can be contacted at:devika.vaghela@spluspl.com

How To Fit BA’S & PM’S On Agile Projects?

It seems like there has been a discussion about this for 10+ years and we will probably continue the discussion for another 10!

Titles do cause confusion. In general, there has always been a confusion regarding the roles of PM (Project Manager) and BA (Business Analyst). The role of a BA and PM are not divided into undisputed territories. The industry works hard to clearly draw a line between the roles of a BA and PM, but the real-life challenges of organizations and projects make perfect alignment to textbook role definitions impossible. With the advent of Agile, roles related to Agile have been added to the mix. This makes it even more difficult do actually decide how to fit BA and PM on an Agile project.

In today's business environment which are fast paced, companies are constantly under pressure to adapt to the changing market conditions. Companies that are into software development increasingly incline towards agile development practices to help them stay ahead in the market. Agile processes are iterative, highly collaborative and all focused on the rapid and incremental delivery of software.

More and more organizations are transitioning to an agile mindset which creates more confusion pertaining to roles of BA and PM. Common title and role-related questions include:

• Is a BA involved in an agile project?
• What would be a BA’s role on an agile project?
• Is the role of a Scrum Master the same as that of a PM?
• Does the PM become Scrum Master?
• Does the BA become Product Owners?
• Is QA a part of the agile team or are they separate?

Do we really need to ask these questions? Or instead just adapt to the changing needs of the market. Many organizations have started to adapt but by modifying the roles as per their convenience and that makes it even more difficult for the industry to answer these questions? There is a need to stop finding links between traditional titles to agile titles. That’s not how it works. There is no direct translation or 1:1 conversion. And when we try finding that relation, it is no more agile and becomes hybrid agile. 

No doubt that skills of the people involved defines an agile team and not titles but that doesn’t mean we should neglect the core concept of agile. At times it becomes so difficult and confusing when BA, PM, Scrum Master, Product owner, all are involved in a single project and they call it an agile project. Nobody talked about roles like Scrum Masters and Product Owners before the birth of agile. That clearly explains that these are agile roles popularized and defined by the agile methodology.

It rarely happens when HR managers are looking forward to hire resources for the new agile roles. These roles are new for organizations implementing agile, but that doesn’t mean that there is a need to hire new resources. So, how do we get people for these new roles? The answer and the people are in the same organization i.e. people who have experience in traditional roles. PMs, BAs, Tech Leads, Solution Architects, Business Managers and Product Managers with little bit of research and training can take up these new agile roles.

There are times when titles don’t change. So, by title one can be a Business Manager but play the role of a Product Owner when working with an agile team. One can be a BA by title but my role would depend on what the team needs and what talent I bring to the team when it is agile.

Basic skills required for every software development project remains same. The only difference is in the application of those skills in accordance with the project requirements. The ultimate goal is to successfully complete the project, be it in the traditional way or the agile way. The agile team determines in achieving this goal by applying agile principles to determine what will add the more value to the business process and the customer.

There is a mad rush in the market and everyone wants to be agile. Transitioning from traditional to agile can be frustrating given that at times agile roles seem to be a bit blurry at times. Every organization tackle this challenge differently. If we just forget about the titles and focus more on techniques, skills, incremental improvement, we can minimize the confusion involved in transition to agility. Let the focus be on successfully delivering value to our organizations instead of pondering over how to fit BA’s and PM’s on agile projects.

Every organization has their own terminology and have different names for different roles. It does matter what you name it, rather what really matters is the team dynamics needed to succeed in agile projects. Try and identify people who excel in their current job title in traditional projects, it should not be hard for them to work on agile projects. Ultimately you need to successfully complete the job at hand, with or without agile.

About Author:

Sachin Poojary is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: sachin.poojary@spluspl.com 

Behind the Scenes as a Business Analyst

A Business Analyst (BA) scrutinizes intrinsic details of an organization or business domain and documents its business, evaluating the business model or its amalgamation with technology.

A Business Analyst (BA), is basically a part of the business processes and works with Information Technology to improve the quality of the services being delivered, assisting in Integration and Testing of new solutions. BA also supports the creation of training material, contributes in implementation, and delivers post-implementation support. This may involve the development of project plans and often requires project management skills.

What does it take to be a Business Analyst:

The Business Analyst role is perceived as a communication link amid IT and the commercial stakeholders. Business Analysts should be great vocal and written communicators, insightful diplomats, problem solvers and analyzers - with the capability to engage with stakeholders to fathom and respond to their needs in the rapidly changing business environments. 

This involves frequently dealing with senior stakeholders and ensuring that the value for money is attained from IT developments.

In order to understand the benefits that Business Analysts bring to a project, it is essential to know the general criteria for a project to be successful. Following are the four key components which determine the project’s success:

• Completion of project within the specified Timeline
• Adherence to estimated Budget
• Determine the impact on everyday Business
• Adopting Solutions and determining usefulness 

Few Essential steps to be followed by a Business Analyst to Meet Project Deadlines and ensure successful completion of project:

1.Get required clarifications

To meet a project deadline, it is essential for the BA to know what the project requires. Building assumptions around what is expected can result in mismanagement of the project and waste time of the project team and as well as the client. It is equally important to get clarifications necessary to meet the client’s needs. Once an agreement is reached, it is essential to get it in writing, and have the client sign off on it to avoid any possible disputes.

2.Break it Down

Most projects are accomplished over a set period, and require few precise actions to be taken along the way. As the complication of the project increases it is important for the BA to ensure that all steps are completed. Identifying key checkpoints will help one track the project's development and stay on schedule.

3.Communication

Communication is vital to the success of any project. As a BA is a link between the client and the internal team, effective communication plays a significant role to align the various stakeholders to attain a common goal. While an email notification may be adequate for a small project, a multifaceted project usually requires face-to-face communication. Making departments and people responsible for carrying out definite steps will help to keep the project on schedule and reduce the likelihood of misunderstanding.

4.Time

The project team’s BA must elicit, analyze, and validate all project requirements frequently with the stakeholders. A project needs to be completed within a certain time frame. If the requirements are defined clearly then there will be less rework and will enable to complete the project in a cost effective manner and deliver it on time. 

  

Today’s business environment entails project driven transformation to be executed with more discipline and agility than ever before. The Business Analyst’s skilled interaction with stakeholders all the way through the organization will facilitate the acute need to bridge the gap between strategy and execution. It is essential to engage with technologies in order to deliver the final product within the specified time, budget and estimated effort.

Gurpreet kaur Gaga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, She actively contributes to the areas of Technology and Information Security. She can be contacted at: gurpreetkaur.gaga@spluspl.com

A Meeting Invite Inside

With the advent of technology, all major communication is now done using the internet. An invite right from a meeting to wedding is send online. On daily basis we come across many mails in our inbox and send out so many mails too. Do you reply to every mail sent to you? Do you receive replies to all the mails you have sent? Let’s try and gain an understanding of how a well written email distinguishes itself from the others.

1 Subject Line: 

The best email subject lines are usually short and provide the reader a reason to open your email. They need to be descriptive and should include the meeting name and an indication of what kind of invitation it is that you are sending.

2 Date & Time: 

In the text of the e-mail make sure to include the full date and time of the meeting, including the time zone. Spelling out month names helps avoid confusion for people from other countries who are used to seeing different date formats. Remember that Outlook automatically converts the invite to the local time of the receiver. 

3 Highlight the Agenda: 

An organized meeting will always have a well-written agenda. You must keep all your meeting streamlined and focused, ensuring that you meet all of your goals for your meeting in the shortest amount of time. Always keep time for Q and A in agenda ensuring that the participants are engaged. 

4 Accept, Reject, Decline: 

Any meeting invite send must be responded to. As a participant you can accept or decline a meeting request. If you are unsure you can send a tentative response or propose a new timing. But ensure that it is replied to. Not answering to meeting invites is considered unprofessional.

E-mails reflect a lot on an individual’s professionalism. Ensure you keep e-mail strictly professional, do not get too emotional. If you are unsure of your emotions take some time out and then draft the e-mail. Do not forget to format the e-mail and check for spelling errors. 

As they say “Regardless of the mode of communication used, professionalism and courtesy never go out of style”

Shweta Samudra is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, She actively contributes to the areas of Technology and Information Security. She can be contacted at: shweta.samudra@spluspl.com

The Agile - Scrum Framework

Scrum is framework which is based on agile principles, a framework that handles simple, complicated and complex software development. Scrum is based on continuous improvement in product and process. Scrum deliver software frequently (value), it showcase the hidden problems in systems development. In scrum project move forward with series of iteration that are called Sprints. Each sprint size is typically two to four weeks long. It is based on inspect and adaptive cycle. Produce product incrementally and iteratively, thus reduce risk and enhance visibility.

Scrum has simple roles, activities and artifacts.

Scrum Roles:   Below are the roles in Scrum

1 Product Owner,   2 Scrum Master, 3 The Team

1 Product Owner

•  Product Owner (PO) is client's representative, define features of product and decide release date and content
• Priorities features according to market value and be responsible for the profitability of product
• Accept or reject work items

2 Scrum Master

• Coach for scrum team , Enacting scrum values , Ensure team's productivity
• Build winning team, Apply agile principles and make system effective.

3 Team

• 5-9 Members team (Developer , Tester) , Self-organizing, High performance team
• Build winning product, Work collaboratively and share responsibilities, Cross functional team.

Scrum Activities:
1. Sprint Planning
2. Daily Scrum
3. Sprint Review
4. Sprint Retrospective
5. Product Backlog Refinement

1 Sprint Planning:
       Goal: Team to plan and agree on backlog items they can complete and confirm the tasks required        to support acceptance

Product owner present the backlog items in priority order for review

• Review and clarify user Backlog items/stories
• Breakdown larger stories and each story into task and acceptance criteria
• Task are estimated in hours by team, Developer and tester assigned to task
• Process continue until all available hours are used for the sprint.
• Output of sprint planning is be Sprint backlog, Estimated tasks etc.
• Duration: 4 Hours for 2 weeks sprint , Who: Scrum Team, Scrum Master, PO, When: Beginning of the Sprint

2 Daily Scrum:
Goal: Plan for the day, Inspect and Adapt daily towards reaching the sprint goal.
Description:

• Daily development Team standup for 15 minutes in circle and talk only on three points
• What I did since last daily scrum meeting?
• What I am planning to work on today?
• Impediments (Issue/blocker) if any?
• Scrum master protect the team and facilitate for being effective.
• This give an opportunity to team to inspect and adapt daily on the sprint goal.
• Who: Scrum Team, Scrum Master, When: Daily throughout the sprint , Duration: 15 minutes maximum

3 Sprint Review:
Goal: Get feedback on product development. Inspect and adapt on the product feature.
Description:

• During this meeting team demonstrate 100% completed work.
• Scrum master facilitate the environment.
• In case of new request, Product owner (PO) note and updates the product backlog as required.
• Product owner is final decision maker on acceptance.
• Duration: 2 hours for a 2 week sprint, Who: Scrum Team, Scrum Master, PO, Stakeholders, When: Last day of sprint

4 Sprint Retrospective:
Goal: To inspect and adapt to become more effective and efficient on process, people, culture aspect.
Description:

• Participation in the discussion to inspect and adapt as scrum team.
• Scrum master play vital role in sprint retrospective, Scrum master bring in the culture of openness, trust and respect as people discuss the improvement areas, facilitate and focus on improvement and changes that pointing fingers at others.
• This is platform to scrum master to help team resolve ineffectiveness in the systems
• Inspect and Adapt: Try everything that makes sense, reject things that didn’t work even after repeated trails. Shape your culture, process and practice.
• Duration: 2 hours for a 2 week sprint, Who: Scrum Team , When: Last day of sprint

5 Product Backlog Refinement:
Goal: Keep product backlog items ready, uncertainty to certainty
Description:

• Product owner provide clarity on each product backlog item (All uncertainty clarified into certainty )
• Product owner Update product backlog. 100% be present and involve all team members
• Team understand, carefully listen to need of product owner, understand the acceptance criteria. Help product owner to order the backlog.
• Duration: 1-3 hours depending on the team’s need. , Who: Scrum Team, Scrum master, PO, When: Continuous process, in between the sprints.

Scrum Artifacts:
Below are Scrum Artifacts.
1) Product Backlog,   2) Sprint Backlog, 3) Product Increment

1 Product Backlog
This is an ordered list of ideas for the product, which can come from the product owner, team members, or stakeholders. A description and estimate of effort complement each product backlog item.

The product backlog is ordered to maximize the value delivered by the Scrum team. The development team’s work comes from the product backlog, and nowhere else. Every feature, enhancement, bug fix, documentation requirement, every bit of work the team does comes from a product backlog item.

The product backlog may begin as a large or short list. Typically it begins short and becomes longer and more defined as time goes on. Product backlog items slated for implementation soon will be "refined," which means they will further clarified, defined, and split into smaller chunks. Though the product owner is responsible for maintaining the product backlog, the development team helps produce and update it.

2 Sprint Backlog
The sprint backlog is the list of refined product backlog items chosen for development in the current sprint, together with the team's plan for accomplishing the work. It reflects the team's forecast of what work can be completed. Once the sprint backlog is established, the development team begins work on the new product increment.

3 Product Increment
Every sprint produces a product increment, the most important Scrum artifact. A product Increment is the "goal line" for each sprint and, at the end of the sprint, it must:

• Be of high enough quality to be given to users
• Meet the Scrum team's current definition of done
• Be acceptable to the product owner

Scrum Information Radiators:

Task boards:

• Task boards allows transparency, display what is the live status of the teams work and focus area
• Simple task board has backlog , To-do, in progress and done status
• There are various format
• Team design their best “Information Radiators” that helps them in self-organizing

Burndown Chart:

• For current sprint, it shows  the total estimated work remaining for the entire forecasted sprint backlog against time
• Updated by team , regularly  and continuously
• Independent of the work, it represents total remaining estimated time to market to achieve sprint goal

About Author:

Kshitij Yelkar is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, He actively contributes to the areas of Technology and Information Security. He can be contacted at: kshitij.yelkar@spluspl.com

Being a BA is not for the Faint Hearted

A Business Analyst (BA) is a person who analyzes an existing or ideal organization and design of systems, which includes businesses, departments, and organization. The BA then recommends changes to add maximum value to the business.

Business Analysts are in great demand due to an increase in the complexity of requirements needed in business systems and projects. The complexity is increasingly driven by the trends in technology like big data, mobile computing and security which brings the role of the BA in the front row. To survive in this ever increasing demand from the customers, a BA has to deal with all the following aspects:-

Getting Stakeholders To Make Time

It can be a challenging task to get the stakeholders to make time, if they lack interest in a project. When Stakeholders are not committed to the project, it takes extra time and effort for the BA to their work done. An effective approach to overcome this is to ensure that managers are copied in all communications all the way through. When functional managers are involved, even if it is to a small extent, team members are keener to fall in line.

Lack of Clarity

Achieving clarity of scope is one of the most difficult aspects of any project. Clearing up any confusion surrounding the scope of the project is one of the main responsibilities of a BA. Unless objectives and scope are fully defined and agreed upon, there would be no success. This is the reason why defining scope and objectives is such an important part. A BA can’t confidently flag off a project without signoff on these.

Inadequate Time Allotted For BA Work

Wouldn’t it be great if you got a new project and were told that it could be completed whenever it suited you? However in the real world, time allocated to your project will be limited. A major hindrance to delivering high-quality deliverables is lack of adequate time to complete Business Analysis tasks. Time constraints is one of the main reasons which can lead to incomplete specification documents which eventually lead to implementation of requirements that do not solve the business problem. As a precautionary measure, it is always better to plan well and start early. A strategic plan with all activities mapped out, sufficient resources and some extra buffer time built in can help you stay ahead.

Conflict among Stakeholders

At times, stakeholders may not be amiable and find it difficult to work well together. One thing that can be particularly difficult to control in any project is how stakeholders comprehend one another. In such scenarios, it is important to help stakeholders separate work issues from business issues and handle stakeholder interactions proactively. It becomes even more essential for the BA to reinforce the importance of working together as a team towards a common goal and facilitate it. Instances where stakeholder requirements conflict, it is up to the BA to managing stakeholders in arriving at a common ground. BAs must understand how to manage conflicting requirements and reduce conflict during stakeholder interactions.

Documentation and Specification Skills

Documentation is a key aspect in a BA’s profile. Documents should be crystal clear and concise (the latter becoming increasingly necessary in a lean or agile world) capturing all the important as well as the less important aspects of the project. A BA should not compromise in capturing and registering information as and when required. While documentation or writing could be considered a subset of written communication, it’s really its own skill set for a BA. As a new business analyst, you may not have experience in a variety of business analyst specifications (that comes with time and a variety of project experiences) but it’s quite possible that your strong general documentation and writing skills will get you started.

Job of a Business Analysis is not a cake walk until and unless the Business Analyst develops all the skills to handle tackle situations that might arise during the project development life cycle. Although the profile is convincingly rewarding, but to attain expertise in this job one has to be strong in analysis, clear in words and must have a lot of patience to deal with pressure situations.

About Author:

Sachin Poojary is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, he actively contributes to the areas of Technology and Information Security. He can be contacted at: sachin.poojary@spluspl.com 

Motivation by Project Manager – Makes or Breaks the team!

People and Planning is what really determines the overall project success. The team members are the real gems of any project. When a team is working well, each member knows that he or she is part of something bigger than the individuals involved - that the team is greater than the sum of its parts. When a team performs well, they know they can overcome obstacles have achieve their goals easily. All this is only possible when the team is headed is by a strong leader, in most cases – The Project Manager.

Jim Rohn says - The challenge of leadership is to be strong, but not rude; be kind, but not weak; be bold, but not bully; be thoughtful, but not lazy; be humble, but not timid; be proud, but not arrogant; have humor, but without folly. What it all boils down to is – If a Project Manager can rightly motivate his team!

From a bit of research, here are a few points below that I feel really help motivate a team:

1. Clarity 

The most important factor while working in a team, is that the team realises what they are working for. Each project has different goals and as a project Manager, be sure that you have shared clearly with the team what they are working towards achieving and when it needs to be achieved by.

2. Maintain a Positive Outlook

Whether you love your job or hate going to work every day depends on the kind of environment you work in. If it’s a negative environment it creates frustrations and it becomes difficult to retain people. Hence, a project manager needs to ensure that a positive environment is maintained in his team. He needs to ensure communication is open; members can state their opinions knowing that differences of opinion are valued. 

3. Be understanding

It's important to be friendly with your team members, to make small talk, and to make them feel wanted and cared for, but you don't want to cross too far over that line. Most importantly, successful team members should not just "feel good", they need to get their work done, meet deadlines and achieving their goals – it is important. 

4. Reward for Contributions

Be a project manager who is acknowledged as one of the team member. It is easy to turn into a dictator – So make sure you behave far from one. Ask for your team members opinions, ask them to share their knowledge. Make them feel important and equally responsible for the project. Reward the members for making contributions and encourage healthy competition.

5. Create Social Events out of Work Space

Everyone likes to party! It has been studied that creating social events for the team to gel up will make the team stronger. You can decide to have lunch together, or go dining after office. Adding a bit of fun element to your daily routine environment will serve as a change as well get more productive efforts from your team members.

A Project Manager is responsible for the overall success or failure for a Project. And how the Project Manager relies on are team members. Motivation is thus an important skill that every project manager must possess to get the best out of his team!

About Author:

Shweta Samudra is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: shweta.samudra@spluspl.com 

Requirements Elicitation for Business Intelligence

A detailed insight of business requirements is never available at an analyst’s fingertips. Much of business or technical requirements are obtained from end users as well as through surveys. The purpose of requirements elicitation is to systematically categorize the business requirements, business risks, and assumptions associated with any given project.

Requirement Elicitation

One of the fundamental things an organization may require after installing an enterprise software application is essential a Business Intelligence (BI) Software. BI tools play a significant role in the organization as they provide an insight into the various data outlines, relations between organizational data sets, and can provide input to tactical decision-making, as well as it is essential to comprehend all the strategic requirements of the business.

The business will be in a much better state to understand what software tool is required when what exactly needs to be accomplished is determined. For instance, analyzing what users do (tasks) and the decisions they make would help to gauge the requirements. These requirements can then be used as a foundation for determining the level of complexity the application would be required to handle. Once requirements are gathered and it is determined what level of BI software configuration is required, user can then start evaluating solutions based on their capability to deliver the requirements.

Elicitation Techniques

After obtaining the stakeholders, an analyst needs to determine the best techniques for eliciting requirements:

Brainstorming – The brainstorming procedure and the subsequent follow-up analysis will help ensure that the best possible solution is obtained for any business objective.

Document analysis – This kind of elicitation is essentially beneficial when the objective is to update the prevailing system or when the understanding of prevailing system will enrich a new system.  However, document analysis alone is not enough to systematically extract all of the requirements for any given project.

Focus Group – Focus groups is a good way for time-pressed analysts to get a lot of information at an instant.

Interface Analysis – An interface analysis carefully examines and analyses the way that a user interacts with an application, or the way one application interacts with another.

Interviews – Personal interviews are amongst the most popular kinds of requirement elicitation technique. They give an analyst the opportunity to discuss the stakeholder’s opinions and get his or her viewpoint regarding the business needs and the feasibility of potential solutions

Prototyping (story-boarding, navigation flow, paper prototyping, screen flows) – Prototyping is particularly valuable to relate to a graphic illustration of the end product.

While you may get away by not considering the non-functional requirements with other applications, it is essential when dealing with BI. BI applications should be selected only after contemplation of their compatibility with your existing architecture/infrastructure and a host of other relevant factors. Collecting requirements for reporting/business intelligence may seem overpowering but can be streamlined by asking the right questions.


It is essential to determine the following questions to elicit accurate requirements:

1. What business decisions are essential in order to achieve the organizational goals (short-term and long-term)?
2. Which key business processes does the business need to improve?
3. What critical business decisions need to be made to facilitate business operations?
4. What information is obligatory to accomplish key job functions effectively? 

BI tools help to deliver a platform for users to interpret pre-defined KPIs for strategic decision-making. It significant to comprehend what business decisions the BI tools need to support so that the required data can be made available.

About the author:

Gurpreet Kaur Gaga is a consultant in Systems Plus Pvt. Ltd. Within Systems Plus, she actively contributes to the areas of Technology and Information Security. She can be contacted at: gurpreetkaur.gaga@spluspl.com