Project Acceptance archives - Quality Assurance and Project Management
Home > IT Blogs > Quality Assurance and Project Management >

Quality Assurance and Project Management:

project acceptance

May 29 2009   10:00AM GMT

Post Implementation Review – When, ldeally?



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.

AddThis Social Bookmark Button     0 Comments     RSS Feed     Email a friend

Apr 22 2009   9:51AM GMT

5 myths about Project Overrun



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.

    • AddThis Social Bookmark Button     0 Comments     RSS Feed     Email a friend