August 23, 2006

SQA: People Person

Let us have a look at the primary duties of an SQA.

The audits, the review meetings and the escalations to resolve any quality issues in a timely manner.

In brief, an SQA has to get things done, in time, from people with whom he does not have a reporting relationship. He has to ensure that the process violations are minimal even when he is not in charge of the projects.

Talk about project teams and you know you are talking about people who have less and less time, who have lots of deliverables to work on, who have deadlines and who keep this evergreen statement in mind, "Customer wanted it yesterday!!!".

SQA often gets to work with such teams and its these teams who have to ensure that the project has no non compliances and liaisons with PMs/PLs or TLs.

If one is not careful, tactful and sensitive about handling 'stressed' people, the resulting chaos may not be suitable for the project's objectives. SQA can easily be blasted, can get a sly reply, a ridiculing laughter or a blunt answer indicating a clear refusal.

It may be argued that, if a project team does not see any value in a process, it should be presented that way or a deviation could be sought. The argument is good, not practical, however. There are many factors that drive process/product compliance or non-compliances like deadlines, pressures, attitude, skills levels etc.

Moreover, many times, it becomes imperative for the project teams to keep up with the pressures from various quarters and thus they tend to ignore the compliance issues unless they have been directed by the senior management or the customers.

Therefore, it's highly recommended that SQA should empathise with the project teams, strive to understand their work and working environments and build better relationships in order to enthuse a confidence in the project teams about software quality processes.

Its not possible to do it without being a people person. Isn't it?

No comments: