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.
Share your comments and feedback on Project Management Topics. This Blog discusses about general Project Management tips and articles. It focuses on how different Project Management aspects like cost, time, scope, quality and resources impact an IT project and their relationship to Property and Casualty related Policy, Billing and Claims Projects. This blog also has posts about Insurance Concepts and insurance industry functioning and processes
Showing posts with label project success definition. Show all posts
Showing posts with label project success definition. Show all posts
Thursday, January 3, 2013
Wednesday, May 18, 2011
Manage Stakeholder Expectations
Many things have been written and said about Managing Stakeholder Expectations. This is one of the most difficult tasks a project manager has to perform throughout the life cycle of the project depending upon the type and number of stakeholders involved. Essentially what may mean as a 'perfect and successful' project to the project manager, may turn out to be a complete disaster in the eyes of the stakeholders.
During Concept Phase:
A Project is conceptualized when the stakeholders or project sponsors meet and layout the project idea. Objectives and goals are set at this stage and a project is born. Once it has taken a definite shape and the ball has started rolling and the project progresses from the concept or initiation phase to design, construction, testing and finally delivery and closure. At every stage, we, as Project Managers have to manage stakeholder expectations.
Every stakeholder comes from a different arena or a different functional area and therefore has different definition of success. Hence it is very important at the onset, to make sure all stakeholders are on the same page and are driving towards a common goal. This is achieved in the Project Kick off meeting. The project sponsors or the ones who had laid the project high level objectives may not be the only ones who are the actual stakeholders that are involved with the project, as the project progresses you will find the number of stakeholders and actual representatives may also vary.
So, from the initial requirement sessions you may find that the stakeholders that get involved are deviating from the ground rule and are asking for something that is not in project scope or not inline with the general project agenda.
This may happen due to various reasons,
1> Stakeholders not clear on the Project Objectives
2> Need some understanding wrt different project areas or how projects are executed.
It is the job of the Project Manager to make sure these risks are addressed at proper time by proper planning.
Example:
Coming to an insurance industry example of this scenario,
say the project deals with integrating your Policy-Claims administration system with a Contacts management software and during the stakeholder meetings, the discussions lean towards tweaking and tuning of another dependant 3rd party interface - CMS upload for medicare.
Agreed, the 2 items may be related, but that does not definitely mean that the other interface is to be handled in this project scope (Unless that is the way the project has been scoped out).
To handle this situation make sure the project objectives are strongly and succintly communicated to the stakeholders that we are integrating to a new contact management software and this may mean some changes associated to some middleware bridge to make the other contact dependent interfaces work as expected, with minimal to no impacts. This lays a ground rule and restricts the deviations that may otherwise happen.
How to:
Major steps to stakeholder management in any project large or small are,
Step 1:
Conduct Stakeholder interviews:
- Study your stakeholders - their roles, who they are - organizational positions, their project roles - e.g. sponsors, end users, business SMEs, what they do? How would they influence the project outcome - completely understand their 'needs' and 'beliefs'? All this can be managed by having a 'Stakeholder map'.
- Know them wrt likes, dislikes, project expectation etc
Step 2:
Stakeholder Communication:
This is the most important thing in any project. I cannot stress on how important is this factor to guarantee a project success.
- Involve your stakeholders in all stages of the project right from initiation.
- Try to understand the project objectives from the stakeholders perspective. What does it mean to them by project success/failures/key painpoints etc? Let them define this in their own terms.
- Familiarize them with project financials, give them an overall project picture by having regular project status report meetings. In these meetings, make sure you concentrate on areas that are important to the stakeholders rather than delving into your project management methodologies and bravado stories.
- By effective communication and holding them accountable to project realities in times of project changes we can definitely and successfully manage stakeholder expectations. Remember Stakeholders and Project Sponsors have as much vested interest in project success as everyone.
During Concept Phase:
A Project is conceptualized when the stakeholders or project sponsors meet and layout the project idea. Objectives and goals are set at this stage and a project is born. Once it has taken a definite shape and the ball has started rolling and the project progresses from the concept or initiation phase to design, construction, testing and finally delivery and closure. At every stage, we, as Project Managers have to manage stakeholder expectations.
Every stakeholder comes from a different arena or a different functional area and therefore has different definition of success. Hence it is very important at the onset, to make sure all stakeholders are on the same page and are driving towards a common goal. This is achieved in the Project Kick off meeting. The project sponsors or the ones who had laid the project high level objectives may not be the only ones who are the actual stakeholders that are involved with the project, as the project progresses you will find the number of stakeholders and actual representatives may also vary.
So, from the initial requirement sessions you may find that the stakeholders that get involved are deviating from the ground rule and are asking for something that is not in project scope or not inline with the general project agenda.
This may happen due to various reasons,
1> Stakeholders not clear on the Project Objectives
2> Need some understanding wrt different project areas or how projects are executed.
It is the job of the Project Manager to make sure these risks are addressed at proper time by proper planning.
Example:
Coming to an insurance industry example of this scenario,
say the project deals with integrating your Policy-Claims administration system with a Contacts management software and during the stakeholder meetings, the discussions lean towards tweaking and tuning of another dependant 3rd party interface - CMS upload for medicare.
Agreed, the 2 items may be related, but that does not definitely mean that the other interface is to be handled in this project scope (Unless that is the way the project has been scoped out).
To handle this situation make sure the project objectives are strongly and succintly communicated to the stakeholders that we are integrating to a new contact management software and this may mean some changes associated to some middleware bridge to make the other contact dependent interfaces work as expected, with minimal to no impacts. This lays a ground rule and restricts the deviations that may otherwise happen.
How to:
Major steps to stakeholder management in any project large or small are,
Step 1:
Conduct Stakeholder interviews:
- Study your stakeholders - their roles, who they are - organizational positions, their project roles - e.g. sponsors, end users, business SMEs, what they do? How would they influence the project outcome - completely understand their 'needs' and 'beliefs'? All this can be managed by having a 'Stakeholder map'.
- Know them wrt likes, dislikes, project expectation etc
Step 2:
Stakeholder Communication:
This is the most important thing in any project. I cannot stress on how important is this factor to guarantee a project success.
- Involve your stakeholders in all stages of the project right from initiation.
- Try to understand the project objectives from the stakeholders perspective. What does it mean to them by project success/failures/key painpoints etc? Let them define this in their own terms.
- Familiarize them with project financials, give them an overall project picture by having regular project status report meetings. In these meetings, make sure you concentrate on areas that are important to the stakeholders rather than delving into your project management methodologies and bravado stories.
- By effective communication and holding them accountable to project realities in times of project changes we can definitely and successfully manage stakeholder expectations. Remember Stakeholders and Project Sponsors have as much vested interest in project success as everyone.
Friday, April 29, 2011
What is a Project?
A Project is an initiative, by definition is a temporary endeavor set to create a unique product or a service which has a defined start and end date, specific goals and conditions, defined roles and resp, constraints and risks etc.
Some people do not have a clear idea of what a project consists of. Project is not about setting up a bunch of repetitive Tasks and making sure that they happen. It is much more than that. True projects involves a unique effort (If it is repetitive, it is no longer a project), Projects have clearly defined objectives, have a defined lifespan or a one time effort.
Let's take an example of a Project and how it would be executed.
Again, every project is unique but it does follow some common standards and Guidelines, more or less
Digging a well is a project. It involves a predefined and a set Objective,
Objective - Dig a well so that it provides drinking water to a set of people (Stakeholders).
There are a bunch of people to bear the expenses for the well being dug (Sponsors)
There are a bunch of people who will dig the well (resources)
The well digging initiative will be managed by a person (Project Manager).
The activities performed by the manager will be something along these lines,
- Project sponsors come with a requirement ( Dig a well). They have a budget and an objective and a high level roadmap in mind (Provide water to group of people by end of next 3 months - Budget $5000)
- Project sponsors appoint a Project Manager who starts with meeting the stakeholders involved, sponsors to understand scope, budget, timelines.
- Prepares a Plan based on high level Scope understood, sets Milestones, plans resources, deliverables to be achieved/delivered.
- Prepares a schedule based on this High level plan.
- Gets resources approved, allocated for the project term duration
- Prepares a high level communication plan, risk analysis and management plan, configuration and change management plan
- Gets a sign off on the project charter, SOW
- Holds a project kick off meeting with all the stakeholders involved on the project.
- elaborates on the Project plan with the Project Team wrt identifying the work activities, schedule, risks, mitigation plans etc
- Team designs and develops as per the plan
- Regularly meets with the Team to identify issues, risks, mitigation plans/strategy, works on coordination and facilitation activities.
- Regularly updates the Stakeholders, Sponsors etc on the overall Prject status
- Finally project is delivered to the Stakeholders
Some people do not have a clear idea of what a project consists of. Project is not about setting up a bunch of repetitive Tasks and making sure that they happen. It is much more than that. True projects involves a unique effort (If it is repetitive, it is no longer a project), Projects have clearly defined objectives, have a defined lifespan or a one time effort.
Let's take an example of a Project and how it would be executed.
Again, every project is unique but it does follow some common standards and Guidelines, more or less
Digging a well is a project. It involves a predefined and a set Objective,
Objective - Dig a well so that it provides drinking water to a set of people (Stakeholders).
There are a bunch of people to bear the expenses for the well being dug (Sponsors)
There are a bunch of people who will dig the well (resources)
The well digging initiative will be managed by a person (Project Manager).
The activities performed by the manager will be something along these lines,
- Project sponsors come with a requirement ( Dig a well). They have a budget and an objective and a high level roadmap in mind (Provide water to group of people by end of next 3 months - Budget $5000)
- Project sponsors appoint a Project Manager who starts with meeting the stakeholders involved, sponsors to understand scope, budget, timelines.
- Prepares a Plan based on high level Scope understood, sets Milestones, plans resources, deliverables to be achieved/delivered.
- Prepares a schedule based on this High level plan.
- Gets resources approved, allocated for the project term duration
- Prepares a high level communication plan, risk analysis and management plan, configuration and change management plan
- Gets a sign off on the project charter, SOW
- Holds a project kick off meeting with all the stakeholders involved on the project.
- elaborates on the Project plan with the Project Team wrt identifying the work activities, schedule, risks, mitigation plans etc
- Team designs and develops as per the plan
- Regularly meets with the Team to identify issues, risks, mitigation plans/strategy, works on coordination and facilitation activities.
- Regularly updates the Stakeholders, Sponsors etc on the overall Prject status
- Finally project is delivered to the Stakeholders
Subscribe to:
Posts (Atom)