Hopefully the topic on Insurance was helpful...Today lets touch upon Business Analysis
Background
Who is a Business Analyst? Who activities does a Business Analyst perform?
In an IT based project, Business Analysts form the bridge between Business and IT. For Example, say we are implementing a Policy Administration System and have a Rate Structure Table that needs implemented, the business has been rating policies in Excel for past 20 years and now they want their Rates, Rating Factors, Discounts etc to be available in the Policy Admin Software so that when an Underwriter or Operations are processing a Quote for a Policy or Rating the policy for Renewals or some mid term endorsements, the UI properly allows them to rate the policy, just the way they have been doing it in the Excel form. Moreover the UI can also display log messages as to why a particular rating factor was applied, so that the Underwriter can view them and take corrective actions, if necessary.
Now this above is a Business scenario which a developer may not understand (Unless he has spent a few years in the Trenches and understands the business well, this is usually not the case)
This brings us to our Savior, the Hero - The Business Analyst. The Business Analyst is a person who not only understands the business, but also understands the IT aspect of it, which means he can ask the right questions to the End users and SMEs by holding workshops and then translate the Business requirements to High level design documents and specs that the Application Developers can comprehend and produce loads of software code that does what it is exactly supposed to...or so we hope.
For the requirement sessions or Gap analysis sessions as they are called, to proceed, the BAs are equipped with their quiver full of Use Cases. Use Cases are the documents that take a particular functionality and describe the application, System and user level interaction in that particular functionality using various scenarios. This helps clarify the various processes that business follows and sets the expectation from the business side as well as the IT side on how the future application to be implemented looks like.
Along with the getting the requirements on the functional scope, BAs are also involved in the business process mapping of the whole scene meaning for an insurance company that has been in business for say 30 long years, that has 12 regional offices and 200 adjusters, operators and underwriters that handle the day to day business. The Users are used to do the business in a certain way based on the IT application limitations, the business outlines and statutory and state mandated requirements set out. The job of the Business analysts here is to select a functional area, map the process using a process mapping application like Visio. For this, the BAs hold sessions/workshops with the business to understand their current process with the objective that how they can better the processes in the future. Help the organization in improving their bottom line. run the processes more efficiently so as to benefit the entities involved.
To give an example of business process improvement, there was an Insurance company that used a pretty outdated software to quote an insurance policy to an insured, who was (say) calling in for the first time. For this, the agents sitting in their office with the insured would first send the policy information to the insurance company via fax. It would be received by an operator who would then load the data in the system and give out a quote to the agent via another fax. This would take up atleast 30-40 mins for getting just an insurance quote. you don't want to know how long it took to bind and issue the policy. Anyways, by mapping the process flow, the BAs were able to show the organization that implementing Internet based IT solution would not only resolve the timing issue it would also fix any bottlenecks related to data inconsistency or incorrect data entry thus saving the insurance company tons of money and a happy customer in return.
Coming along, the BAs also help in System Testing, Regression Testing, End user testing the final application after it gets developed. They also help the Testing Team to design and develop the Test cases and Test scenarios.
Business Analysts are a very Unique breed and they gain expertise by their specific overall background, business knowledge by executing various projects etc
PreRequisites
Now we come to what it take to be a BA. If you are already in the field, you can skip this. If you are trying to enter into the field of business analysis, this may give you some idea.
The first and foremost prerequisite to being a Business Analyst is to have a an eagerness to understand the business domain which can be anything from Insurance to Banking to Manufacturing. Choose an area of your liking and move ahead.
The 2 main functions that a BA performs and would work towards his benefit if he has gained skills and knowledge in these areas
1> IT Process and Methodology
- i.e. Understand the IT Process lifecycle, the Inputs and deliverables for executing any project, using a specific Project Management Methodology
2> Business Knowledge
- Knowledge of the particular domain that you will be responsible for.
After you have acquired the knowledge, it is important to have some exposure via some realtime project exposure, there are some online and classroom courses also available that give you some first hand exposure via case studies etc
Let me know if you have any specific questions or viewpointd, i will be glad to answer and will try to guide and direct you in the proper direction
Do let me know through your comments if you found the article helpful.
Showing posts with label IT. Show all posts
Showing posts with label IT. Show all posts
Wednesday, March 13, 2013
Tuesday, February 12, 2013
Training, Coaching and Mentoring-I - The Basics
"Practice makes a man perfect"...But before practice comes - getting knowledge (or trained) in your area of choice....
To achieve excellence in any field you need to start with Training and Guidance,...followed by your Hardwork, dedication and gradual experience.
In today's competitive world, nothing comes easy....To gain an entry and make your mark in the favorite field, it has becoming increasingly difficult.
This article is for all those who are trying to enter the IT field or are looking to gain experience in their favorite area of work.
In one of my projects, I had a colleague who was an excellent integration developer and a solutions architect, but somehow he felt his calling was being a business analyst.
Then there were those who were Insurance business domain experts and want to try their hand at Project Management, based on their leadership qualities.
One of my colleagues from India recently got married. His wife was from the IT background back home, but had stopped working for past few years. Now she wanted to restart her career. I sat with them to see where her skillsets and background would fit, so she could contribute her knowledge and grow professionally and personally as well.
I gave them my two cents and that somehow led me thinking to this blog article and maybe a few subsequent few to follow. Bear in mind, i can only write about areas that i am know of.
So coming back, here are the steps i advise to my friends who are planning a change in their area of expertise or planning to gain more exposure to their favorite area of work
Analyze your interests - strengths and weakness
- Helps you gain insight on what you can do and need to work on. Builds your focus areas
Plan for the area of work
- Systematically find mentors or someone who can coach you, guide you and point you in the right direction
Gain systematic knowledge and exposure
- Gain knowledge, experience and real time exposure which is key.
Confidently march towards your dreams
- Last but not the least...go get'em tiger....
All the above steps are very important because once you have the requisite knowleldge and exposure, it helps boost your morale and confidence when you go for an interview.
If you are new to the IT Industry or going to enter a specialized Industry like IT for Insurance, it is always to your advantage to have some project background.
In the next few posts i will try to give some guidelines on some specific areas of work like Project Management, Business Analysis, Insurance basics, Packaged solutions for Insurance etc..so keep reading..
Also, please let me know your comments and feedback
To achieve excellence in any field you need to start with Training and Guidance,...followed by your Hardwork, dedication and gradual experience.
In today's competitive world, nothing comes easy....To gain an entry and make your mark in the favorite field, it has becoming increasingly difficult.
This article is for all those who are trying to enter the IT field or are looking to gain experience in their favorite area of work.
In one of my projects, I had a colleague who was an excellent integration developer and a solutions architect, but somehow he felt his calling was being a business analyst.
Then there were those who were Insurance business domain experts and want to try their hand at Project Management, based on their leadership qualities.
One of my colleagues from India recently got married. His wife was from the IT background back home, but had stopped working for past few years. Now she wanted to restart her career. I sat with them to see where her skillsets and background would fit, so she could contribute her knowledge and grow professionally and personally as well.
I gave them my two cents and that somehow led me thinking to this blog article and maybe a few subsequent few to follow. Bear in mind, i can only write about areas that i am know of.
So coming back, here are the steps i advise to my friends who are planning a change in their area of expertise or planning to gain more exposure to their favorite area of work
Analyze your interests - strengths and weakness
- Helps you gain insight on what you can do and need to work on. Builds your focus areas
Plan for the area of work
- Systematically find mentors or someone who can coach you, guide you and point you in the right direction
Gain systematic knowledge and exposure
- Gain knowledge, experience and real time exposure which is key.
Confidently march towards your dreams
- Last but not the least...go get'em tiger....
All the above steps are very important because once you have the requisite knowleldge and exposure, it helps boost your morale and confidence when you go for an interview.
If you are new to the IT Industry or going to enter a specialized Industry like IT for Insurance, it is always to your advantage to have some project background.
In the next few posts i will try to give some guidelines on some specific areas of work like Project Management, Business Analysis, Insurance basics, Packaged solutions for Insurance etc..so keep reading..
Also, please let me know your comments and feedback
Wednesday, January 2, 2013
Thought process Transformation
They say..If you show a dollar coin to an IT and Business Person both will look at it differently...
Business person will say "I wonder what is today's exchange rate?" and the IT person will say...""hhhmmm, this coin is shaped more like Alpha character "O" (Letter Oh) rather than numeric Zero"..(Not true...just made it up....but you get my point)....
IT developers and the business folks live and operate in 2 different worlds....unfortunately sometimes it is true...There should be steps taken by both sides to minimize this gap as much as possible...
Why?
A very basic necessity of working in today's world is to understand the business you are in and work towards supporting the business using your technology acumen and skills.
This is true, unless you work in a IT product based environment or somewhere else, where you may be working only to service your internal IT customers e.g. IT Infrastructure in a IT Company etc or you work alone on a marooned island manning a lighthouse switch.
Beyond that you have to work with the business.
This is required because Business is what drives Profits, Revenue and Sustainability to an Organization. Business has drivers like internal and external customers and partners, Competition, Compliance etc that decide and drive business and its exective decisions.
Coming from a Technology background, sometimes it becomes really difficult to think in terms of business, it is very easy to go back to the "Ones" and the "Zeros". During my initial IT Career days, being a consultant you have to wear the hat of an IT Developer cum Business Analyst, it becomes very difficult, to not think in terms of Tables and Columns and integrity data checks, rather in terms of Actors and Use cases, in front of the customer, who maybe as a Claims adjuster, is trying to explain how to send data to a glass vendor from the claim screen and wait for an amount estimate for damage repairs and then has to follow an escalation process so it gets approval if amount for repair was above the assigned claim adjuster's limit.
This really requires a major mindset change, a paradigm shift, if you may... wherein you get away from the developer mindset, where you in your own world do an efficient and scalable High level and low level designs and develop and unit test your own software to a Business person who tries to understand the people who run the business, their process and thinks of ways the technology can help them to make their work easier, better, faster and more efficient and smoother.
How?
The most important way to do this is, "to place yourself in the other person's shoes" and think the way he/she goes about the business day. This will help understand their painpoints and in turn help you to help them.
Certain steps that can be taken to overcome this chasm would be,
1> Get IT and Business aligned...In terms of Corporate Business goals and Objectives.
2> Companies to organize trainings, seminars for IT folk and business alike to make each side of the other side. For instance, hold workshops for business expaining them an IT lifecycle, what is a Functional document, high level designs, Integration, System Testing etc. Similarly for IT Folks, explain them the business processes and not just give them specs and expect the work to be done.
3> Have regular IT/Business meetings, maybe on a monthly/weekly basis where there will be general updates from both sides, Q&A to understand more and better
4> More involvement of IT Developers in Business meetings so they can understand the discussions and business painpoints and start thinking in terms of making those better.
Let me know your comments if you feel there are some points that can be added/modified to help you.
Business person will say "I wonder what is today's exchange rate?" and the IT person will say...""hhhmmm, this coin is shaped more like Alpha character "O" (Letter Oh) rather than numeric Zero"..(Not true...just made it up....but you get my point)....
IT developers and the business folks live and operate in 2 different worlds....unfortunately sometimes it is true...There should be steps taken by both sides to minimize this gap as much as possible...
Why?
A very basic necessity of working in today's world is to understand the business you are in and work towards supporting the business using your technology acumen and skills.
This is true, unless you work in a IT product based environment or somewhere else, where you may be working only to service your internal IT customers e.g. IT Infrastructure in a IT Company etc or you work alone on a marooned island manning a lighthouse switch.
Beyond that you have to work with the business.
This is required because Business is what drives Profits, Revenue and Sustainability to an Organization. Business has drivers like internal and external customers and partners, Competition, Compliance etc that decide and drive business and its exective decisions.
Coming from a Technology background, sometimes it becomes really difficult to think in terms of business, it is very easy to go back to the "Ones" and the "Zeros". During my initial IT Career days, being a consultant you have to wear the hat of an IT Developer cum Business Analyst, it becomes very difficult, to not think in terms of Tables and Columns and integrity data checks, rather in terms of Actors and Use cases, in front of the customer, who maybe as a Claims adjuster, is trying to explain how to send data to a glass vendor from the claim screen and wait for an amount estimate for damage repairs and then has to follow an escalation process so it gets approval if amount for repair was above the assigned claim adjuster's limit.
This really requires a major mindset change, a paradigm shift, if you may... wherein you get away from the developer mindset, where you in your own world do an efficient and scalable High level and low level designs and develop and unit test your own software to a Business person who tries to understand the people who run the business, their process and thinks of ways the technology can help them to make their work easier, better, faster and more efficient and smoother.
How?
The most important way to do this is, "to place yourself in the other person's shoes" and think the way he/she goes about the business day. This will help understand their painpoints and in turn help you to help them.
Certain steps that can be taken to overcome this chasm would be,
1> Get IT and Business aligned...In terms of Corporate Business goals and Objectives.
2> Companies to organize trainings, seminars for IT folk and business alike to make each side of the other side. For instance, hold workshops for business expaining them an IT lifecycle, what is a Functional document, high level designs, Integration, System Testing etc. Similarly for IT Folks, explain them the business processes and not just give them specs and expect the work to be done.
3> Have regular IT/Business meetings, maybe on a monthly/weekly basis where there will be general updates from both sides, Q&A to understand more and better
4> More involvement of IT Developers in Business meetings so they can understand the discussions and business painpoints and start thinking in terms of making those better.
Let me know your comments if you feel there are some points that can be added/modified to help you.
Wednesday, June 27, 2012
IT Negotiations
There are a very few natural born negotiators, the rest have to practice.....
Negotiations happen everyday and everywhere, in various forms all around us. Our day starts reasoning with the kids to make them drink a glass of Milk, negotiating the price of an antique showpiece you want, from a mom & pop Thrift shop.
Even Professional negotiations follow the same rules as these day to day negotiations, maybe on a more detailed level.
Not everyone is an expert negotiator, but someone who has the skills and has been doing it with the right attitude & panache, actually does a lot of winning.
Nowadays IT projects consume a major chunk of an organization's revenue, sometimes upto 20-25 percent according to a recent study. Many companies are utilizing their hard earned revenues to solidify and streamline their IT Process and systems, so that they can reap the business benefits in times to come. For this reason it makes sense for both parties in an IT deal to be Negotiations savvy. Due to the fear of an unknown outcome, Negotiations are very much dreaded by IT and business folks alike. It is kept as a last minute activity and attacked head on when time comes - Something like a Deer staring at a racing car's Headlights and then you know how it goes.
If proper time is spent on planning and executing negotiations, you will reap the benefits in times to come - in form of increased profits and revenues and successfully executed projects.
IT Negotiations occur at various levels - Marketing, Pre-Sales, Sales, Project Scoping, Resourcing, Contractual agreements in terms of Contract types, SLAs, Milestones and Commit dates etc
Negotiations occur between various parties - IT Firms, Servicing companies, Clients (Insurance companies in my case), at various levels - project level between Team members, leads and resources, clients and vendors, suppliers and end users etc
Negotiation skills help,
Achieve project goals and objectives
Avoid unnecessary conflicts and arguments later in the project lifetime
Build trust and priorities amongst the project teams
How to be a good negotiator?
Practice, practice and some more practice.
Good negotiation skills should be imbibed in your senses. Organizations usually have a cut out approach towards negotiation, something that defines their org culture, e.g. having negotiation planning meetings, specific negotiation templates and proceses etc. Overall, the negotiation Team's objectives and motives have to be aligned with the organizational agenda. The corporate direction could either be a Win All-Lose none (Aggressive), Win some-Lose Some (Moderate) or Win-win for both (Practical). It all depends on what strategic importance the deal has for the corporation.
On a personal level, an important skillset for a successful negotiator is soft skills - i.e. ability to have meaningful and engaging conversations. Conversations that lead the other party to reveal or atleast point to their interests and areas that will help you build focus and leverage. Something that will help develop relationships between with all parties involved. Remember here from a psychological perspective, everyone wants to win in life, be it negotiations or a free 5 day cruise to the Caribbean.
To cite an example - On one of the projects i was managing, we responsible for an Insurance Installation for a mid size P&C Carrier, the contract was signed based on initial high level estimation, but during the actual scoping and definition phase, the client wanted the everything under the sun to be included.
After much efforts and involvement of many a c-level executives and a heavy level setting exercise, the client finally agreed on the scope which could be delivered in the duration of the project. The way the client agreed to the option was, if the client wanted 100 things to be done in the project duration and cost, the quality of the product would suffer, but to have the best quality installation within the project cost and timeline which will help the client achieve set their business goals, it was beneficial to both parties to cut scope and go live with 70 items which would have the best quality.
Negotiation Steps
Every negotiation is a logical process, it has a beginning, the actual process and the end or specifically "Pre-Negotiation", "Negotiation" and "Closing".
Pre-Negotiation involves
Establishing an objective, background preparation or doing your homework, (Always start with a 10000 ft view of what you want out of the negotiation and why you want it - i.e. laying the objectives, ground rules and favorable expected outcome and finally how you wil get there).
This includes establishing a steering commitee, involving all related stakeholders, end users, everyone who will be impacted by the project or contract negotiation. Because doing this later in th`e game will not give you much wiggle room to try and resolve issues, incase an impacted party gets left out or finds something that may de-rail the whole deal. Preparing the RACI chart for all involved parties also helps as it clearly defines what is expected of each involved party. Laying down the negotiation rules and guidelines on rules of conduct during the negotiation path.
Negotiation includes
Meeting on the set dates and having discussions per agenda and guidelines decided. This helps to have focused discussions and helps achieve the desired positions effectively. Also make sure the Teams meet internally on a regular basis afterwards, while negotiations are in progress so if team member needs to be aligned or steered or some points need to be given in or held against, can be avaluated and then comes
Negotiation Planning should include contract break clauses, long term contract pricing policies and sharing the Total cost of ownership for a contract.
The total breakdown of all fees sould be enforced in a contract, SLAs and other KPIs to evaluate the levels of service provided.
Closure and Lessson learned (This is the most important step in every negotiation and is also the most missed one). If this is followed as a regular process, rather than a 1 time post negotiation activity or if done only for certain high profile negotiations it will miss its actual impact and utility.
Lessons learned will actually help you learn and do course correction which may help save many a future negotiations. This may also help you lay foundations for setting an organization culture in terms of process and templates setup
Essentially for any negotiation to be successful you have to have the right set of people, tools and strategies, past experiences, thoughtful planning and documentation.
Negotiations happen everyday and everywhere, in various forms all around us. Our day starts reasoning with the kids to make them drink a glass of Milk, negotiating the price of an antique showpiece you want, from a mom & pop Thrift shop.
Even Professional negotiations follow the same rules as these day to day negotiations, maybe on a more detailed level.
Not everyone is an expert negotiator, but someone who has the skills and has been doing it with the right attitude & panache, actually does a lot of winning.
Nowadays IT projects consume a major chunk of an organization's revenue, sometimes upto 20-25 percent according to a recent study. Many companies are utilizing their hard earned revenues to solidify and streamline their IT Process and systems, so that they can reap the business benefits in times to come. For this reason it makes sense for both parties in an IT deal to be Negotiations savvy. Due to the fear of an unknown outcome, Negotiations are very much dreaded by IT and business folks alike. It is kept as a last minute activity and attacked head on when time comes - Something like a Deer staring at a racing car's Headlights and then you know how it goes.
If proper time is spent on planning and executing negotiations, you will reap the benefits in times to come - in form of increased profits and revenues and successfully executed projects.
IT Negotiations occur at various levels - Marketing, Pre-Sales, Sales, Project Scoping, Resourcing, Contractual agreements in terms of Contract types, SLAs, Milestones and Commit dates etc
Negotiations occur between various parties - IT Firms, Servicing companies, Clients (Insurance companies in my case), at various levels - project level between Team members, leads and resources, clients and vendors, suppliers and end users etc
Negotiation skills help,
Achieve project goals and objectives
Avoid unnecessary conflicts and arguments later in the project lifetime
Build trust and priorities amongst the project teams
How to be a good negotiator?
Practice, practice and some more practice.
Good negotiation skills should be imbibed in your senses. Organizations usually have a cut out approach towards negotiation, something that defines their org culture, e.g. having negotiation planning meetings, specific negotiation templates and proceses etc. Overall, the negotiation Team's objectives and motives have to be aligned with the organizational agenda. The corporate direction could either be a Win All-Lose none (Aggressive), Win some-Lose Some (Moderate) or Win-win for both (Practical). It all depends on what strategic importance the deal has for the corporation.
On a personal level, an important skillset for a successful negotiator is soft skills - i.e. ability to have meaningful and engaging conversations. Conversations that lead the other party to reveal or atleast point to their interests and areas that will help you build focus and leverage. Something that will help develop relationships between with all parties involved. Remember here from a psychological perspective, everyone wants to win in life, be it negotiations or a free 5 day cruise to the Caribbean.
To cite an example - On one of the projects i was managing, we responsible for an Insurance Installation for a mid size P&C Carrier, the contract was signed based on initial high level estimation, but during the actual scoping and definition phase, the client wanted the everything under the sun to be included.
After much efforts and involvement of many a c-level executives and a heavy level setting exercise, the client finally agreed on the scope which could be delivered in the duration of the project. The way the client agreed to the option was, if the client wanted 100 things to be done in the project duration and cost, the quality of the product would suffer, but to have the best quality installation within the project cost and timeline which will help the client achieve set their business goals, it was beneficial to both parties to cut scope and go live with 70 items which would have the best quality.
Negotiation Steps
Every negotiation is a logical process, it has a beginning, the actual process and the end or specifically "Pre-Negotiation", "Negotiation" and "Closing".
Pre-Negotiation involves
Establishing an objective, background preparation or doing your homework, (Always start with a 10000 ft view of what you want out of the negotiation and why you want it - i.e. laying the objectives, ground rules and favorable expected outcome and finally how you wil get there).
This includes establishing a steering commitee, involving all related stakeholders, end users, everyone who will be impacted by the project or contract negotiation. Because doing this later in th`e game will not give you much wiggle room to try and resolve issues, incase an impacted party gets left out or finds something that may de-rail the whole deal. Preparing the RACI chart for all involved parties also helps as it clearly defines what is expected of each involved party. Laying down the negotiation rules and guidelines on rules of conduct during the negotiation path.
Negotiation includes
Meeting on the set dates and having discussions per agenda and guidelines decided. This helps to have focused discussions and helps achieve the desired positions effectively. Also make sure the Teams meet internally on a regular basis afterwards, while negotiations are in progress so if team member needs to be aligned or steered or some points need to be given in or held against, can be avaluated and then comes
Negotiation Planning should include contract break clauses, long term contract pricing policies and sharing the Total cost of ownership for a contract.
The total breakdown of all fees sould be enforced in a contract, SLAs and other KPIs to evaluate the levels of service provided.
Closure and Lessson learned (This is the most important step in every negotiation and is also the most missed one). If this is followed as a regular process, rather than a 1 time post negotiation activity or if done only for certain high profile negotiations it will miss its actual impact and utility.
Lessons learned will actually help you learn and do course correction which may help save many a future negotiations. This may also help you lay foundations for setting an organization culture in terms of process and templates setup
Essentially for any negotiation to be successful you have to have the right set of people, tools and strategies, past experiences, thoughtful planning and documentation.
Friday, September 30, 2011
Vendor Procurement and Management
Family man, family problems....My wife and i have been working on finding a Nanny for our 3 year old for past few weeks....Let me say its not an easy task....you have to go through classifieds, talk to your network of friends, interview people for the position, negotiate terms, the whole nine yards...
This activity made me think about writing this article.
Working as an IT Manager, many a times we come across similar scenarios wherein the Client would want to go through a Vendor procurement Process.
For the sake of simplicity, we will refer to the Organization seeking Vendor Services as a "buyer".
Here are a few scenarios from my Insurance world, why a buyer would look for Vendor services,
1> Outsourcing Services
- An Insurance company say. wants to focus its attention on the Insurance Business and does not want to be sidetracked with IT Issues. So it would naturally want to partner with one or more IT Firms to run its business applications, maintain hardware, do application modifications to maintain and Competitive edge in its business domain.
2> IT Consulting Services
- An Insurance company in business for years and decades would have lots of in-house and Third party applications and services communicating with each other. Thus if the company wants to overhaul and upgrade its infrastructure, hardware or software systems for better and reliable performance and scalability, it has to procure services from Vendors who have handled similar Business Transformation Initiatives.
3> Technology Solutions
- An Insurance Company wants to (say.) move away from its Legacy applications and march towards the latest and greatest state of the art application suite available in the market to better run its business.
These are some of the reasons why the procurement manager would want follow proper Vendor Procurement guidelines. Failure to do so, may lead to problems and issues in the whole venture and many a times may lead to scrapping the whole deal either midway or towards the end of the project.
Here are the top 3 reasons why Procurement process may fail,
1> No clear requirement specifications and hence no clear understanding of the exact scope of work.
2> Carelessness in terms of contract clauses negotiations. No clear review of Vendor Contract terms and conditions.
3> Unrealistic targets and deadlines promised and accepted by both parties during the procurement process.
A Vendor Procurement process just like any project life cycle has 4 distinct phases, They are,
1> Requirement scope and Elaboration
- The Buyer has to elaborate on the exact requirements that will be shared with the Vendors and clearly defines why you are seeking the vendor services. These requirements may be Technical, functional etc as the case demands.
There will be a team of Business analysts and Functional experts who will meet the necessary business users to gather the exact requirements and thus prepare the requirements specifications documentation.
2> Vendor Selection
- The requirements specifications created are used to prepare an RFI (Request for Information), RFP (Request for Proposal) or RFQ (Request for Quotation) etc as the case may be.
The buyer Organization prepares a selected Vendor list and sends RFIs/RFP to them. The set of vendors must meet a predefined selection criteria set by the buyer organization. These prospective vendors will be someone, who already do similar service for the buyer organization or are in similar business as the work scope demands.
Before sending out the questionnairre to the Vendor make sure there is a confidentiality Non Disclosure agreement signed, as here the buyer may share some Business sensitive information with the potential vendors. It is necessary to safeguard the business information and Intellectual property from competition.
After this, if the vendors have some technical questions or need any clarifications, the buyer may arrange for a common Q&A session or they may request the vendor questions via email.The buyer sets a deadline for the questions and queries so they can be reviewed and answered.
The prospective Vendors have to be aware of the milestone dates and the formal processes like routing the questions through the procurement Manager etc.
The Procurement Manager is responsible for responding to the questions. The same information should be shared with all vendors, so that no one gets any unfair advantage in this process and in turn will also help the vendors understand the requirements better.
3> Contracting and Contract Administration
After receiving responses from the Bidders or Vendors, the buyer has its own selection criteria to finalize the vendor for the job. This is usually based on some weightage program, Vendor rating system, Proposal evaluation technique or expert judgement etc.
After the vendor selection is complete, then comes the contracting phase. In this phase, the contract agreement (this may also called as the Statement of work, Letter of Intent etc) that is sent by the vendor company has to be carefully read and scrutinized so that both parties agree to the terms and conditions in the contract and it is favorable to both parties. If there is any clarification, ambiguity in any of the points, seek clarification from the Vendor representative immediately.
Contract Administration is a very important phase for successful execution of the Contract. During execution, there may be some changes required to the Project scope, milestone and deadlines approval processes set.
The Contract should also be a project acceptance and completion criteria specified. e.g. For a new Policy System installation and enhancement project, the acceptance criteria specified should be in terms of service or scope delivery timeline (say 12 months) with (say) 2 Critical, 4 Medium and 6 low level bugs open.
There should be software SLA specified in the contract.
There should also be processes set for change controls. This includes tools, techniques and activities that help to monitor the change control process and control the project scope and timeline.
These contracts are generally prepared and reviewed by the legal departments with definite help and inputs from the procurement manager who forms the main coordinator. So make sure the contract is well understood by you - the Procurement Manager. It is detailed and elaborate. The contract has to specify the penalties to be imposed on the vendor in case of missed deadlines like any pricing credits or additional resource guarantee etc
4> Exit and Renewal criteria
The contract also has to specify the exit criteria for extreme cases like either party wants to exit out. e.g. If the buyer wants to default on a contract, there will be a penalty of (say) $500,000 and 2 months notice period and the entire knowledge base will become the Intellectual property of the Vendor Organization.
In case the buyer wants to extend the contract with the vendor, the renewal criteria also has to be specified.
e.g. Annual Maintenance contract for supporting Policy and Claims Administration system can be extended with IT vendor 'X' provided the application went live with max 2 open defects and specified timeline. This will have an elaborate pricing, resourcing and timelines specified.
The service SLA for Annual Maintenance is response in 1 business day and solution within 2 business days for critical issues and 3 business days for regular issues.
Thus Vendor procurement and Contract Management is a very important process for organizations that do business with external vendors. So proper knowledge of the process is an absolute must for both the Buyer and Vendor Organizations.
This activity made me think about writing this article.
Working as an IT Manager, many a times we come across similar scenarios wherein the Client would want to go through a Vendor procurement Process.
For the sake of simplicity, we will refer to the Organization seeking Vendor Services as a "buyer".
Here are a few scenarios from my Insurance world, why a buyer would look for Vendor services,
1> Outsourcing Services
- An Insurance company say. wants to focus its attention on the Insurance Business and does not want to be sidetracked with IT Issues. So it would naturally want to partner with one or more IT Firms to run its business applications, maintain hardware, do application modifications to maintain and Competitive edge in its business domain.
2> IT Consulting Services
- An Insurance company in business for years and decades would have lots of in-house and Third party applications and services communicating with each other. Thus if the company wants to overhaul and upgrade its infrastructure, hardware or software systems for better and reliable performance and scalability, it has to procure services from Vendors who have handled similar Business Transformation Initiatives.
3> Technology Solutions
- An Insurance Company wants to (say.) move away from its Legacy applications and march towards the latest and greatest state of the art application suite available in the market to better run its business.
These are some of the reasons why the procurement manager would want follow proper Vendor Procurement guidelines. Failure to do so, may lead to problems and issues in the whole venture and many a times may lead to scrapping the whole deal either midway or towards the end of the project.
Here are the top 3 reasons why Procurement process may fail,
1> No clear requirement specifications and hence no clear understanding of the exact scope of work.
2> Carelessness in terms of contract clauses negotiations. No clear review of Vendor Contract terms and conditions.
3> Unrealistic targets and deadlines promised and accepted by both parties during the procurement process.
A Vendor Procurement process just like any project life cycle has 4 distinct phases, They are,
1> Requirement scope and Elaboration
- The Buyer has to elaborate on the exact requirements that will be shared with the Vendors and clearly defines why you are seeking the vendor services. These requirements may be Technical, functional etc as the case demands.
There will be a team of Business analysts and Functional experts who will meet the necessary business users to gather the exact requirements and thus prepare the requirements specifications documentation.
2> Vendor Selection
- The requirements specifications created are used to prepare an RFI (Request for Information), RFP (Request for Proposal) or RFQ (Request for Quotation) etc as the case may be.
The buyer Organization prepares a selected Vendor list and sends RFIs/RFP to them. The set of vendors must meet a predefined selection criteria set by the buyer organization. These prospective vendors will be someone, who already do similar service for the buyer organization or are in similar business as the work scope demands.
Before sending out the questionnairre to the Vendor make sure there is a confidentiality Non Disclosure agreement signed, as here the buyer may share some Business sensitive information with the potential vendors. It is necessary to safeguard the business information and Intellectual property from competition.
After this, if the vendors have some technical questions or need any clarifications, the buyer may arrange for a common Q&A session or they may request the vendor questions via email.The buyer sets a deadline for the questions and queries so they can be reviewed and answered.
The prospective Vendors have to be aware of the milestone dates and the formal processes like routing the questions through the procurement Manager etc.
The Procurement Manager is responsible for responding to the questions. The same information should be shared with all vendors, so that no one gets any unfair advantage in this process and in turn will also help the vendors understand the requirements better.
3> Contracting and Contract Administration
After receiving responses from the Bidders or Vendors, the buyer has its own selection criteria to finalize the vendor for the job. This is usually based on some weightage program, Vendor rating system, Proposal evaluation technique or expert judgement etc.
After the vendor selection is complete, then comes the contracting phase. In this phase, the contract agreement (this may also called as the Statement of work, Letter of Intent etc) that is sent by the vendor company has to be carefully read and scrutinized so that both parties agree to the terms and conditions in the contract and it is favorable to both parties. If there is any clarification, ambiguity in any of the points, seek clarification from the Vendor representative immediately.
Contract Administration is a very important phase for successful execution of the Contract. During execution, there may be some changes required to the Project scope, milestone and deadlines approval processes set.
The Contract should also be a project acceptance and completion criteria specified. e.g. For a new Policy System installation and enhancement project, the acceptance criteria specified should be in terms of service or scope delivery timeline (say 12 months) with (say) 2 Critical, 4 Medium and 6 low level bugs open.
There should be software SLA specified in the contract.
There should also be processes set for change controls. This includes tools, techniques and activities that help to monitor the change control process and control the project scope and timeline.
These contracts are generally prepared and reviewed by the legal departments with definite help and inputs from the procurement manager who forms the main coordinator. So make sure the contract is well understood by you - the Procurement Manager. It is detailed and elaborate. The contract has to specify the penalties to be imposed on the vendor in case of missed deadlines like any pricing credits or additional resource guarantee etc
4> Exit and Renewal criteria
The contract also has to specify the exit criteria for extreme cases like either party wants to exit out. e.g. If the buyer wants to default on a contract, there will be a penalty of (say) $500,000 and 2 months notice period and the entire knowledge base will become the Intellectual property of the Vendor Organization.
In case the buyer wants to extend the contract with the vendor, the renewal criteria also has to be specified.
e.g. Annual Maintenance contract for supporting Policy and Claims Administration system can be extended with IT vendor 'X' provided the application went live with max 2 open defects and specified timeline. This will have an elaborate pricing, resourcing and timelines specified.
The service SLA for Annual Maintenance is response in 1 business day and solution within 2 business days for critical issues and 3 business days for regular issues.
Thus Vendor procurement and Contract Management is a very important process for organizations that do business with external vendors. So proper knowledge of the process is an absolute must for both the Buyer and Vendor Organizations.
Subscribe to:
Posts (Atom)