Quality Assurance and Project Management

Aug 28 2008   10:30AM GMT

Project Management – IV

Jaideep Khanduja Jaideep Khanduja Profile: Jaideep Khanduja

In my earlier blogs on Project Management – Project Management – I (https://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-i/), Project Management – II (https://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-ii/) and Project Management – III (https://itknowledgeexchange.techtarget.com/quality-assurance/project-management-%e2%80%93-iii/), I tried to spot on certain defects in our project management process. All these defects or shortcomings were initially not visible due to small teams, small size of projects and different management perspective. But a requirement to relook into ‘project management’ arose when management had to change their perspective due to change in customer perspective.

This asked for introspection, analysis and thought process in which we identified certain factors as stated on my earlier blog “Project Management – III”.

All these factors were causing:
Missed Schedule – Most of the projects were either getting overdelayed by dying to their natural death prior to completion or implementation.
Missed Functionality – Lack of customer requirements, lack of documentation, isolation were few of the factors that caused the build of an improper functionality or totally missing it from the product. The customer living on another island was in a different imagination world dreaming about a different functionality and product as compared to the one being built (or missed) by the development team.
Missed Budget: Obviously – any delay in schedule, or building of a functionality that was skipped during initial built will ask for a fresh expenditure. Is customer ready to pay this additional amount?
Brittle Product: The product is too fragile or brittle that it is loosely threaded in such a manner that it will lose its flow or functionality during actual usage.
Quality Aspect: The product that is seeking changes during the later stages is always prone to weak quality due to time and budget constraints and various other pressures from customer side.

One thing was clear by now that we need to change, as there is no alternative. We need to change to strive, to exist, and to deliver. We need to change to get out of our static system. We need to change to meet customer requirements. We need to TRANSFORM – OURSELVES, OUR PROCESSES, OUR THINKING.

Change – What and How – wait and hop on to my next blog in the series – “Project Management – V”

 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.

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:

Share this item with your network: