Quality Assurance and Project Management

Aug 29 2008   10:30AM GMT

Project Management – V

Jaideep Khanduja Jaideep Khanduja Profile: Jaideep Khanduja

Tags:
Hardware

This is the last in my “Project Management” series. To enjoy this blog you will have to go through Project Management I (http://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-i/), Project Management II (http://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-ii/), Project Management III (http://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-iii/) and Project Management IV (http://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-iv/).

Nothing is constant in this world except “CHANGE”. One this was clear by now that we have to change – immediately and without any further delay. To enhance our Project Management Process, we had already identified our weak areas, we knew what is to be addressed, and when it had to be done also was very clear – it had to be NOW. How? We had to think and analyze ourselves.

We had to transform ourselves in following respect:
Project Requirements: Not only the customer and business requirements but all project requirements need to be specific, clear cut, vetted by customer, documented – including any communication taking place thereafter – in form of email, telephone or otherwise.
Quality: Involvement: Testing team right from the beginning of the project and make them a part of development team, let them participate in all development discussions. Let them be very clear to identify the risks involved if the product is developed as per the project specifications and design finalized. Testing team has to be an integral part of the project now onwards, testing not at the final stage, but at each and every stage of development, by clearly identifying the scope of testing (unit, module, product, functional etc.) and highlighting the defect or bug at the moment it is encountered without waiting for submission of a test report (which in any case will happen but not after each defect identification!).
Sizing and Right Candidature: Go for the right size and right people while building a team for a project.
Backlog: Be clear about the requirements still pending to be catered to, built into the product. Count it as backlog, cut backlog into smaller pieces, and assign each element of backlog to a team member with the time plan (hours or max day).
Monitor: Regular monitoring of this backlog planned versus the completed is required atleast once a day. Involve only the concerned in the backlog as with the backlog resizing, the team also have been divided into smaller parts.
Involve Customer: Keep customer updated on each and every backlog completed. Let the customer, if they wish, to run through the backlog completed. Let the customer, if they wish, to check the balance backlog.
Release the Product: Release the product as per your commitment date. Any pending jobs (if at all!) may become the part of next release after their completion.

Hope you enjoyed the series.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: