Do you ever hit a brick wall?

Have you ever experienced a project where you simply hit a brick wall with the product owners / customers? Where what they are asking for is obviously going to cause usability problems, is going to introduce so many potential 'sketchy' user scenarios or is simply going to cause a huge amount of code debt, that even a tester can see it already?

Anyone experienced this?
If so, what did you do and how did you do it?
How did you convince them not to implement the feature?
What happened if they did implement - did it backfire later?

Rob

▶ Reply to This

Replies to This Discussion

Permalink Reply by phil kirkham on April 16, 2009 at 2:03pm: What do you see your role as - The Guardian of Quality that wont let a hacked together piece of code go out of the door with your name on it ? What is their response to the problems you raise - do they have a valid business case for ignoring you ? Is it important for them to get something out of the door no matter what shape it's in ?
whats their history - do they always do this ?
what was your brief - what were you brought in there to do ?; ▶ Reply to This

Permalink Reply by Rob Lambert on April 16, 2009 at 2:33pm: hmm,

Let's see
What do you see your role as - The Guardian of Quality that wont let a hacked together piece of code go out of the door with your name on it ?
Not really, but at the same time I can see the support calls coming back in. I can see the users making mistakes. I can see the users getting confused and the app very much needs to be simple to use.

What is their response to the problems you raise - do they have a valid business case for ignoring you ?
Lets continue for now and see where it goes. Let's have a meeting in a few weeks.

Is it important for them to get something out of the door no matter what shape it's in ?
It is, but is also HAS to work and HAS to be usable.

whats their history - do they always do this ?
Only recently.

what was your brief - what were you brought in there to do ?
Improve quality. Through the whole cycle. It's also my baby really. In terms of the work I enjoy and am quite proud of.

I have a way I'm gonna deal with it and I know answers to these issues are often very specific to the company and the people. Just wondered what other people have done in this situation.

Rob..; ▶ Reply to This

Permalink Reply by Michael Bolton on April 16, 2009 at 2:36pm: Anyone experienced this?

Yes.

If so, what did you do and how did you do it?

I reported it, and let management make the decision.

How did you convince them not to implement the feature?

In one case (I was a program manager, rather than a tester, so I had extra authority that a tester might not expect to have), I managed to convince the product manager (who was the product owner) that a claim on the box (when compared with the company's ability to fulfill that claim) was tantamount to lying, and that a sale based on that claim would be tantamount to stealing. In that case, I was desperate to avoid a case of consumer fraud.

What happened if they did implement - did it backfire later?

In cases where they did implement, sometimes it backfired, and sometimes it didn't. When it did, people learned. Sometimes we dodged a bullet, in which case people didn't learn.

---Michael B.; ▶ Reply to This

Permalink Reply by Rob Lambert on April 16, 2009 at 2:42pm: Michael,

Yep, I think this is going to be the case. I think there could be lessons learnt for the team. the reporting to management is definately the way to go. All I can do is highlight - let someone who can make the decision - make the decision.

Cheers
Rob..; ▶ Reply to This

Permalink Reply by Joel Montvelisky on April 16, 2009 at 3:06pm: Yes & No.

Yes, you need to report to management, but No sometimes I feel we need to take a more active role as Project Stakeholder.

For me, QA/Test Manager is as much a manager as the Dev Manager, Support Manager, Sales Manager, etc. I believe that part of our role and responsibility is to shed light on the rest of the team and bring to their attention the future repercussions of a mistake.

Not in all companies and cultures it is possible, but I find it that in many places we stop our job at reporting to the project or product manager and not to the complete group of project stakeholders... I've found that when I make sure all the rest of the manager understand how they are going to "pay" in the future for the mistakes being done today it helps to apply pressure on the people making the product decisions.

At times I've being called an anarchist, but after a while people started listening to my warnings.
You might want to think about that course, specially if it is baby...

My 2 cents.; ▶ Reply to This

Permalink Reply by Michael Bolton on April 17, 2009 at 7:12pm: Note that I reported to the entire project community (as represented at a pretty well-attended meeting), but let management make the decision.

---Michael B.; ▶ Reply to This

Permalink Reply by Rob Lambert on April 17, 2009 at 7:37pm: I've done just this. Made sure the right audience was there in the meeting and laid it on the table. The future ideas. The problems the user will face. The way we can do things differently and I'm leaving it to the stakeholders to decide.

That is all I can do and if nothing changes then nothing changes. I accept it, move on and get it tested.

Thanks all.

Rob..; ▶ Reply to This