Quality Assurance and Project Management:

Risk Plan

May 8 2009   10:09AM GMT

Change Management in terms of people – how to manage during a project



Posted by: Jaideep
change management, Project Management, Software Project, Risk Plan, Risk Management, risk mitigation, manpower management, Project Lifecycle, project stages, project guidelines

Although it can not be avoided in real life scenario and that is why there is a risk plan and risk management to avoid such circumstances. But still a lot can be done to atleast minimize the risk and thereby mitigation.

Vendor - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and team members during the project lifecycle.
They also have to ensure that the project is handled in such a manner that any change(s) happening therein will not affect or delay any of the stage.

Customer - Management has to ensure the bare minimum changes (preferably NO CHANGES) in terms of project manager and key users during the project lifecycle.
They also have to ensure to adhere to the guidelines specified by vendor project manager to manage such change(s) so that it does not affect or delay the project during any stage of the project.

Apr 20 2009   10:05AM GMT

Role of customer project manager at customer site during implementation stage



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 17 2009   10:03AM GMT

    Role of vendor project manager at customer site during implementation stage



    Posted by: Jaideep
    project manager, software implementation, project implementation, Project Management, project team, project lead, Risk Management, Risk Plan, implementation plan

    The vendor project manager has to work as a consultant to the customer project manager rather than taking the full command at customer site during implementation phase. From vendor side, it is the responsibility of the project manager to highlight the risks (in terms of user’s availability, user’s understanding level, or about the product usage) to his and customer management and a plan to overcome those risks. He also has to ensure that the solution provided is in line with the business needs.

    He has to make the customer management totally convinced that it is their product which they have to use in real life scenario and hence they have to be fully confident in that. The vendor management has to be with him all the time for this.


    Apr 8 2009   10:18AM GMT

    10 stages of Risk in software application development and testing



    Posted by: Jaideep
    Software application, software development, software testing, application testing, risk, risk perception, risk identification, risk assessment, Risk analysis, impact analysis, risk classification, Risk Plan, risk plan analysis, risk plan execution, risk closure

    A risk is a bigger than its size if it is not identified well in advance. An identified risk is as risky as unidentified if its assessment is not done. Risk assessment is useless if there is no impact analysis. Impact analysis has no worth if its countermeasure is not identified.

    Let us understand the different stages of risk in software application development and testing phase:

  • 1. Risk perception
    2. Risk identification
    3. Risk Assessment
    4. Risk Analysis
    5. Impact Analysis
    6. Risk Classification
    7. Risk Plan
    8. Risk Plan Analysis
    9. Risk Plan Execution
  • 10. Risk Closure


    Mar 9 2009   10:28AM GMT

    20 points for organizational self evaluation to check where it stands in Software Project Management



    Posted by: Jaideep
    1. organizational self evaluation, software project management, Project Management Methodology, project metrics, customer expectations, organizational goals, continuous improvement, software development, software testing, software bug, product release, process integration, project management evaluation checklist, customer feedback, customer request, innovation process, software implementation, project implementation, post implementation, project manager, project team, roles and responsibilities, on-site project, off-site project, project overrun, Risk analysis, Risk Plan, empowerment, Code repository, test case repository
  • 1. Does a formal Project Management Methodology exist in your organization?
    2. Are you using some metrics to check if this is the right methodology?
    3. What is the degree of improvement required in your current methodology to meet your customer expectations?
    4. What are your organization’s primary and secondary goals?
    5. Do you agree that there is always a scope for continuous improvement in everything we do – be it process, method or skills?
    6. Do you agree that a product developed without any pre-defined procedure has varying chances of success?
    7. Do you have a culture of performing development and testing as separate activities?
    8. Do you assure a bug-free product at the time of its release?
    9. Do you see all your processes integrated going hand in hand?
    10. Do you get your payments from customer in time?
    11. Do you have a process to capture customer feedback and request?
    12. Do you have an innovation process in place?
    13. Do you have a post implementation review in place?
    14. Are your project managers and their teams aware of their roles and responsibilities – on-site and off-site?
    15. Do you have project overruns often?
    16. Do you have a risk analysis and planning process in place?
    17. Are your employees delighted in doing whatever they are asked for?
    18. Do you have empowerment process in place?
    19. Are you certain about success in your projects or is it by chance/ by luck?
    20. Do you have a repository of code, test cases etc. for re-use?

  • Mar 4 2009   10:03AM GMT

    10 top “Do this if you want blunders!” in Software Development and Software Testing



    Posted by: Jaideep
    software development, software testing, Project Management, Software Project, Quality Goals, software quality, SQA, SQC, product development, project documentation, organizational goals, time to test, development plan, Project Plan, Test Plan, test case, implementation plan, project close-out, top management requirements, requirements analysis, business requirements, change management, Risk Plan, Risk Management, Software Repository, Code library, Code repository, test case repository, project standards, project methodologies, software development standards, software development methodologies, test standards

    1. Quality Goals are meant only for Quality Department: No department other than quality (project management, product development, documentation, general management etc.) has to read, understand and learn about the quality goals of the organization. It is only the responsibility of quality department and quality staff. So keep performing without ‘quality’ in it. After all the quality has to do its job.
    2. Don’t define your quality goals: If quality goals have such a low value in the organization, don’t document it. Because even if it gets documented, it will be never read or adhered to. Why waste efforts and paper.
    3. Give least time for testing: In your project development plan, keep least time between the release time and development finish time so that quality people get least time to test the product and thereby least burden to the production/development team.
    4. Have a highly versatile and flexible project plan: Build a scope of huge flexibility and versatility in your project plan/ development plan/ testing plan/ implementation plan to make it a never ending project.
    5. Don’t focus on customer top management requirements: Just focus on the user’s and department’s requirements while freezing customer requirements in requirements freezing stage. Discard top management in all briefings, findings and their requirements analysis at any stage. This may make you success in all stages except the final project close-off stage, which will never come in this scenario.
    6. Adopt no methodology: Don’t try for any world class standards or methodologies in your project management even if you have any world class projects in hand. Be assured that both situations will go hand in hand for a long run. So no need to worry.
    7. Learn the art of converting inadequate into adequate: Project in your review reports at all stages that situation is under control with an art of projecting inadequate efforts, planning etc as adequate.
    8. Never change: Have a firm belief that priorities have no meaning. Keep working on your pace as per your desire. Don’t prioritize and re-prioritize anything, ever.
    9. Risk: If your trust yourself, be firm that there is any risk to assess. There is no requirement of risk assessment and risk planning in your projects at any stage.
    10. No Repository: Who says – there has to be a library of codes and test cases for instance? Why create a repository? You have enough time to work and re-work on anything.