Productivity & Quality...

[A0C61ZZ]

I manage a s/w engagement project for a reputed client in the financial services industry. My team mostly consists of members from my consulting company.
The productivity and quality definitions and perceptions vary greatly between my client and parent company.
As far as processes and project maturity is concerned my client is at level 1 (don't have much of these).

My client mgr. expects 0 defects/ high-quality without paying for it. I tried reasoning about industry-wide benchmarks but he dismissed it as consultant-babble...

Nevertheless he's great to work with...especially since he's got fire in his belly - so to speak and has a good drive in getting thinks done. On the other hand my team definitely not slackers do not share his enthusiasm as such.
This raises the 2nd question of productivity. Their productivity is definitely above standards but cannot match his.

Can anybody share light on these 2 aspects of productivity and Quality? Right now I'm doing this balancing act, nevertheless a new/fresh perspective on this would definitely help me.
Cheers...

 

[clivehenderson]

you sound as though you are on a sticky wicket here.
1. You need to have the acceptance criteria written down at the outset. The notion of zero defects is not feasible.
Consider categorising defects into severity level impacts e.g 1 to 5 with 1 being system malfunction down to 5 being cosmetic errors
Then talk of acceptance with zero severity level 1 defects makes sense.
Non-acceptance by the client = project failure
2 Quality is only one aspect of your dilemma. Your team needs to buy into the schedule(You have!! prsesumably it is baselined)so the deadlines are yours (hence theirs) and will impact development costs and business case assumptions. (Time cost, quality et al)
I would suggest this should be raised as a project issue and managed as such).
Hope this helps
Regards
Clive Henderson
Sandlegold Ltd
Project Management Consultants

 

[LNBruno]

Or, as my mentor was fond of saying in regards to software development:

Cheap, fast, and good. Pick any two.

< M!ke >
[small]First Rule of Holes: When you're in one, stop digging.[/small]

 

[prjman]

I like LNBruno's comment on this a lot. Personally I go with production and then quality. Of course, a reasonable amount of quality should be there at any time, but trying to perfect things at the start of a project, especially in the dynamic world of IT Projects (where a product tends to take shape as the project goes on), can do more harm than good. Feedback from the client is always the key (I think I'm describing Agile over here).

http://www.pmhut.com/

- The Project Management Hut

 

[supermenon]

I have to disagree with the comments posted on this topic. When it comes to delivering a project my prime focus is on "Quality" more than anything else.

For example: If my financial application project is deliver a product with 5 features and my team's productivity is low but quality is high...I would rather deliver 1 superior working feature that 5 partially working features.

However in a ideal world...I would like to have a decent balance between Quality and Productivity.

"Ideal World" is a dream...and they rarely come true...

 

[A0C61ZZ]

I agree with clivehenderson,prjman & LNBruno on this. The constraints here are too involved and impede quality.
First of all the users need this as soon as they demand this - the risk to business is always high if this is NOT done on time.
Secondly we cater to multiple user teams each catering to one phase of the product's lifecycle. Thus changes to one user group's process step on another's. This means we need to handle the design part well.
Thirdly we have a highly fragmented system evolved though years and we have technologies from Java to COBOL.
Lastly the team size is less, don't have as much business knowledge as needed.
Asking for zero-defect quality I feel would be outlandish in this scenario. I had this hunch that my client mgr is not aware of the industry standards on quality and is asking for these. Just wanted to confirm my observation with you guys.
Thanks again...

 

[IonelBurtan]

My oppinion about this is a little different.

Quality is esential for multiple reasons:
- the impression on the client when he gets a delivery
- the easiness to add enw features and to debug problems when they appear in a high-quality product
- the re-use concept of a well written component
and so-on and so forth.

Key is do not make quality JUST BECAUSE THE CLIENT EXPECTS IT. Even better, you should aim a higher than client expectations when setting quality levels.

Now about clients that expects 0 defects - this is pure politcs to convince him of nonsense. If he still resist, then go with cost-related elements (for example introduce "stablilzation" periods of 2-3 weeks before each delivery - to enhance quality). If he'll hear he needs to pay for that, he may change his mind.

The real problem with these guys is in fix-price projects. Here, you need to prepare a lot of time for quality from the begining of the project. And your experience MUST kick in here. (if you do not have it, better ask around before commiting to an insufficient plan).

Anyway, no silver bullet on the matter,
Yet...


s-)

Blessed is he who in the name of justice and goodwill, sheperds the weak through the valley of darkness...

http://www20.brinkster.com/ionelb

 

[prjman]

The client is only able to judge what he sees. In most IT projects, what the client sees is an interface in action. Bugs would still exist here & there, but once you have a functioning system in place, you can fix your bugs. A client that believing that an IT project can be released as 100% unfaulty is an uneducated client, and the PM should explain this at length to the client, only when the latter discovers a bug after release(it'll just be creating monsters if you do this prior to/during development).

Additionally, you might have sometimes an in-house quality coding standards that you really would like to implement, that you feel obliged to drop in order to finish the project on time. The client really doesn't care how your code is written. You might actually want to revise the code at a later stage as part of the maintenance phase.

I think everyone agrees with IonelBurtan but many times it just ain't feasible.

http://www.pmhut.com/

- The Project Management Hut