How to handle clients and requirements
As a business analyst, or any customer facing role involves facing different types of customers and at times we will face angry or irate customers
How to deal with angry or difficult customers
1) The first thing we can do is remain calm, we need to undertand that they are not angry on us, they are angry on the situation they are in.
2) Listen and acknowledge, Keep your ears open and rather then replying to him by making excuses are in or giving clarifications, just hear him out
3) Take ownership, winning an angry customer is to take the ownership of the situation, process either we can choose to pass the task to someone else or we can assure him that we will look into it and get back within reasonable time
4) Empathise, put yourselves in their situation and analyse the pain he is going through
4) Always follow a project management guidelines and have everytihng in writing.
Example we follow Agile development, so we need to document every requirements in User stories with clear Acceptance criteria and proper sign off having everything in black and white helps a long way
How to manage high touch customers
In high-touch accounts, status quo is not sustainable. You need to constantly be planning how to get more strategic and larger in the account—or you will be engineered out. We need to make sure that we are driving for value and just project
completion
Ability to set expectations
Setting expectations early on in the project is very useful as it gives everyone clarity about roles, responsibilities and expected deliverables. If we can under commit and over deliver that can generate a wow factor. If the customer knows early on the project what he will get and by when that will save a lot of time for everyone
There are many ways to do this
1) Create mockups and take sign offs
2) Work on Data models and agree with all and take sign offs from all stakeholders including client SMEs and other integration experts
3) Share test cases with client early on
4) Document the US in a concise and easy to understand manner for all
5) Make sure all stakeholders inclucing client, dev team, test team are on the same page early on calling a spade spade early on is a good practise if there is any amibuity or doubt in a Business Analysts mind, get it clarified before signoff and before dev starts
6) Follow Agile and take iterative feedback of client on every step
Once the development has started and then we set expectations that will lead to customer dissatisfaction and will leave you with no time to correct course if something is going wrong
Push back on requirements
1) Push back from the Tech Team
We often face a push back from the tech team saying "Thats not possible". When we discuss some requirements with tech team they just say its no possible and close the discussion.
Its very important for a business analyst to understand the technical workings and ask the correct questions to break down why its not possible ? is it a data model change ? is it just a UI change / will it require some re-work etc etc. If we are aware of the technical architecture and technologies that are used then we should be able to discuss with tech team in their own
jargon and that should help us in knowing the exact issue and then we can build our solution accordingly
2) Push back from the client
Often times we need to push back clients and say NO to certain requirements
When we are doing it we need to make sure
1) We have facts, data, technical clarity and business knowledge
up our sleeve
2) Shold stay cool, our demeanour can diffuse the situation at times
3) Be active listener, before speaking just hear out the client
4) Take notes if required
5) Dont use words like but, nopes, not possible, etc
instead try and use positive words like yes, ok etc
6) Be assertive dont let them push you around
7) Make sure you have all the documents, emails, data correctly in your favour while you rest your case
8) Be smart and have an equal counter
ex. a client wants to add a new attribute and change data model logic, which is a major change given the deadline is very near
You can simply counter by saying yeah sure we can do this, we will have to extend the Go Live by two weeks and reschedule the roll out plan and charge extra
ex. a client wants to have a new major change at the last moment, a business analyst can simply put that sprint is about to be delivered and at this last hour change has to be taken as part of next phase or release cycle
When you counter with equal argument, you are basically saying No very politely
How to handle chaning requirements
One of the best way to handle requirements is to follow a project management guidelines, one of the best methodologies used these days in IT is Agile development.
One of the key principle in Agile Manifesto is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Lets look at how Agile helps
1) Regular customer inputs and discussion with the team
There are constant status update calls and stand up calls with all the team members, this ensures that every one is in loop and customers requirements are understood correctly, even if customer changes its requirements
2) Agile sprint planning, a working product is shipped to the customer after every sprint, this gives customers time to test it and incorporate new changes if any, this can be handled by agile two weeks sprints. This way customers are constantly in sync with what is being developed and there is always scope to handle new requirements in new sprint cycle.
3) Task boards for tracking who is working on what
A task board simply lists down what are the tasks, who is working on it and dependancies if any, it tracks
To do
In progress
In testing
Done
Tasks boards help manage changing requirements because of the visibility they offer
4) User Stories and sprint planning
User stories help document every details possible, a concise and well written story with acceptance criteria helps delivering a good working product
How to handle vague requirements
With Agile development we can handle vague requirements easily. When customers have vague requirements, we should try and ask them more Open ended questions, this helps in knowing more about the reqs.
Give examples to customers of other similar projects that you have worked on, this way the client can have more clarity as to what can be achieved
Try phased development / multiple releases divide the project into different phases to work with the unknown. break down the user stories and start working on the most clear ones first and then that should give clarity into the unknown.
Make assumptions
Put down the assumptions and communicate it with all the stakeholders
How to handle too many requirements
Follow MoSCoW.
MoSCoW method or MoSCoW analysis,is a popular prioritization technique for managing requirements. This method helps key stakeholders understand the significance of what to develop in which release.
The acronym, MoSCoW, stands for 4 different categories of initiatives: must-haves, should-haves, could-haves, and will not have at this time.
Sometimes, the “W” in MoSCoW is used to stand for “wish” instead of “will not have right now.”
Best wishes for your next project
360 degree analytics
Lets look at few analytical models applied in Retail Industry
Market Basket Analysis
Frequent itemset mining leads to the discovery of associations and correlations among items in large transactional or relational data sets. Market basket analyzes customer buying habits by finding associations between the different items that customers place in their “shopping baskets”. This helps retailers develop marketing strategies by gaining insight into which items are frequently purchased together by customers.
Forecasting Horizons
Long Term
5+ years into the future
R&D, plant location, product planning
Principally judgement-based
Medium Term
1 to 2 years
Aggregate planning, capacity planning, sales forecasts
Mixture of quantitative methods and judgement
Short Term
1 day to 1 year, less then 1 season
Demand forecasting, staffing levels, purchasing, Inventory levels
Quantitative methods
Types of Forecasting Models
Types Of forecasts
Qualitative – based on experience, judgement, knowledge
Quantitative – based on data, statistics
Methods of Forecasting
Formal Methods – systematically reduce forecasting errors
Time series models (eg. Exponential smoothing)
Causal medels (e.g. regression)
Assumptions of Time Series Models
There is information about the past
This information can be quantified in the form of data
The pattern of the past will continue into the future
Short Term Forecasting Needs and Uses
Scheduling existing resources
How many employees do we need and when?
How much product should we make in anticipation of demand?
Acquiring additional resources
When are we going to run out of capacity?
How many more people will we need?
How large will our back orders be?
Determining what resources are needed
What kind of machines will we require
Which services are growing in demand? Declining?
What kind of people should we be hiring?
Techniques of Averaging
Moving Average
A technique that averages a number of recent actual values, updates as new values become available
Weighted Moving average
More recent values in a series are given more weight in computing the forecast
Exponential smoothing
The most recent observations might have the highest predictive value.
Therefore, we should give more weights to the more recent time periods when forecasting
Techniques for Trends
Develop an equation that will suitably describe trend, when trend is present
The trend component may be linear or nonlinear
Linear trend equation
Ft = a + bT
Ft = Forecast for period T
T = Specified number of time periods
a = Value of Ft at T = 0
b = Slope of the line
Error Measures
Error – Difference between actual value and predicted value
Mean Absolute Deviation (MAD)
Average absolute error
Mean Squared error (MSE)
Average of squared error
Mean absolute percent error (MAPE)
Average absolute percent error
Data Mining Overview
Data Mining Process and knowledge Discovery
Data functionalities are used to specify the kind of patterns to be found in data mining. The tasks can be classified into two categories: descriptive and predictive. Descriptive mining tasks characterize the general properties of the data in the database. Predictive mining tasks perform inference on the current data in order to make prediction.
Methodology
Classification is the process of finding a model or function that describes and distinguishes data classes or concepts, the objective is to predict the class of objects whose class label is missing. “How is the derived model presented”? Using Neural networks and decision tree
Classification predicts categorical (discrete, unordered) labels, prediction models continuous – valued functions. That is, it is used to predict missing or unavailable numerical data. Regression analysis is a statistical methodology that is most often used for numerical prediction
Sample 4D Data Cube
Hope you find your data nugget! cheers!
Data Modeling for Business Analysts
As a Business Analyst we come across scenarios where we are discussing requirements with clients and feel need to design a Data model. A data model helps to break down a complex business problem and build a solution,
Data Model are of 3 types
Conceptual - A conceptual model is a high level data view
Logical - This is a logical representation of data and using this model a physical schema should be created
Physical - A physical schema or Entity diagram is the actual representation of how tables, attributes and its data types will be stored in the database.
As busniess anlyst we need to build a logical data model to correctly document the requirment
How to Model Data ?
Step one - Identify all the Entity Types
An entity is a representation of people, places, processes, things, events, concepts, systems etc.
These entities are used to create objects in data model. Ex. of entities in a Customer maangement
system can be Accounts, Sales, products, price, contacts etc
Step two - Identify Attributes
Each entity type will have its own data attributes. for ex. a product entity will have product name,
code, size, color, MRP, tax etc as its attributes
Step three - Apply data naming conventions
Each business organization will have its own naming conventions as per their process. Ex. a SKU code
would be MAC-BL-IND-001 where MAC stands for Machine BL for BLUE and IND for India, blue machine from India
Step four -- Identify Relationships
Each entity will be directly or indirectly related to each other, ex. one product might have multiple
prices as per the customers, so that means entity product has one to many relationship with price
Step five - Assign keys
Identify primary and foreign keys and use them to map the relationships
Step six - normalize the data
In this step we try to organize the attributes in the entity in such a way that increases cohesion of
entity types and eliminate the data redundancy.
Forex. many customers will buy many products, keeping customer and product information is not
advisable . what we should ideally do is keep customer info in customers table, product info in product table
and order information in orders table
Step at times we might need to De- normalize data to improve performance
At times normalize data in production result in performance issues, so we have to denormalize data
schema, structure the DB in such a way that it reduces server load and gives good performance
Agile data modeling
Data modeling performed in an iterative manner or an incremental manner.
Finally practicing with other BA's and solution architects will give us better skills to data modeling
Cheers!
How to introduce team to a new process
Every company needs to set processes or change processes as it grows
Processes are the only way to scale, without process a company cannot scale.
Similarly people participating in the process is crucial and only then processes will succeed.
Hence, it is necessary to introduce teams to processes and get them on-board people are generally averse to change, they dont like change and would want to continue working the way ther are.
Also, people dont understand the benefits of the process. Are overwhelmed by the amount work involved in the new process. So we should address all the issues when introducing a new process.
Hence, we should consider make the process a strategic initiative approved by management. Once, people know that its strategic priority then it will be taken seriously.
The process should be the primary focus and alternative approaches should not be allowed. All the people including the senior management has to follow the process other people when see that the seniors are doing it then they also follow
Communicate the benefits
Demontrate how the new process is good for overall company and how it will benefit all in the long run.
Set goals
We need to set goals for process, people and tools, as to where is it that you want to be when the process is implemented.
Identify Risks and plan on how to mitigate it
When a process is implemented there might be certain risks that might spring up, be pro active to identify them and plan to mitigate them
Communication
Regular communication and transparent updates to all the stakeholders should help the process become the norm
Best wishes
Thanks for reading
Integration to third party systems | Guide for a BA
How to approach integraon with two systems: How do you get System “A” to talk with System “B”
Lets look at the overall components.
Middleware - It is the glue that holds two systems together
Many major companies like MuleSoft
Interoperability - Interoperability is the property that facilitates unrestricted sharing and use of data or resources between disparate systems via local area networks (LANs) or wide area networks (WANs) efficient automated data sharing between applications, databases, and other computer systems is a crucial component throughout networked computerized system
Protocols -
Data Transfer protocols
CSV import / export
XML Export / import
Webservices - APIs, using APIs is very common method of connecting different systems, RestAPis using JSON objects is a very common method
Webhooks - webhooks or HTTP callbacks are an alternative to APIs.
ISC and orchestrations
How to build a Robust Integration solution
Today in many companies we can see examples of data silos, in this age of digitalization we are seeing that more and more companies are integrating their systems (ERP, CRM, Accounts, Finance, etc) and levaraging the advantages of connected systems and data.
To make this happen we require a robust integration system
So what makes a robust integration system
Firstly, Its scalable - while desiging the integration system we need to make sure that is our system scalable?, are we taking into considerations the current and future growth of systems, new data types, increased number of data transfers, integrating more objects etc ?
All the future scenarios should be thought of and considered as
rebuilding later would cost a lot of time, efforts and money wasted.
Secondly, Easy to upgrade - once the new upgrades are available or necessary the system should be able to upgrade without affecting the current solution
Handle Data security
When we integrate two systems and data transfers from one to another there is high probability that data is exposed and company is in vulnerable position. So to avoid data security breach we need to ensure our data transfers securely via SSL encrypted transfers. Data should be read and write directly to and from the databases via the APIs and avoid data staging (i.e FTP server).
How to handle errors in integrations
When data transfers from one system to another we need to make sure that while designing the integration interface we have considered below
a) While importing data how to handle data error
b) How to handle connection error
Often times we are so focused on building interface that we forget to take care of data and connection issues
Firstly we need to start by finding the source of error
In most cases, the error is in
1) bad or poor designed connections, these connectors are not able to handle
all data / data types and crash
2) bad data or missing data, the destination system requires data in
certain format, certain required fields, but the data from the source is
not satisfying all the conditions and errors pop up
Secondly, the platform that we choose
If we are going with a integration platform like MuleSoft or Dellbhomi, then these platforms provide in built error handling tools. These should help us in solving most of the errors
Thirdly, if you are running periodic batches, then maintain a log of past weeks history, this way it is easy to track the data that was processed by the system
How to handle concurrency
In any system with multiple users and large systems there will be concurrent transations, these often lead to
Dirty read
A dirty read happens when a transaction accesses data that has been modified by another transaction but the change has not been committed or rolled back yet.
Dirty write
When two transactions access the same record and both update the same record. One transaction will overwrite the other transactions values, Thus it results in dirty write.
There are various other issues like Phantom reads, fuzzy reads
To solve these issues we need to make sure
1) That our transactions maintian their ACID properties
2) We use SQL servers default locks to avoid concurrency problems
3) Another option is to use row versions to support concurrency
Weights in survey data
Using Weights in the Analysis of Survey Data
What do we mean by Survey weights?
A Value assigned to each case in the data file
Usually it used to make statistics computed from the data more representative of the population benchmark
E.g. A value shall indicate how much each case will count in a statistical procedure
Examples:
-- A weight of 4 means that a case is counted as four in the dataset
-- A weight of 1 means that a case is counted as one in the dataset
-- Weights can (and often are) fractions, but are always positive and non-zero
In stats we call them as pweight
Types of Survey Weights
Two most common type:
-- Design Weights
-- Post-Stratification or Non-responsive weights
Design Weight:
-- Normally used to compensate for over – or under – sampling of specific cases or for disproportionate stratification
--Example: it is common practice to over-sample minority group members or persons living in areas with larger percentage minority. If we doubled the size of our sample from minority areas, then each case in that area would get a design weight of ½ or 0.5
-- The design weight when we want the statistics to be representative of the population
To know more, click here Weights_in_Survey_Data_Final