'Resurrection' is life....Well, hold on!....I am not being philosophical...atleast not at a level that i will start giving you dictums of wisdoms. But i can definitely share with you something that i am absolutely sure all of you must have faced and experienced ( or something similar) somewhere in your personal/professional life.
Somethings things go great and sometimes they don't...that's just life...
And when they dont, that is when it becomes a cause of concern. Be it a Project worth 1000s or millions of dollars or be it your pefectly planned weekend getaway gone awry.
So professionally, to manage these situations, we have this breed of specimen called 'Project Managers' - whose job is to ensure things stay on track. Project Managers ensure that the project are run and executed smoothly, Projects meet their set goals and objectives and we all achieve and even overachieve our targets.
Examples of Awry
Personal
In our personal lives, say, we buy a house, we start to pay our mortgages diligently and then somewhere down the line, we miss a payment due to something unforeseen - a medical emergency, a job/family situation, mortgage plan changes etc, we start spiraling down the Rabbit hole.
Professional
Imagine a situation when you are on a project that is just not going the way as planned, the reports are all pointing that things have started to go wrong and it is time to raise the red flag....Hopefully you find this, before the Captain asks to abandon ship.
So what do we do when things start spiraling the path it was not meant to be...a Project down on its knees...
A Policy Admin implementation which kicked off with a much held fanfare and furore but suddenly somewhere down the way failed to keep up.
I have been a part of such a project which i will say, is a classic case study for this article. This project was a 3 year - multi Million dollar Enterprise level P&C Admin apps Setup project. It was a new organization entering P&C business that had engaged us for a policy, billing and claims solution setup....Successfully execution would have made the careers of many a people on the project, not to mention the benefits to the client, if it had met the roadmap timelines.
Initially things went well as planned for a few months then we started missing deadlines, good resources were leaving the project, client was having 2nd thoughts on using us as successful partners. It came to such a point that our consulting Org was threatened with a liability lawsuit, as we had risked the client's plan of going live with its new programs and products in a new market that would have really given them a competitive edge.
How did we come out of this mess.
First Things First
First we calmly took stock of where were on the project
- We had all our key stakeholders, responsible parties together. Tried to understand and outline how and where things went wrong.
Once we know the 'what' and 'why's, we decide to focus our energies positively, be constructive and stay away from the blame game as it was not going to help anyone....we remained focused and started to work on 'how' to fix the problem.
Come up with a plan to go from point A to point B
We had regular meetings with the Stakeholders and finally arrived at a consensus on what needed to be done
In your case, it may include things like,
Timeline changes
- Extending the project timeline
Scope changes
- changing the work scope to fit the timeline
Resourcing changes
- Lining up your A resources to get the job done, shuffling resources per competencies
Cost and budget changes
- Increase project budget
Unthinkable option
- Dumping the project altogether. Sadly, this happens in many cases when you are on a time bound project and you completely miss it.
Once you have the plan ready, make sure to dot your Is and cross your Ts. Have an executive summary of your plan ready. This will serve you 2 purposes, you will need it to convince your project sponsors that you are taking the necessary steps to get on track and the funding should continue.
Also this presentation will also help curb the project level noise, if any. You can use the same presentation with maybe a little tweaks for removing your team fears on where the project is going. Proper communication within Team is absolutely essential.
Later on, when things get back on track and project completes successfully(i am sure!...), remember to have a lessons learned session with the whole Team so we learn from our mistakes and future run is a lot smoother.
One of the major takeaway for our project case was, have regular status reports, meetings set that will highlight slippages right at the onset.
Summary
So all in all, as they say...'stuff happens'...It is all about how do we separate the men from the boys and get our act together and make sure all of us march towards the common goal of a successful project implementation.
Let me know if you all agree or have a different perspective, input on things based on your experiences.
Monday, December 2, 2013
Wednesday, March 13, 2013
Training, Coaching and Mentoring-II - Business Analysis
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.
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.
Friday, February 22, 2013
Training, Coaching and Mentoring-II - Insurance
Continuing our Topic....Today we will touch upon "Insurance Basics"
Firstly, Who should read this?
If you are a beginner in the Insurance Industry or Insurance related field like IT, Business.
If you are an IT Techie and are working in the Insurance domain for sometime now...this article is for you
If you are someone who has a liking for insurance or are curious about the inner know-hows and basics
or someone who wants to have some valueadd to his knowledge and skills.....go ahead and read
I came to the insurance industry quite by chance. For around 4 years since i graduated i had worked on C++ and Java assignments..all non-Insurance. Then i joined a company which specialized in Property and Casualty Insurance - Policy, Billing and Claims Administration Product development and Installation. I was the solutions architect for the product. I loved what i did there....This job Introduced me to the insurance industry and showed me how product functionality and performance considerations gave us Happy customers...and sometimes poor management and mis-alignment of objectives gives unhapy customers, but let's keep that for another article.....
Coming to Insurance basics,
Why do we need Insurance?
Insurance is a very thriving and an absolutely necessary industry which has borne the shocks of the failing economy. To think of it, be it an bear market or bull, everyone needs insurance, right from buying a home to a car or your personal health and life to insuring smaller electronic gadgets and devices...Insurance is everywhere.
Insurance is a form of risk management and mitigation technique wherein you pay the insurer a "Premium" to accept a portion or all of your associated "risk". And if god forbid, things do go wrong, as they sometimes do, you-The Insured, will file a "claim" and based on the Insurance premium you pay, the "coverages" that you have applicable on your "policy", the insurance company "Adjuster" will work with you and try to work with you on the "Actual Value" or the "Market value" based on the years of "Depreciation" of the Item that you are insured and are claiming for...with the objective of ensuring the "Insured" gets to the "same economic situation" as before. The Objective of Insurance is to cover the loss, so that insured bounces back to the same economic state as before the loss.
This is as elementary as i can get to explain what is insurance to a Layman.
Where did the Insurance concept come from?
Long time ago, when there were to TVs, planes or IPods....when traders and merchants took their goods to faraway places for trading, sometimes they lost the goods to weather conditions, pirates or some other Loss making situations and had to bear a loss. So they came up with rather ingenious ways to "self-Insure" their goods or mitigate their "Risk" or losses.
The Merchants would get together and pool a set amount of money so as to compensate the trader who lost his goods or they would sometimes give extra amount of money to the lenders, from whom they bought goods as a means of insuring against losses in trade.
What are the types of Insurance?
As i said, Insurance is applicable and available in all walks of life...right from Personal to commercial..within that at a very high level, you can dividie insurance into Life, General and Health. Within General you have personal, Commercial. Within that you have Property and Casualty.
The area within Personal and Commercial at a High level would be,
Auto, General Liability, Property, Worker's Comp, Home Owners, Inland Marine, Specialty Lines etc. Each of these, as their names suggest cater to a specific area of Business. There are certain insurance companies that deal with certain specialities or some that do a mix.
There is also another interesting area within Insurance called Re-Insurance wherein, an Insurance Carriers (also called Ceding Company) reinsures part or all of his associated risk with another Company (Reinsurer). The Insurance agreements between them are of various types namely Facultative or Treaty reinsurance etc based on the risk selection criteria etc
What are the industry known and recognized certifications?
Now that you have a basic background and knowledge about insurance, to gain more insight into your particular area of expertise, be it a specific Product like Guidewire, Pega, DuckCreek, Accenture etc related to Policy, Billing and Claims Administration or you aim to become to Business SME for Policy, Billing or Claims...
Make sure you find a right mentor to lead you and guide you in the right direction. Take firm and steady steps towards your career goals and confidently rise the success ladder.
Let me know if you have any specific questions or doubts, i will be glad to help 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.
Firstly, Who should read this?
If you are a beginner in the Insurance Industry or Insurance related field like IT, Business.
If you are an IT Techie and are working in the Insurance domain for sometime now...this article is for you
If you are someone who has a liking for insurance or are curious about the inner know-hows and basics
or someone who wants to have some valueadd to his knowledge and skills.....go ahead and read
I came to the insurance industry quite by chance. For around 4 years since i graduated i had worked on C++ and Java assignments..all non-Insurance. Then i joined a company which specialized in Property and Casualty Insurance - Policy, Billing and Claims Administration Product development and Installation. I was the solutions architect for the product. I loved what i did there....This job Introduced me to the insurance industry and showed me how product functionality and performance considerations gave us Happy customers...and sometimes poor management and mis-alignment of objectives gives unhapy customers, but let's keep that for another article.....
Coming to Insurance basics,
Why do we need Insurance?
Insurance is a very thriving and an absolutely necessary industry which has borne the shocks of the failing economy. To think of it, be it an bear market or bull, everyone needs insurance, right from buying a home to a car or your personal health and life to insuring smaller electronic gadgets and devices...Insurance is everywhere.
Insurance is a form of risk management and mitigation technique wherein you pay the insurer a "Premium" to accept a portion or all of your associated "risk". And if god forbid, things do go wrong, as they sometimes do, you-The Insured, will file a "claim" and based on the Insurance premium you pay, the "coverages" that you have applicable on your "policy", the insurance company "Adjuster" will work with you and try to work with you on the "Actual Value" or the "Market value" based on the years of "Depreciation" of the Item that you are insured and are claiming for...with the objective of ensuring the "Insured" gets to the "same economic situation" as before. The Objective of Insurance is to cover the loss, so that insured bounces back to the same economic state as before the loss.
This is as elementary as i can get to explain what is insurance to a Layman.
Where did the Insurance concept come from?
Long time ago, when there were to TVs, planes or IPods....when traders and merchants took their goods to faraway places for trading, sometimes they lost the goods to weather conditions, pirates or some other Loss making situations and had to bear a loss. So they came up with rather ingenious ways to "self-Insure" their goods or mitigate their "Risk" or losses.
The Merchants would get together and pool a set amount of money so as to compensate the trader who lost his goods or they would sometimes give extra amount of money to the lenders, from whom they bought goods as a means of insuring against losses in trade.
What are the types of Insurance?
As i said, Insurance is applicable and available in all walks of life...right from Personal to commercial..within that at a very high level, you can dividie insurance into Life, General and Health. Within General you have personal, Commercial. Within that you have Property and Casualty.
The area within Personal and Commercial at a High level would be,
Auto, General Liability, Property, Worker's Comp, Home Owners, Inland Marine, Specialty Lines etc. Each of these, as their names suggest cater to a specific area of Business. There are certain insurance companies that deal with certain specialities or some that do a mix.
There is also another interesting area within Insurance called Re-Insurance wherein, an Insurance Carriers (also called Ceding Company) reinsures part or all of his associated risk with another Company (Reinsurer). The Insurance agreements between them are of various types namely Facultative or Treaty reinsurance etc based on the risk selection criteria etc
What are the industry known and recognized certifications?
Now that you have a basic background and knowledge about insurance, to gain more insight into your particular area of expertise, be it a specific Product like Guidewire, Pega, DuckCreek, Accenture etc related to Policy, Billing and Claims Administration or you aim to become to Business SME for Policy, Billing or Claims...
Make sure you find a right mentor to lead you and guide you in the right direction. Take firm and steady steps towards your career goals and confidently rise the success ladder.
Let me know if you have any specific questions or doubts, i will be glad to help 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.
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, February 6, 2013
Project Management Styles
Yesterday my 4 year old son wanted candies for Dinner and i firmly gave him 'No Candies for Dinner' speech. It was a difficult task, i am sure you all will understand. He was, let us say, less willing to be onboard.
As all kids are, he tried all tricks in the book to get his point across. You of course know how this story goes...
Everyone makes some or the other decisions everyday. Be it a life changing decision say, to get married or have kids or marginally life changing ones like where to take your better half for Dinner (Which now that i think of it can also be a major decision whether it a Four Star Restaurant or a roadside eatery).
Everone has their own decision making styles that are inculcated in him/her based on their subconscious thought process, their upbringing, their own innate nature or how they have moulded themselves over the time.
Today we will talk about some of these decision styles or when used in a Project Management Environment.
These different styles are Authoritative, Experienced, Collaborative, Democratic and Laissez Faire.
Let us talk about each approch in detail and decide see which approach suits best in which situations.
Authoritative -
Authoritative Project Management style is when the Project Manager has a decision maker position and tries to coerce or enforce his decisions on the Team without understanding the project situation or team views and thoughts.
This decision making does not necessarily mean he has the experience to understand the situations and has taken a 360 view before coming to a conclusion. This merely means he is in a Authority position and people will listen to him just because of that.
This definitely can lead to many a problematic situations and i have heard enough horror stories where Authoritarian Project Managment has led the project aground because the decision makers were simply not ready to read the signs on the wall.
Long ago, I was a developer in an insurance application project where we had 20 people development team and the Client has enough experience in executing these type of projects. We were developing a policy application system for the client. Since the client had executed multiple projects of this type, he wanted to have a buy-in on some of the decisions wrt what development tools we used, how we did our code reviews and code check-ins to ensure quality, but our Project Manager at that time was jut not ready to listen and did what he thought was right, which led to situations where there was a lot of blame game played and ultimately the client ended up in not renewing the contract at the end of the term and our Executive leadership was left wondering what went wrong and why did we lose the Client.
Experienced -
An Experienced style of Project Management is when you have been there and done that. The project manager has been in the area of project management for a long term and knows how, when and where to execute projects. He knows the nuances, the ins and outs of the project. This is a leader that i would definitely like to follow - well, to an extent.
It is definitely beneficial to the project and gives the team a sense of security when the project manager does and knows his job.
Collaboratative -
This Project Management style intersects with the next one wherein you as a project manager want to decide on something and will take the buy in of all your members as well as your stakeholders. Sometimes this is a win-in style as everyone who has a say will contribute to the decisions and once the team is involved this ensures their commitment and sincere dedication. This is less formal than the democratic style as you may not actually vote for a buyin. This works well for a large scale transformation type projects wherein you have multiple dispersed teams, areas that may be in multiple geographies.
Democratic -
This is similar to collaboration where is the project members take decisions as a team, but with everyone's buy in and voting. Here there is a risk that certain team members - the minority Team members may feel left out. So it is important for the project manager to get them onboarded on the decisions, actively and sincerely listen to their points and those team members get and stay involved. Because if those team members start to lose interest in the project and feel that they are not listened then that may not be beneficial to the project.
Laissez Faire -
Last but not the least 'Laissez Faire' - or i call it the 'Cruise Control'. This is actually a very effective style of management but only works if the team has enough experience and expertise in executing these type of projects. Here the team is self monitored and self led and sort of runs the ship on cruise control.
Basically here the team has been in these situations that the project brings forth many a times. If a project manager decides to execute the project with this style based on team experience then it actually turns out to be a positive as team feels motivated that they have a say in the decisions and a feeling that they are running the project. But this can also negatively impact the project if the team is not experienced or less exerienced in handling these type of projects, they may run the project aground. So the project Manager has to carefully decide and choose looking at the all around situation with his Team.
So all in all, the project manager has to decide how to run a project based on the surrounding internal and external conditions and situations. Sometimes it will make sense to run a project with a particular style and sometimes use a mix of these Styles. You be the judge.
Do let me know your thoughts and comments on the above article
As all kids are, he tried all tricks in the book to get his point across. You of course know how this story goes...
Everyone makes some or the other decisions everyday. Be it a life changing decision say, to get married or have kids or marginally life changing ones like where to take your better half for Dinner (Which now that i think of it can also be a major decision whether it a Four Star Restaurant or a roadside eatery).
Everone has their own decision making styles that are inculcated in him/her based on their subconscious thought process, their upbringing, their own innate nature or how they have moulded themselves over the time.
Today we will talk about some of these decision styles or when used in a Project Management Environment.
These different styles are Authoritative, Experienced, Collaborative, Democratic and Laissez Faire.
Let us talk about each approch in detail and decide see which approach suits best in which situations.
Authoritative -
Authoritative Project Management style is when the Project Manager has a decision maker position and tries to coerce or enforce his decisions on the Team without understanding the project situation or team views and thoughts.
This decision making does not necessarily mean he has the experience to understand the situations and has taken a 360 view before coming to a conclusion. This merely means he is in a Authority position and people will listen to him just because of that.
This definitely can lead to many a problematic situations and i have heard enough horror stories where Authoritarian Project Managment has led the project aground because the decision makers were simply not ready to read the signs on the wall.
Long ago, I was a developer in an insurance application project where we had 20 people development team and the Client has enough experience in executing these type of projects. We were developing a policy application system for the client. Since the client had executed multiple projects of this type, he wanted to have a buy-in on some of the decisions wrt what development tools we used, how we did our code reviews and code check-ins to ensure quality, but our Project Manager at that time was jut not ready to listen and did what he thought was right, which led to situations where there was a lot of blame game played and ultimately the client ended up in not renewing the contract at the end of the term and our Executive leadership was left wondering what went wrong and why did we lose the Client.
Experienced -
An Experienced style of Project Management is when you have been there and done that. The project manager has been in the area of project management for a long term and knows how, when and where to execute projects. He knows the nuances, the ins and outs of the project. This is a leader that i would definitely like to follow - well, to an extent.
It is definitely beneficial to the project and gives the team a sense of security when the project manager does and knows his job.
Collaboratative -
This Project Management style intersects with the next one wherein you as a project manager want to decide on something and will take the buy in of all your members as well as your stakeholders. Sometimes this is a win-in style as everyone who has a say will contribute to the decisions and once the team is involved this ensures their commitment and sincere dedication. This is less formal than the democratic style as you may not actually vote for a buyin. This works well for a large scale transformation type projects wherein you have multiple dispersed teams, areas that may be in multiple geographies.
Democratic -
This is similar to collaboration where is the project members take decisions as a team, but with everyone's buy in and voting. Here there is a risk that certain team members - the minority Team members may feel left out. So it is important for the project manager to get them onboarded on the decisions, actively and sincerely listen to their points and those team members get and stay involved. Because if those team members start to lose interest in the project and feel that they are not listened then that may not be beneficial to the project.
Laissez Faire -
Last but not the least 'Laissez Faire' - or i call it the 'Cruise Control'. This is actually a very effective style of management but only works if the team has enough experience and expertise in executing these type of projects. Here the team is self monitored and self led and sort of runs the ship on cruise control.
Basically here the team has been in these situations that the project brings forth many a times. If a project manager decides to execute the project with this style based on team experience then it actually turns out to be a positive as team feels motivated that they have a say in the decisions and a feeling that they are running the project. But this can also negatively impact the project if the team is not experienced or less exerienced in handling these type of projects, they may run the project aground. So the project Manager has to carefully decide and choose looking at the all around situation with his Team.
So all in all, the project manager has to decide how to run a project based on the surrounding internal and external conditions and situations. Sometimes it will make sense to run a project with a particular style and sometimes use a mix of these Styles. You be the judge.
Do let me know your thoughts and comments on the above article
Thursday, January 3, 2013
Successful Project Definition
I remember many years back i was on a fix schedule, T&M project with a large scope, it was a Mid Tier Company Claims System implementation and we had reached the project closedown phase and the end product had been finally delivered to the client followed by a month's warranty and post production support. The application was in Production for over a month and we, as vendors were all ready to wrap up. Then we got an email from the Client CEO saying they did not consider the project as closed as there were 3 functionalities not yet delivered, the service time was less than expected and the quality of the software delivered was sub par.
What went wrong here? Let's see...
Definition of Success
Everyone wants their project to be a success. But How do you define success? Is it when the developers have cleared their desks? Is it when the Deliverable is handed over to the Client? Is it when the Project End date is reached? Is it when the last Invoice is cleared? Is it when the product delivered meets defined quality standards and criteria? Or is it that the project was on time and within budget?
A Project has multiple stakeholders. Fact of the matter is, everyone has a different definition of Success. Every stakeholder looks at the project from his/her point of view and thus defines success from their looking glass.
Project success definition has to be a collaborative effort. Both the client and the vendor have to have a common goal defined. At the very onset of the project, it is the responsibility of the Client Organization to have a clear and tangible vision of what defines project success for them. The definition should be in measurable and understandable terms i.e. in terms of KPIs, SLAs etc
e.g For a Policy and Claims Processing web application,
- 500 Concurrent users access the System at Peak load with zero down time
- Page load time should not be more than 2 secs at peak.
- System should be able to process Intake, Adjudication, Salvage and Subrogation and search functionality for a claim without any errors.
- Intake functionality processing should take no more than 30 seconds...and so on....
Collaboration
Once the success criteria are defined by the client, these should be discussed with the Implementation vendor. The vendor's job is to completely understand and analyze the success definition. He should prod and question the client for any issues or clarifications because ultimately he is the one, who has to deliver on those. If there are any client dependencies that would need to be satisfied for the project to be delivered those have to be implicitly added to the SoW so everyone is on the same terms e.g. Infrastructure requirements, software, Licenses, Third party vendor relationships etc. Once all criteria are mutually agreed upon, it should be an integral part of the SoW (Statement of work).
Success criteria is also important for defining project milestones. This helps the sponsor and executive team track the progress of the project. This helps the project Manager take corrective action in case there are some ups and downs in the project during execution phase.
Ensure that the signoff requirements, Team responsible for signoff are also defined.
Success at each stage of the project has to be shared with the Team so that they are aligned with the Progress and know that their contribution to the project is what makes the project a success.
Relationship
Lastly there is a criteria that i think to be very essential for a project success and that is relationship. The type and level of relationship fostered between a client and a vendor defines success or atleast the perception of it. I have worked as a consultant with clients where i knew that the client could have been more rigid and firm when it came to finally signing off on a project, but because the client knew our work quality, dedication, efforts and the amount of energy we had spent in understanding the business, requirements and scope, he is also ready to let a few things slide off.
So to summarize,
Define entry and exit criteria that would make a project a success
Have tracking mechanisms in place to make sure the criteria are reached
Keep all the stakeholders and Team members in the Loop during each phase of project.
So the Key to a project success is meeting and exceeding client expectations.
Let me know if you all agree or if you hold a different view to this.
What went wrong here? Let's see...
Definition of Success
Everyone wants their project to be a success. But How do you define success? Is it when the developers have cleared their desks? Is it when the Deliverable is handed over to the Client? Is it when the Project End date is reached? Is it when the last Invoice is cleared? Is it when the product delivered meets defined quality standards and criteria? Or is it that the project was on time and within budget?
A Project has multiple stakeholders. Fact of the matter is, everyone has a different definition of Success. Every stakeholder looks at the project from his/her point of view and thus defines success from their looking glass.
Project success definition has to be a collaborative effort. Both the client and the vendor have to have a common goal defined. At the very onset of the project, it is the responsibility of the Client Organization to have a clear and tangible vision of what defines project success for them. The definition should be in measurable and understandable terms i.e. in terms of KPIs, SLAs etc
e.g For a Policy and Claims Processing web application,
- 500 Concurrent users access the System at Peak load with zero down time
- Page load time should not be more than 2 secs at peak.
- System should be able to process Intake, Adjudication, Salvage and Subrogation and search functionality for a claim without any errors.
- Intake functionality processing should take no more than 30 seconds...and so on....
Collaboration
Once the success criteria are defined by the client, these should be discussed with the Implementation vendor. The vendor's job is to completely understand and analyze the success definition. He should prod and question the client for any issues or clarifications because ultimately he is the one, who has to deliver on those. If there are any client dependencies that would need to be satisfied for the project to be delivered those have to be implicitly added to the SoW so everyone is on the same terms e.g. Infrastructure requirements, software, Licenses, Third party vendor relationships etc. Once all criteria are mutually agreed upon, it should be an integral part of the SoW (Statement of work).
Success criteria is also important for defining project milestones. This helps the sponsor and executive team track the progress of the project. This helps the project Manager take corrective action in case there are some ups and downs in the project during execution phase.
Ensure that the signoff requirements, Team responsible for signoff are also defined.
Success at each stage of the project has to be shared with the Team so that they are aligned with the Progress and know that their contribution to the project is what makes the project a success.
Relationship
Lastly there is a criteria that i think to be very essential for a project success and that is relationship. The type and level of relationship fostered between a client and a vendor defines success or atleast the perception of it. I have worked as a consultant with clients where i knew that the client could have been more rigid and firm when it came to finally signing off on a project, but because the client knew our work quality, dedication, efforts and the amount of energy we had spent in understanding the business, requirements and scope, he is also ready to let a few things slide off.
So to summarize,
Define entry and exit criteria that would make a project a success
Have tracking mechanisms in place to make sure the criteria are reached
Keep all the stakeholders and Team members in the Loop during each phase of project.
So the Key to a project success is meeting and exceeding client expectations.
Let me know if you all agree or if you hold a different view to this.
Wednesday, January 2, 2013
First Day
Well begun is half done...
You just completed a plush assignment or maybe its your first job....or maybe It is your new assignment on a new job whatever the case maybe, i am sure everyone in their career, has been there sometime.
Especially if you are in the consulting world like me, you will see a lot of "First Days on a project or in a new organization"
My approach to this first day has changed a lot over time...here are some thoughts related to that....
Remember when we were beginning our life's journey as 3-4 year old, our parents held our hands and took us to a pre-school, Pre-K, Kindergarten, first grade etc....and then when we grow up, more experienced about schooling, we planned our first days to college, who do we meet there? What to wear?, How to walk, talk etc.
Then comes the professional world...here again initially we are in the blank and need some hand holding, then we turn deft and know how to tread and where...I will try to give some tips and observations on what i have seen and experienced...
Let's say, you just finished a Job assignment and have landed another meaty assignment after aceing an interview.
Here's how and what you should plan for,
1> Background
Nowadays every bit of information about a company is online, especially if it is a listed company. Try to gather as much about the company as you can. It is always good to know what business the company is in, who are the clients, overseas business, turnover, revenues and most importantly the competitors....This information gathering will help hone your thinking process towards understanding the company, the culture, the business, the steps taken at the C-Level etc.
Here again try to gather information about the company culture, the corporate goals and objectives etc.
This will help you even if you are not an employee of the company and are just going to work there as an external consultant.
Based on the above and your area of skillset for which you are hired, prepare a 2-3 minute elevator pitch about yourself. Not necesarily, say it out to every other person you meet on your first day (Unless you want to make it your last day too). Depending on the type of conversation or meeting you are having, be ready to use it in parts or whole as required.
2> Social Networking sites- LinkedIn etc
Social Networking can help you a lot here in terms of gaining useful perspectives from people who work at that organization, their view points about the organization, people performing different roles at the organization on how they view their peers, subordinates, C-Level executives and the business in general.
3> Know your work area and domain
You already are a master of your domain area because this is what is going to be your most useful weapon which will help you outshine your peers and help you in gaining trust within the organization. If there is a certain area of skill that you need to perform or something you know you are not too comfortable with, try working on it, polishing it, so you do it confidently when you need it.
4> Unlearn
This is very important. Every Organization has its own working Methodology and process and steps to execute a project. In IT, some may follow waterfall, Agile, RUP and some have flavors of their own. They have their own internal politics and work culture nuances that you may have been used to, and your brain may have been accustomed to think that it is right. But it may not be so.
So be ready to unlearn the old and accept the new, if need be. For this, make sure you watch, watch and watch, people around you...
5> Communicate, Communicate and Communicate
Last but not the least, when you in, be ready to communicate, talk to your peers, subordinates, bosses, customers, partners. Understand the roles that they perform and their viewpoints. This will help streamline your thought process and give you a 360 degree perspective on the business as a whole.
Once you are armed with the above, things should become fairly easy. Make sure you are pleasant and greet people you meet. Atleast give a smile, right from the person next to you in the elevator to the colleague who sits next to you.
When you meet someone have a good erect posture, confident smile and a few lines to say to the other person. Give the other person a line or 2 about yourself and inquire about him/her asking about his job background general local information etc. These generally act as good ice breakers.
If you are not comfortable, doing this...practice this a few times if front of the elevator...Remember your first day on the job is just as important as the job interviews...because this is when people (by way of human nature) will form an initial opinion about you, which if for any reason is a wrong one,it will be very difficult to reason and build a new one.
As they say, Plan before execution....sooner than you think, you will be sitting amongst the best in the crowd and be accepted for your skills and expertise and the genuine person that you are.
Please comment if you agree, if there is something you feel i missed here
You just completed a plush assignment or maybe its your first job....or maybe It is your new assignment on a new job whatever the case maybe, i am sure everyone in their career, has been there sometime.
Especially if you are in the consulting world like me, you will see a lot of "First Days on a project or in a new organization"
My approach to this first day has changed a lot over time...here are some thoughts related to that....
Remember when we were beginning our life's journey as 3-4 year old, our parents held our hands and took us to a pre-school, Pre-K, Kindergarten, first grade etc....and then when we grow up, more experienced about schooling, we planned our first days to college, who do we meet there? What to wear?, How to walk, talk etc.
Then comes the professional world...here again initially we are in the blank and need some hand holding, then we turn deft and know how to tread and where...I will try to give some tips and observations on what i have seen and experienced...
Let's say, you just finished a Job assignment and have landed another meaty assignment after aceing an interview.
Here's how and what you should plan for,
1> Background
Nowadays every bit of information about a company is online, especially if it is a listed company. Try to gather as much about the company as you can. It is always good to know what business the company is in, who are the clients, overseas business, turnover, revenues and most importantly the competitors....This information gathering will help hone your thinking process towards understanding the company, the culture, the business, the steps taken at the C-Level etc.
Here again try to gather information about the company culture, the corporate goals and objectives etc.
This will help you even if you are not an employee of the company and are just going to work there as an external consultant.
Based on the above and your area of skillset for which you are hired, prepare a 2-3 minute elevator pitch about yourself. Not necesarily, say it out to every other person you meet on your first day (Unless you want to make it your last day too). Depending on the type of conversation or meeting you are having, be ready to use it in parts or whole as required.
2> Social Networking sites- LinkedIn etc
Social Networking can help you a lot here in terms of gaining useful perspectives from people who work at that organization, their view points about the organization, people performing different roles at the organization on how they view their peers, subordinates, C-Level executives and the business in general.
3> Know your work area and domain
You already are a master of your domain area because this is what is going to be your most useful weapon which will help you outshine your peers and help you in gaining trust within the organization. If there is a certain area of skill that you need to perform or something you know you are not too comfortable with, try working on it, polishing it, so you do it confidently when you need it.
4> Unlearn
This is very important. Every Organization has its own working Methodology and process and steps to execute a project. In IT, some may follow waterfall, Agile, RUP and some have flavors of their own. They have their own internal politics and work culture nuances that you may have been used to, and your brain may have been accustomed to think that it is right. But it may not be so.
So be ready to unlearn the old and accept the new, if need be. For this, make sure you watch, watch and watch, people around you...
5> Communicate, Communicate and Communicate
Last but not the least, when you in, be ready to communicate, talk to your peers, subordinates, bosses, customers, partners. Understand the roles that they perform and their viewpoints. This will help streamline your thought process and give you a 360 degree perspective on the business as a whole.
Once you are armed with the above, things should become fairly easy. Make sure you are pleasant and greet people you meet. Atleast give a smile, right from the person next to you in the elevator to the colleague who sits next to you.
When you meet someone have a good erect posture, confident smile and a few lines to say to the other person. Give the other person a line or 2 about yourself and inquire about him/her asking about his job background general local information etc. These generally act as good ice breakers.
If you are not comfortable, doing this...practice this a few times if front of the elevator...Remember your first day on the job is just as important as the job interviews...because this is when people (by way of human nature) will form an initial opinion about you, which if for any reason is a wrong one,it will be very difficult to reason and build a new one.
As they say, Plan before execution....sooner than you think, you will be sitting amongst the best in the crowd and be accepted for your skills and expertise and the genuine person that you are.
Please comment if you agree, if there is something you feel i missed here
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.
Subscribe to:
Posts (Atom)