Apr 17 2009 10:03AM GMT
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 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.
Mar 4 2009 10:03AM GMT
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.
