There are three ways to look at data. The first is analytics.

This is when you look at data from

the (potentially very recent) past. Think analytics. It allows you to explore the questions what
happened and why did it happen? The second is monitoring. This is looking at things as they
happen. In many cases, monitoring is used to find abnormalities. Finally, there is predictive
analytics. This is looking at data in a way that helps make predictions about what might
happen in the future.

Basically, predictive analytics is what drives the actions that make the changes which will, in
turn, be monitored by the analytical phase. As you build your predictive analysis model, you
will have various algorithms that you can select in the categories of machine-learning, data-
mining, and statistics. Once you know more about your data, and what you want to
accomplish, making this decision will become a bit easier.

The algorithms that are right for you depend on what you are trying to accomplish. For
example:

Classification algorithms are great if customer retention is your focus or if you are
trying to put together a recommendation system.
Clustering algorithms work well for segmentation or use with social data.
Regression algorithms are generally used as a way of predicting outcomes from
events that are calendar driven.

It should be considered a best practice to use the maximum number of algorithms that you
can as long as they are the types of algorithms that you need. The more information that you
have to compare and analyze, the better off you will be. It can be quite enlightening to find
surprises, or to reveal interesting bits of information. This can lead to your ability to solve
problems. Perhaps even more importantly, this can reveal to you which information in your
data can be used to predict future trends. Lets begin by going over some of the most popular
predictive algorithms and methodologies.

The Ensemble Model

Many people have found that using an ensemble model is the best method for successful
predictive analytics. This is multiple models that all use the same data set. Basically, a
mechanism is created to gather all of the output from the various models. This information is
then used to provide a final analysis to the person running the test.
The specifics of each model can vary. For example, decision trees, scenarios, queries, etc. are
all models. To pick the correct models, you have to understand what works best for your data,
and the problem you are trying to solve. Before proceeding, you will need to clearly define
the questions you are trying to answer? For example:

Will a new target audience be receptive to our current email marketing efforts?
Should we create a microsite or a reviews page for a new product line?
Are customers with poor credit going to default if we offer in-house financing?
Will consumers buy clothing made with cheaper fabrics if prices are cut?

Unsupervised Clustering Algorithms

These algorithms are very useful in helping you find relationships that may not have been
clear to you at first glance. If you are interested in finding similarities between various user
personas, clustering algorithms might be the way to go. You can also use these to discover
product relationships as well. If youve ever wanted to bundle services or wondered how you
could influence customers to respond to your upselling efforts, these might be some
algorithms to consider.

Regression Algorithms

If you have data that you receive on a continuing basis, regression algorithms might help you
to predict future trends based upon that data. For example, if you purchase raw materials for
manufacturing processes, you could use the monthly price data that you gather to predict
seasonal fluctuations in those prices.

Not an Exact Science

There is no exact formula for finding the ideal algorithms for predictive modeling. It takes a
combination of understanding the types of algorithms available to you, understanding exactly
what it is that you need to know, and understanding how to interpret the information that you
receive.

Those who are most successful at choosing the right algorithms for predictive modeling will
have a strong understanding of data science, or they will work with people who do. Then, in
addition to this, having a strong level of business area expertise and experience is key. This
might be considered the art of predictive modeling.

Conclusion

Ultimately, the work that goes into selecting algorithms to help to predict future trends and
events is worthwhile. It can result in better customer service, improved sales, and better
business practices. Each of these things can, of course, result in increased profits or lowered
expenses. Both are desirable outcomes. The information above should act as a bit of a primer
on the subject for those new to using analytics.
Pre-sales Activities

Since a long time, I was thinking to write down the pre-sales activities that we follow during
some RFI/RFP. This is what I have learnt when I was working with Patni and got some great
opportunities to work on some large size RFPs. Please let me know if this blog is useful for
you and also I would be happy to receive the feedback. Let me know if you want me
add/modify any of the activities below. Presales SPOC should be working between the
delivery and engagement management. Sales person from onsite will be sending all the RFI,
RFP and staff requirements to pre-sales person at offshore. Let us discuss them one by one:

Following tasks should be handled by the pre-sales person. Presales SPOC should be working
between the delivery and sales team. Sales person from onsite will be sending all the RFI,
RFP and staff requirements to pre-sales person at offshore. Let us discuss them one by one:

RFI (Request for Information)

Usually this type of information is required by the vendee when they are selecting
some vendors to start a new engagement. This exercise is usually done to check the
capability of the vendor.
When pre-sales person receives the RFI, he has to study the requirement.
First thing, he has to prepare one query sheet to ask questions from sales person and
the vendee (Customer) to gain the better understanding of the requirements.
Now he has to build the team from different areas, who will be working on the RFI
like Technical architect, domain architect (BA), legal, project management, finance
etc.
Once team is build, he has to kick off the RFI and set the expectations and divide the
work between all the stakeholders. Each and every person should have a clear roles &
responsibility, section ownership from RFI.
Usually, all the information for RFI is readily available in most of the organization
because this type of information is the general information regarding the companies.
Vendee used the RFI for the final selection of the vendors, who will be working on
the RFPs.
But in some cases, if deal size is large. Vendee is taking some extra precautions in
order to select the vendors. I have also worked in some RFI, which are equivalent to
RFP. Vendee gives information related to the technology stacks and domain at a
higher level. In this case, Vendor has to provide all the details on domain, and
multiple technical & methodologies solutions etc. Approximately as per the trend the
final document size in such cases ended up with around 100 pages.
Sales person also has to decide the template or response format if Vendee do not
restrict the response in some particular format. Response could be in the form of
document or presentation. However, vendee usually gives a fixed format in case of
RFI.
Most of the times, it is in the form of questions, which vendor has to respond.
Questions are almost from each department of the company that includes domain
expertise, technical expertise, available human resources on the domain and technical
experience, organizational standard processes, TOM, communication model etc.
 Once pre-sales person will receive the response from all the stakeholders. He will
integrate all the responses into the final template and will send to sales person after
having a proper review of the final outcome from the stakeholders and senior
management.
Delivery team also has to work on the billing/cost model and rate card for a particular
customer. Rate depends on the technology and domain for a particular country

RFP (Request for Proposal)

Once vendee selects a vendor based on the RFI submitted. Customer sends the RFP
based on the specific requirements.
RFP will require more detailed responses from each stakeholder because it will be
specific to a particular requirement/functionality.
Decision for Bid or No Bid: When vendor receives the RFP, the first thing vendor has
to do is to take a decision whether to bid or not to bid. It depends on the vendor's
capability on the RFP technology or domain or above all the kind of complexity RFP
requires in order to prepare the response. Remember this is very important.
Sometimes, responding to RFP itself is a kind of project, which requires a lot of
money to be spend on the RFP team.
While forming the team, pre-sales person should try to identify people who have
worked on the similar kind of the project/RFP.
Query sheet, response template and RFP tracker (R&R sheet: who owns what) is very
important for large size RFPs.
Query Sheet: Query sheet should have the following information:
o Document name - applicable in case there are more than one document in the
RFP.
o Section
o Page (Optional)
o Question
o Response
RFP Tracker: RFP tracker will contain each and every activities team will be doing
for the RFP.
o Each section that will be going into the response template; a kind of response
TOC
o Against each section, there should be a clear name written who will own the
response from that section
o Deadline for each section
o Review date from each reviewer
o Final submission date
Response Template: High level TOC is given below. However, this will be a detailed
in fact every detailed document. Most of the RFP document contain more than 100
pages. I still do not agree why do we create such a long document. I personally feel
that customer would never read such a long document ever.
o Executive Summary
o Understanding of the requirements
o Technical Solution - will contain the proposed architecture, tools etc.
o Domain Solution - will contain all the applicable features and how will the
future application/product represent them.
o Execution Methodology
o Governance Model
 o Schedule
o Cost/price/rate card
o Each section should be clear and crisp as per the vendee/customer
requirement. However, if vendor feels that more details/supporting
documentation should be provided in the response, that content can go into the
appendix.
Most of the times, there will be a lot of documentation as part of the RFP that need to
read and understood while forming the solution. In such cases, documents are divided
into different stakeholders for reading.
There should be a war room created for each large size RFP. All the important
stakeholders will work from a single location.
Daily meetings will help to track the progress and tracker will help its progress.
Debate on each and every topic will help to understand the requirements and come to
a conclusion.
Technical architect will work on the architecture, tools, software and licenses.
Domain architect (BA) will work on the detailed functionality or to define the
functionality scope.
Project management person will work on the methodology, governance model,
estimation, resourcing, costing, schedule, case studies, collecting profiles of the
names resources etc
Estimation, Costing, Resourcing, Risk, Assumptions inputs will be taken from
everybody
Final document/RFP should have Executive Summary (solution summary), Schedule,
Objective, Scope, Proposed technology stack, proposed domain solution, Proposed
technical solution, Engagement model or execution model, proposed project
deliverables, Project Plan (Gantt Chart), Acceptance criteria, Roles & Responsibility,
Assumptions, Risk Management, Commercial (Cost, pricing model, change control
process), Appendix and case studies.
Sometimes, you might have to work on the POCs to test the results of your solution.

Post RFP Submission

Once RFP is submitted. Selected vendors team need to present their solution at the
customer location. This is a detailed discussion on each solution/section. Mostly done
with the help of the ppt.
Vendor usually travel to customer location with its critical stakeholders who will
present their section on Technical, Domain, Project Management etc.
This is an important platform for the cost negotiations. Vendor usually negotiate on
the rate card or fixed price cost that vendor has proposed.
Selection of the vendor is not dependent on one parameter. It could be cost, solution,
timeframe etc that decide the decision.