Jun 3 2009 10:00AM GMT
Posted by: Jaideep
Project Management,
post implementation review,
project manager,
Software Project,
project completion,
project sign-off,
project closure,
software implementation,
project feedback
Both vendor and customer have to understand that the real journey of a product starts only after a successful implementation of software at customer site. The challenges get a new meaning once the project team leaves the customer site after project sign-off. Both the managements can celebrate the successful completion of project. But it is better to hold on this celebrations for a while, till customer really learns to live with the product, starts tasting the real fruits of the product committed earlier. Let the key users start managing the show on their own, run the complete process in live scenario and get satisfied with themselves and the product. The project team that comes at customer site for implementation has a role related to post implementation review prior they go back home after successful closure of project. Similarly the management (customer) have to clearly understand their critical role once the vendor project team goes back after the completion of project. It is the key users and management (customer) now to run and manage the show. No doubt that the vendor team is always at the back to support and assist them in achieving this. Let us assume that the project is over and team is about to leave the customer site. At this juncture it is the prime responsibility of vendor and customer project managers to shake hands and understand the importance of post implementation review in following terms:
The Project manager from vendor side has to hand over the post implementation review plan to customer at the time of implementation sign off and explain clearly each and every agenda of the post implementation review. The clarity in terms of product, managements, users, usage and product is very important for assessment purposes after a stipulated period.
The project manager from customer end has to ensure to get the post implementation plan for feedback purposes at the time of implementation sign off. This will not only leave the project open for another some time in terms of providing a lease for customer team to assess and experience the product in complete isolation in their own terms.
The purpose ultimately is to share the overall health of product, the key users, and the management.
May 29 2009 10:00AM GMT
Posted by: Jaideep
post implementation,
post implementation review,
Project Management,
project board,
project sign-off,
project closure,
Software Project,
software implementation,
project acceptance,
software performance,
product performance
When is to perform a post implementation review? A witty answer could be – obviously after implementation. Ha! Definitely a successful closure of implementation could declare a project closure with a formal project acceptance report or project sign off. So shall we have a post implementation review as soon as we have a project sign off? Nah! That would not solve the purpose. Give an appropriate time to the customer team key users to settle down as the captain of the ship and sail it smoothly. One day or one week smooth sailing will not tell you the turmoil or undercurrent storm about to come in future. Correct. Then future is too long. That means keep waiting for turmoil. But mind it, all ships sailing in the sea do not experience storm. Similarly all products after implementation and project sign off do not guarantee a serious disaster.
Product performance in actual sense requires a certain timeframe to establish and to give confidence to end users. Some part of post implementation review related to team performance (implementation) can be answered quickly, maybe immediately after the project closure. But the other part needs a considerable amount of time to understand the product from different perspectives and accordingly present a right picture in the review report.
Certainly, then, atleast a period of minimum three months is required to experience the product and then fill in the post implementation report. Ideally, I would say, wait for six months, use product in all respects, aggressively, and then the top management need to sit with their key users and project board to evaluate, assess and fill the post implementation review.
Apr 24 2009 10:06AM GMT
Posted by: Jaideep
Project Management,
Software Project,
project momentum,
project velocity,
project cost,
project time,
project organization,
customer engagement,
project sign-off,
project closure,
project training,
Project Plan,
Project Planning,
management involvement
Project overrun is simply a project crossing its boundaries set by the organization. These boundaries may vary from organization to organization depending on how they blindly or how over-extensively (both extremes) they want to look at it.
5 ways to control project overrun could be:
1. Requirements: With any change in requirements from customer, effort estimation and change in plan is important to drive the project in right direction.
2. Customer engagement: At customer site (or earlier as and when customer involvement is required) if customer project team is not justifiably involved in project by means of specifying requirements, providing master inputs, in training, timely sign-offs at various stages, hands-on exposures, etc. effects project drastically and plan may go haywired, without anybody’s accountability to prove, if alarm is not raised well in time.
3. Milestones: If appropriate milestones are not identified and monitored at every stage of the project, it affects the project finish off in time.
4. Management involvement: If management let the project go off without their involvement in it, it has high chances to overrun.
5. Celebrations: No celebrations of achievements during the project can decelerate the tempo and momentum of the team at both ends to finish off the project in time.
Apr 22 2009 9:51AM GMT
Posted by: Jaideep
Project Plan,
Project Planning,
Software Project,
project overrun,
project acceptance,
project organization,
customer requirements,
software requirements,
Project Management,
project closure,
project manpower management,
project cost,
project timeline,
project timeframe
All projects are prone to overrun. An overrun acceptance is directly proportional to an organization’s fault absorption capacity. Accordingly the definition of overrun is framed to demonstrate an overrun project as rightly completed project.
5 myths about Project Overrun could be:
5. Planning: After the initial plan is made, customer requirements have shrunk but it is good not to revise the plan to achieve in-time project closure (or even earlier).
4. Manpower: Project Plan is made after which additional manpower is inducted in the project, but no need to revise the plan.
3. Cost: Customer is ready to pay the full payment to complete the project, even if it overshoots the timeframe decided as per plan.
2. Time: A project had to complete in 5 months, but it took 10 months to complete. Imagine the manpower engaged in this project that could have finished another project if this project finished in time.
1. Customer: Customer is not able to cope up with plan but not ready to pay for extra efforts being done by the project team on behalf of customer thereby overshooting cost and time. We have a valid reason for this overshoot.
Apr 20 2009 10:05AM GMT
Posted by: Jaideep
project manager,
Project Management,
project implementation,
implementation phase,
project lead,
project ownership,
UAT,
business study,
business need,
software training,
implementation process,
implementation plan,
project team,
Risk Management,
Risk Plan,
post implementation,
process owner,
reconciliation,
transaction entry,
project sign-off,
project closure,
project failure,
project success
The customer project manager has to take the lead and ownership of product as soon as it is launched at customer site for implementation. The UAT, training and implementation process can only be effective in case customer project team gets fully involved into each and every activity of the implementation phase. Infact the implementation plan prepared by vendor project manager should be the responsibility of customer project manager to execute.
Customer Project manager and management has to clearly understand the risks involved during the business study, implementation and post implementation phase as highlighted by the vendor Project Manager and to act thereupon to overcome those risks with suggestions from vendor project manager.
These risks could be in terms of consequences involved:
if requirements are not complete and well defined,
the involvement of users and process owners during business study, implementation, UAT, masters creation, transaction entry, reconciliation etc.,
if sign-offs not happening in time, etc.
Even if the sign-off is given and product is not put in use, there is a chance of project failure at both ends.
Apr 16 2009 9:40AM GMT
Posted by: Jaideep
Project Management,
project manager,
Software Project,
software implementation,
project closure,
implementation plan,
project lead,
project team,
software acceptance
Project managers (the customer end and the vendor end) have to work hand in hand during the implementation stage of a software project happening at customer site. The key responsibility of both the project managers working on the project is to ensure successful implementation and project closure.
It is the customer project manager who has to take the charge, be in full lead and command to drive the project and keep the responsibility and onus to him and his management. The implementation plan has to be his baby all the time. Unless and until he takes the lead, he will not be able to put the potential fire in his team to accept the product. And then only he will be able to ensure a fully hassle free implementation.
