Is Project Management Quality Just A Belief?
Is quality just a belief? While this notion has merit, I think it can easily lead us down the wrong path. In the article Quality Needs Data Not Beliefs I highlighted an example of a quality assurance (QA) organization that had difficult detecting quality in a project that eventually was recognized for achieving new levels of quality.
In this case one QA “belief” was that defects were being overlooked and mis-prioritized. As it turned out, the belief was unsupported by any hard evidence (or root cause analysis) and so not surprisingly the QA remedies did nothing but increase the number of meetings and additionally generated tension between QA and product management.
This project, which took a data driven approach to planning, ended up exceeding most of our quality criteria and was lauded by one of our biggest customers for its quality. It also spawned a whole product line noted for its on time delivery and quality.
What was most telling was that while this break-through project was ongoing, QA could not detect that quality was improving (or was even different from previous projects). In my observation (I managed this project) this was due in large part to QA being based more on a “collection of beliefs” about quality than it was on hard data driven indicators.
Both product/project management and QA were not functioning well in this organization. So it was not too much of a surprise that when one part of the organization improved itself, it uncovered problems in other parts of the organization.
We often apply QA as the change agent to improve our organization. What is sobering about this is that QA is probably just as hard to do well as is the activity that QA is supporting. So if we can’t manage the primary development activity well enough to produce quality, it is unlikely that we’ll be able to mange QA so well as to in-turn induce quality in the development organization.
One thought on “Is Project Management Quality Just A Belief?”
Comments are closed.
•Quality does not come into picture in the end of the project during scope verification and acceptance it should be all the way during the project initial phase till the closure phase.I believe Quality should be built in rather than planned
•Quality starts from evaluating a vendors product thoroughly, why do the business require new product, if business say to be competitive in the market then it should clearly be evaluated what percentage of the business would be improved on the new propsal, so that clearly we could estimate the ROI (return on investment) on the new product, if there is no significant percentage of improvement then maybe we could go for enhancements to the existing one this will not burden the overheads of the business may be you could add new personnel to improve the business through different channels at identified market segments, at this stage list all the pros and cons and submit to the management for decision making.
•Further if it’s a new project or enhancing the existing with interfaces with other software’s we need to know the how much load would be on the server in terms of users, bandwidth, network , system capacity, its speed, tools, expertise etc an do we have such infrastructure/environment build or do we have to enhance the environment. All the above would add up to the project cost along with licensing.
•However if business has a nod to go head and SOW/Project charter is prepared with all the project objective, deliverables, end user requirements, role player mapping, high-level strategic planning, goals, budgeting(resource requirements, cost estimation), risk assessment (matrix), supporting quality assurance which includes which testing tools would be adopted, checklists, issue-logs and which quality methodology would be selected say Six sigma/ CMM-I level-5 where level 3 and 4 talks about coporate documentation and reserve the data for future reference, work done is measured in quality and quantitative metrics and level-5 talks about optimization of defects, eventualy at this stage the contract statement should be flexible, negotiable on price say a function of the product may have two to three major changes, five to ten minor changes and if changes exceeds then the sponsor has to pay a percentage of amount estimated on the changes in advance and the rest after acceptance otherwise it would be an open end and the sponsor will keep on changing the requirements and the project could not be delivered as per the constraints Scope/time/cost/quality (of course no gold plating), to support this a change management board to be identified and they should be held responsible for any changes. The agreement should also focus on the SLA’s and who would be responsible to prioritize the issues and the hierarchy to whom the issues are to be escalated if the concerned is not responding in time and plan for how conflicts could be resolved.
•Have PMO set up who will guide the project and integrate all the business requirements from the business analysts, follow up with the concerned and come up with standard methods, tools, templates and procedures to drive the project to it success according to the project plan.
•The quality of the project would also depend on the resources selected, however customer would select the vendor resources by form of interview, similarly Vendor also needs to interview the stakeholders how do they understand the product with some case studies and place them rightly in the functional area where they fit in comfortably.
•Project lead/team could make use of a software design document (SDD) which will have the high level system architecture, system flows, work flows, data flows, high level design information, look and feel of front end screens, Low level design, look and feel of reports if any for each function, so that the programmers could code easily picking up the SDD and this document would be tracked based on the functionality changes of the project so that the prior changes and versions could be referred back easily where and when required, prior to this any changes in the functional design unit test cases has to be prepared and approved from both the parties by doing so that the stake holders would be better be informed whats going on may be some times they would not understand what the design talks about may be a prototype of the requirement may help stake holders to get them back on the right track and on the same page.
•Get the work done audited by cross functional experts, external expertise and quality gurus and then get the scope verification done by the stakeholders get it duly signed by all stakeholders and sponsor and then you could be ready for go live and deploy when all the vendors payments are released as agreed in the contract.
•Allways plan for the activities with lead and lags between activities to have cost and schedule reserves since project is always an improvement to the existing we may not know at the initial stage the insight requirements and it may vary accordingly as we move forward, motivate and integrate the team, track for schedules and costs at milestones/benchmarks, Microsoft project management tool could be one of the tools which could keep the project on right track generating different tabular information along with reports and graphs.
•Track for the defect density and draw control charts at all phases of the project cycle this will help the project to strengthen at the weak phases identified and keep the project on right track with high quality derivables.
The above all activities of a project life cycle could be compared with making a quality dish, the quality dish has a lots of planning what are the quality brand ingredients required how much are they required , how many people would the dish be served, what are tools, facilities,resources and equipments required, who are going to be involved, what are the steps to be executed, what would be the estimated time frame to be completed, cost estimate, the chef should know what would should be the outcome and how would he present the dish and what is the taste/flavour in the customers/sponsors mind who would be the accepting the end result. So in the project life cycle there should be someone like master chef owning the project may be a delivery manager who knows the flavours of the project and could deploy the project deliverables in high quality as per sponsor’s requirements.
However the outcome should be a tasty dish otherwise game finish.