Implementing ISO 9001 - Getting whole team buy-in?

[CATERAF]

Thanks Big Jim,

That clears it up for verification and validation.
How about for approval of the project plan, requirements, design and test cases though? Are these like those of verification and validation and you can approve your own?

Thanks!

 

[Big Jim]

Thanks Big Jim,

That clears it up for verification and validation.
How about for approval of the project plan, requirements, design and test cases though? Are these like those of verification and validation and you can approve your own?

Thanks!

Your organization can choose whatever way they want to do it as long as it is effective.

 

[JaneB]

Re. Approvals in general, Can you not embed approval within the software program authority levels? Eg, more experienced programmers can approve theirs, less experienced or newbies require someone else to, until proven and upgraded authority follows. Otherwise you'll have to do it manually. Link it to competencies and HR.

 

[Golfman25]

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!

Wow. I think you are walking on thin ice here. You are trying to implement your ideas in a department which is at best skeptical of you. Their initial reaction will probably be rejection -- who does he think he is.

IMO I think you need to work with them to help them develop their own process and documentation. Don't go in with your own approach already laid out. Be a facilitator, not a dictator. Walk thru the process with them. Use a process map/flowchart. As a team, determine where documentation is needed and go from there. You know the ISO requirement. They can come up with what works for them and you can validate per the ISO requirement. Good luck.

 

[CATERAF]

Thanks for your feedback.
The procedure/list that I wrote out here is one that I have actually developed with some of the software team; it wasn't something I came up with by myself and am just dictating to them. I have gone through the process with them and we identified that at particular stages they'd need to document their requirements etc. I just wanted to check that it wasn't too cumbersome before asking the rest of the software team to jump on board... perhaps it is a bit heavy though? Or perhaps we just have to make sure the way we approach it stays light (i.e., they detail a requirements document but it may only be 4 lines long)?

Thanks for everyone's help with the approval - now that I know we don't have to have 'upper management' approval for everything that will be much easier. We're a small organisation and are a very flat 'hierarchy' so that there isn't much software management does that the others don't do. Giving them all permission to approve their own work (within reason) would make life much easier for them. I'll have to consult with them as to what documents they think should have multiple people approving and what shouldn't (gets them involved too).

Thanks for the help! I'm starting to see more clearly..

 

[misu183]

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.

From my past experiences almost everybody rely on the method of "design and self check". This way from time to time it happens that mistakes to be found after first article is inspected. Each time I bring this into discussion make the designers to claim that they don't have somebody available to check tones of documentation.
For critical industries I'm sure there are specific q standards which impose strict requirements in verifications.