Implementing ISO 9001 - Getting whole team buy-in?

[JaneB]

Yes, if they're not doing anything at the moment, other than the fun-type coding/playing around with software, it'll all be an imposition to some. That's a very low base!
Some of the big losses from (preventable) mistakes might be useful.
No testing, no project management, no requirements, no formal design documents.. :mg:
Yikes. Words (almost) fail me. Are they self-taught, or did they actually do any formal training? Any model you want to look at in the IT world requires these things!! And for good reason.

Virtually no IT people I've ever met want to 'do the doco' - most would rather staff the help desk instead (and as they loathe that too, it gives you am indication of their dislike). But ultimately... Tough. Because it's an essential part of work that's done properly (vs the cowboys - never mind the specs, let's just get to work don it).
Can you find some analogies from other fields to indicate this in a moderately light hearted way but with serious undertone? I might use something along the lines of oh, never mind the drawings, let's just start building the house. And... We don't need building inspections, WE know what were doing (cue picture of house debacle). We don't need no standards around here... The net is rife with some glorious pictures of how well these approaches (didn't) work

You're also going to need management emphasising that things done change around here as well - carrot and stick.

 

[JaneB]

PS - I'd settle for a majority 'buying in' - heck, even just a few at the outset. Whole team may not happen. But as things improve ( and they will) the benefits will start to become self evident and generate its own momentum.

 

[Big Jim]

There are so many it's hard to know which to address but I think the bottom-line is financial cost (too much documentation means time spent writing, not producing products which we need). Unfortunately it's hard to quantify their current costs because very little is recorded. I've started doing some digging to see if I can calculate some costs and try to compare it to the costs of putting a preventive measure in place. Unfortunately the two examples I have so far end up costing more to prevent than to fix.. Am going to dig deeper into some of the big financial losses that occurred due to mistakes.

I am a fan of the thread that somashekar linked me to which gives the idea of presenting to them the benefits of improvement. I've done some reading and identified many costs which may not seem apparent and am thinking of showing them these and doing a company-wide presentation.
Has this been a good technique for others?

As for whether our current procedures are cumbersome -- yese, they are cumbersome compared to what they currently do because they don't do much at all (no testing, no project management, no requirements, no formal design documents.. ). I think any kind of documentation is impinging on their 'product-generating' time. I'm finding it hard to gauge if it's too much documentation because it all seems to be too much to them. Fortunately we do have some members who have done ISO before and one in particular would be in a good position to tell me if he thinks it's too overboard (he's hardware though and it's software we're working with first).

I think their concern is that they have to generate documents -- but probably don't realise that I'm the one documenting the process, generating templates for them so there is less to do etc. Perhaps it's worth plugging this point?


Thanks for all the comments - very very helpful!

Unless you have an overly burdensom documentation set of requirements, what little really has to be recorded becomes routine very quickly. Perhaps I should also say it will remain awkward as long as they want it to be.

Often, one of the hardest groups (and sometimes one of the easyest groups) to get in line with documentation is the engineering group. When setting up a quality management system where engineering is disorganized, I find it helpful to bring all the engineers and their managers together and carefully explain the record keeping requirements in 7.3 (5 of the 7 elements of design require records, and for the two that don't, you probably do keep records). Then start asking for their input to determine the easyest and most effective way to keep records for each topic. Only once have I had a problem coming up with a very effective design checklist template. That once was in a one engineer company who claimed that all his designs were perfect and never required any revisions.

The engineering team is much more willing to be helpful in this exercise if top management is present at the start of the discussion.

I'm not sitting in your seat so I'm sure that there is much more to your story than what we see so far, so use this example as you see fit.

Remember though that the best defense is a good offence. Go in with a positive attitude about what can be accomplished and show strength in your position.

Best of luck.

 

[JaneB]

Agree with you about it 'remaining awkward as long as they want it to be', Jim, but I'd take a different tack re. the records.
The problem with explaining the 9001 requirements for keeping records is that it only has a positive effect if people want 9001 or think it's a good thing. If they don't, why do they or should they be in the slightest bit interested? Any anyway 'because it's in 9001' isn't a compelling argument for the average IT person.
I'd always focus on the more compelling reasons such as requirements being needed because not having them causes problems later/poor code/pushback from users etc. And testing being needed to prevent defective software being released, with consequences including lots of rework and recoding etc. And if you have no records of what testing was done previously, how can you analyse the weakness of prior testing and improve it?

Of course, we know that those kind of negative outcomes are precisely why such requirements are in 9001, but just using that as a good reason to do it isn't ever as effective as speaking directly in their language to the jobs and activities that they do.

 

[Big Jim]

Agree with you about it 'remaining awkward as long as they want it to be', Jim, but I'd take a different tack re. the records.
The problem with explaining the 9001 requirements for keeping records is that it only has a positive effect if people want 9001 or think it's a good thing. If they don't, why do they or should they be in the slightest bit interested? Any anyway 'because it's in 9001' isn't a compelling argument for the average IT person.
I'd always focus on the more compelling reasons such as requirements being needed because not having them causes problems later/poor code/pushback from users etc. And testing being needed to prevent defective software being released, with consequences including lots of rework and recoding etc. And if you have no records of what testing was done previously, how can you analyse the weakness of prior testing and improve it?

Of course, we know that those kind of negative outcomes are precisely why such requirements are in 9001, but just using that as a good reason to do it isn't ever as effective as speaking directly in their language to the jobs and activities that they do.

Good point Jane.

Another viable approach.

 

[Mallya]

I understand it is very frustrating but make sure the management supports you inside out not GM, cause GM support is not enough make sure every member of management is committed to QMS because they are same guys who rule those departments.

Regards

 

[misu183]

When you communicate with them don't start to make an university lecture.
They will hate this.
I would say this must be taken more as a friendly conversation based on some practical examples.
When a quality problem occurs there is an opportunity to show an example as an alternative in the way of work in order to avoid the same mistake.
After several discussions you will be pleasantly surprised to see that based on examples discussed they will get more involved and some of them will bring ideas for improvements in the work system taking in account internal/external non-conformity experienced in the past.
"Tenacity and patience" are the key words.
Good luck!

 

[CATERAF]

Thank you all so much for your feedback! I'm learning a lot from it and there are so many excellent points.

I agree that the engineering seems to be tricky.. and that's what we're all about (still, a good challenge for me!).

I think a wealth of 'patience' may be key.. and also spending time getting them to help me develop the documentation. I think though I need to get help from those with resistance because the others would help me develop it in a flash but then it still wouldn't be adopted by the others. Perhaps the idea of having a few meetings with them would be useful. I also really like the idea of very basic world examples such as planning before building a house (will come up with some of them!). I also think delving into some of their most 'costly' experiences could be useful... but is difficult to get 'facts' as it's all self-report.

What's surprising to me is that, despite their lack of requirements, design and testing they still have customers who really value their products and keep coming back. Not only that but we're winning big contracts. This is probably not helping the cause 'cos they think what they're doing is working. This probably explains why they think the young engineers are just 'document-minded' because they're fresh out of uni and uni isn't practical in the real world.

Just to check that I'm on the right track documentation-wise (because what's the point of convincing them if we're on the wrong track anyway)..
my plan is for the engineers to develop their project plan (incl. a set of requirements) and then to develop more detailed requirements documents for each 'task' they have. They then generate their design and test cases which must 'map' to the requirements (i.e., inputs match outputs). I've said this is reiterative in the sense that they may not know all their requirements/design so they write out what they can, design what they can, have a go coding and see what happens then go back and change the requirements/design as appropriate. That said, the requirements and design need approval before commencing and as changes are made (with these changes tracked). They need to verify each time they code (unit tests - when they're ready for it) and their own policy is to never check in broken code (i.e., it passes their unit tests). There is then verification with automatic builds and then partial validation periodically (maybe once per week) to check they're on track. When ready for release they have to pass the verification (Automatic builds) and then full validation (cos we don't have time for this with every weekly build). Amongst this they have weekly meetings where they assign tickets (their 'tasks' for the week - also documented in their ticketing system with responsibilities, requirements etc) and they'll have to have a review at appropriate points (to check the rqmts/design/tests are on track?).

So the records/docs are the plan, requirements, design docs, test cases, approval and tracked changes for each of these and records of the weekly meetings/reviews and all tests conducted. It's probably useful to have a checklist/template for the plan, requirements, design and meetings so it's easy for them to just check them off and make sure they've not missed anything.

Does that sound too cumbersome? We are getting a software program allows them to enter each requirement, and their test cases and assigned tasks map to each requirement as they enter them in the software. The design will either be done in an individual document (attached to the software) or be broken down and slotted in with the requirements. Test cases are already mapped to each requirement as they're entered and you can single-source some test case steps so they don't have to be written out multiple times. The software keeps records of tests (and results) conducted, and tracks all changes for them. I was thinking approval would have to be manually done but could we just have a meeting that checks requirements and says it's approved? (Rather than having to 'approve' every individual requirement). This program also provides reports on progress and what's been tested.

Sorry if this is not the place to be asking -- it's a flow-on from my thread but a slightly different question.

Thanks so much for your help!

 

[CATERAF]

.. oh, and one more thing sorry! In response to me saying that one area of improvement is to have documents being 'approved' one of the engineers said 'why can't we just approve our own requirements, design and code?' To me I know that they need someone else to be approving it because their second pair of eyes is what prevents mistakes but this didn't seem to be enough and I have a 'blank-mind' moment and didn't know what to say! Any ideas?

Thanks again!

 

[Big Jim]

.. oh, and one more thing sorry! In response to me saying that one area of improvement is to have documents being 'approved' one of the engineers said 'why can't we just approve our own requirements, design and code?' To me I know that they need someone else to be approving it because their second pair of eyes is what prevents mistakes but this didn't seem to be enough and I have a 'blank-mind' moment and didn't know what to say! Any ideas?

Thanks again!

Two of the seven portions of design are verification and validation. They are forms of review.

The standard is silent as to if a designer could do his own verification and validation. Before going further, definitions are in order.

Verification - confirming that the design went according to your plan.

Validation - confirming that the product is suitable for its intended use.

I often see that the design team or designer does their own verification. I also often see that validation is done by someone else, usually a peer.

In a way that makes sense, as it is no different than proud parents not believing their children can do any wrong. Designers often also cannot see any flaws in their own design.

Again, though, the standard is silent on this matter. It is up to the organization to come up with an effective way to handle this.