Comparing ISO with PMBOK (Project Management Body of Knowledge)

[sathulan]

Comparing ISO with PMBOK

Hi all:

I have 2 questions and since I am from the software domain, I would like to restrict the focus of these questions/responses to software development.

1) PMBOK (Project Management Body of Knowledge, www.pmi.org) describes quality control and scope verification as-

Quality control: analysis of the correctness of work

Scope verification: is concerned with customer acceptance of the project efforts

Would it be correct to say that verification as defined in the ISO9000:2000 is what the PMBOK describes as Quality control above and similarly, is "Validation" as defined in the ISO vocabulary what is referred to as "Scope verification" by the PMBOK above?

2) A question on risk management: should constantly changing scope of work (due to changes in requirements by the customer) be treated as a risk?

As I understand, risk is something with an element of uncertainity about it. When it is known that a particular customer *will* change requirements frequently, is that to be treated as a risk - since there is no uncertainity here.

Would appreciate inputs from the experts out there.

Thanks
Athulan

 

[James Gutherson]

Re: Comparing ISO with PMBOK

sathulan said:


Would it be correct to say that verification as defined in the ISO9000:2000 is what the PMBOK describes as Quality control above and similarly, is "Validation" as defined in the ISO vocabulary what is referred to as "Scope verification" by the PMBOK above?

I think (IMO) that interpretation of verification is reasonable. It of course depends on your particular circumstances.

One part of validation is scope verification, but there might be others required.
ISO 9004: 7.1.2.3 gives insight into Validation; 'Validation of products demonstrates that they meet the needs and expectations of customers and interested parties. Validation activities include modelling, simulation, trials...'

I think that is a software design environment that phototyping, alpha and beta testing and other types of trials are all parts of Validation, making sure that the product meets the needs of the customer.

In terms of risk, every activity has risks attached to it. Risk is a measure of likelihood that something will happen, and the consequence of that thing happening. Some thing might be catastrophic, but only occur every few millions years (comet killing the dinosaurs) so the consequence is high but the likelihood is low, Where as something might happen all the time, but have little negative consequence (bee stings). Risk management is determining all the things that might happen, working out where they fit in terms of Likelihood and Consequence and then deciding which ones require action and which don’t. We would all go broke if we tried to account for meteors, and depending on your situation I doubt it would be worth fitting everyone in bee suits, unless you are on a honey farm. It is the ones in between that require the thought.

In terms of knowing a customer ‘will’ make changes, the likelihood is high (very high), but the risk will depend on what the consequences of the changes are. In a software situation that will depend on a number of things that only you can answer, but one might be when the changes occur, at project definition the consequence is quite low, but towards the end of the development, when code is nearly gold, the consequence might be high. And it depends on what the change is, a few changes to a help file will not be a large consequence, but a new feature might be huge.

I hope this helps a bit.

 

[Marc]

I looked at project management back in 1998 and the PMI. I got information on it and felt it is good stuff. But I have no direct experience in software development to be able to add anything else.

Do we have any software people here? If so, any comments?