Quality is one of those terms we love and hate. We know we need it, and most of us prefer to work on projects that have “quality” in some form, but we’d be hard-pressed to provide an accurate definition in a sentence or two that provides us with a measuring stick to tell us if we’ve nailed it.
And to make matters worse, we often come into our responsibilities with our own preconceived notions of what quality means for our role, our deliverable, or our team. As I talked about in “Fix yourself before you fix the process”, we often hold ourselves accountable for a certain quality of work which may or not even fit (read: deliver value) within the organization we’re working.
At a SQuAD meeting awhile back, Richard Lawrence of Humanizing Work put forward what I found to be an insightful definition of quality that could help us think our way through some of these messes we find ourselves in:
Quality is the ability to deliver value now and in the future. [Laura's note 7/22/2009: Richard was misquoted, this should read "The goal of a software organization is to produce valuable software now and in the future”.]
The interesting part of this concept is “now and in the future”. We all probably think we know enough about value. Saying quality creates values does not drive us to think about things differently. But creating that value not only “now” but also “in the future”…maybe this is part of the key to unlocking the mystery of quality or at least understanding how two purely rationale people can have such opposing views on what makes a quality system in any given situation.
At any given cross-roads where we find ourselves making a decision about quality, can we look at the impact now and in the future? Can we evaluate the trade-off between the timely delivery of value and the ability to continue to deliver value (i.e. is it maintainable and extensible?)? If we side-step that bug fix or kludge together an implementation of that business rule we might deliver value now, but at what expense? Will a timely delivery simply stop our ability to continue to deliver in it’s tracks as we focus on cleaning up our own mess?
(Of course, this definition assumes we know what will create value for our organizations in the first place. Figuring out that problem is a separate topic entirely.)
Viewed from this perspective, quality becomes the foundation of speed and value and it literally becomes nonsense to sacrifice quality to deliver value now. It becomes equally nonsense to optimize quality and never deliver value.
With these thoughts swirling in my head Martin Shoemaker and I had an interesting Twitter conversation one morning soon after Lawrence’s presentation (my apologies, this post has been sitting in my drafts folder for a long, long time). I’ll recapture the salient points here:
UMLGuy “People under time pressure don’t THINK faster.” – Tim Lister. He’s an optimist. People under time pressure think SLOWER.
ClearSpringBA @UMLGuy but can people under pressure do “good enough” thinking and create value faster? I’ve seen it happen.
UMLGuy @ClearSpringBA McConnell cites research on the compressibility of schedules. 15% is possible. Short sprints work, if not overused.
ClearSpringBA @UMLGuy makes sense, but that seems to speak to delivery, not thinking.
UMLGuy @ClearSpringBA But too much pressure, and the team thinks about the pressure, not the problem.
UMLGuy @ClearSpringBA I think a little pressure energizes, motivates, and focuses.
ClearSpringBA @UMLGuy no doubt, pressure vs. good thinking is a balancing act. good leaders drive good, timely decisions. bad leaders just drive.
Pressure. Time-constraints. Good decisions. Focus. QUALITY. LEADERSHIP.
Delivering software or solving business problems is all about balance. There are leaders who drive quality with just the right amount of pressure to encourage proper focus. There are leaders who sacrifice quality through a pressure for short-term delivery and impede our ability to deliver value in the future.
As conscientious professionals, it’s important to recognize the definition of quality we are assuming at any point in time. It’s very unlikely that everyone we are working with shares our definition. As a result, if we pressure ourselves to deliver according to our own standard we might actually miss the mark from the perspective of our stakeholders. Likewise, if we perceive pressure to deliver something impossible, it may be that there are different notions of quality at stake.
Considering these factors as related to quality, the when of delivery, the what of value, can help us bring into light our own perspective as well as those of individuals on our teams and the stakeholders we our so passionate about delivering value and quality for in the first place.
|
By Laura Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura Brandenburg |
Related posts:
Loading ...
{ 14 comments… read them below or add one }
Nice article. I just emailed about it on the agile-quality mailing list, and will refer to it again in the future.
Thanks, Kurt. I am glad you found it useful!
Old saw: Schedule, Quality, Cost — you can only pick 2.
The trouble with ‘quality’ is that is isn’t a thing, even though it is often used as a noun. ‘Quality’ is an attribute (it’s very tempting to say “a quality”) of something. ‘Value’ is the same sort of term and encounters the same sort of difficulties.
I’m not sure they equate (“quality is …”) even though they relate across the delivery boundary. The customer centered notion of ‘use value’ suggests that value has to do with the degree of fit a product or service has with customer need. Quality, I think, has something to do with the product or service itself and derives from a supplier perspective of applying best practices during production. It is quite possible that a ‘low quality’ product has the highest value. The notion, originating with Microsoft, of “good enough” is an example.
Separating quality and value in this way, the tension is another job for the BA as they liaise between stakeholders. Quality measures applied to techniques for life critical systems don’t apply to time critical production of a custom reports. Identifying and recommending result requirements that lead to appropriate production techniques will lead to a good match between quality and value. So a measure of BA quality is the lack of tension between quality and value.
Just a thought.
Hi Nathan,
As always, your comments get me thinking beyond where I was before. I see the point about quality being an aspect and not a thing in and of itself. I suppose we could also look at “time to market” as an aspect and then consider quality and time to market competing aspects of delivery. And we might re-coin the definition to read, “you achieve quality delivery if you can deliver value now and in the future.” Not sure, what do you think?
I think having BAs focus on this tension (or someone focus on it) is valuable. Too often we focus on the short-term value created by a system and not the long-term value of it. These typically come out in our non-functional requirements, but I’ve found it really hard to get business stakeholders to talk about non-functional requirements directly. And when I do they end up asking for metrics that become impossible to implement given project constraints and get thrown out to achieve a timely delivery anyway. Maybe the value over time concept could be a useful concept to guide this conversation and get further into the core of how the business sees the opportunities of the system.
There is quality, and there are qualities. They may overlap.
Software Quality already has a pretty good definition in the ISO 9126 software quality model.
Qualities, as in desirable attributes specified by the customer to define specific service levels or other non functional requirements are what Nathan seems to talking about. Tom Gilb’s Evo methodology has been based on such attribute driven development for a while now. Ryan Shriver has also written a lot about how it works in practice.
Kurt,
Agree with your points. The actual etymology of quality is from the latin qualis ‘of what kind’. The relevant definitions are “peculiar and essential character” and “degree of excellence” (MW). The first captures, I think, the “other non functional req.” notion when viewed from the customer value perspective.
Laura,
Thanks for the mention. Just to be clear, though, I said, “The goal of a software organization is to produce valuable software now and in the future” and that quality is the foundation of value and speed rather than in tension with them. I was definitely not defining quality directly. That’s difficult, if not impossible, to do in a useful way, as some of the previous comments have suggested. Rather, I argued that it’s useful to think about the connection between quality and value–low quality is revealed by reductions or gaps in the flow of value. Instead of talking about quality, let’s talk about how a particular practice or test or meeting helps us deliver value now and in the future. Quality is too abstract to talk about directly.
Richard
In using R Lawrence’s definition of quality as the foundation of value and speed, it got me thinking about if IT and Business have digressed apart in their view of what quality really is.
Quality for my IT group is all about reduction of defects, blah blah blah. The standard stuff that most IT groups have focused on for getting their heads around whether their products work well. I’m not saying that it’s bad thing to focus on, but I wonder if we’ve gotten so mired in watching the number rise and fall on charts that we forget that there are other aspects to quality.
For instance, consider these scenarios:
If a group delivers a partially faulty product to market faster, and includes functionality (that works) that allows a customer to perform a critical function, is there more or less value to the customer? More or less quality?
If a group delivers a pristine product to the customer but it’s six months late and the customer had to manually conduct business during their busy season while waiting for the tech solution, is there more or less value? More or less quality?
So here’s where I’m going with this diatribe. If the customer views quality as a more humanistic characteristic, like the quality of life on the job is better or the quality of output of that person is higher, etc….is IT picking up on that? Reduction in defects is not going to address those aspects, right? IT focuses on things like cost, speed, defects and dates to show a customer that they are delivering value. Does it also, or should it also seek to address these other nuances of quality that may remain hidden?
Where do customers find opportunities of the system. To an exec manager, the opportunity is to reduce cost. That provides quality to the business environment by controlling cost. To the mid mgr, the opportunity is to enhance staff productivity, which provides quality in volume delivery to someone. To the end-user, the opportunity is to streamline necessary steps from the daily grind and the quality of that person’s work life is enhanced while meeting the needs of the management.
Should we be asking our customers to define attributes of quality, value, time during project kickoffs? In tracking the standard cost/time/quality attributes, do we in IT continue to indirectly address overall customer quality concerns or do have lost sight of them.
Thoughts?
I think customer defined qualities are one thing, but lie a little bit outside the realm of “software quality”. If anything, we have concentrated a bit too much on those aspects of quality that directly provide value to the customer, functionality and reliablity, and forgot those parts of quality that help indirectly provide value to the customer, such as all the other aspects defined in the ISO 9126 quality model such as testability, portability, understandability, modifiability etc.
We see this most concretely in most so-called “QA” departments that actually do nothing more than QC, or testing and filing bug reports; they check that the software does the right thing, but neglect the true function of QA, to evaluate that the software was developed correctly.
But there is both a need, as mounting levels of technical debt make delivering true value ever slower, as well as a movement, to bring Real QA back into the QA department.
The Gilbs even started a manifesto about it: http://www.gilb.com/Real+QA+Manifesto
Thanks, Richard for the qualification. I’ve updated the post to reflect the revised quote. My sincere apologies. Ironically enough I am currently re-reading Zen and the Art of Motorcycle Maintenance where Pirsig says essentially the same thing…for those of you new to the book his initial attempt to define quality directly drove him insane. I should know better.
Doug, I think you are right on for a line of questioning that unearths how your business perceives both the value and the quality attributes of any given project. I’d be interested to hear what people have to say on this and how they have approached this in their software development organization.
Richard,
Fair enough, defining quality isn’t the point. I think that the distinction between the internal, or intrinsic, software development characteristics (we can call it best practice design and development instead of quality) and customer value remains.
It that is a valid distinction, then the ‘in the future’ clause as part of the goal of a software organization makes it a best practice. It may or may not be a customer value proposition. Like any other best practice it is subject to alignment with the customer value.
In rereading the thread, I realize that I’m looking at the topic from a BA perspective of liason between separate IT and business organizations. In this case the tension between internal best practices that aren’t aligned with customer value (over engineering by building too much adaptability or missing the core value entirely) is, in my experience, too common.
From the perspective of an IT organization that has strategic responsibility for business success, e.g. office of the CIO, establishing the ‘in the future’ clause with its implication of adaptability, interchangeability, and scalability is an establishment of a [ed. Excellent!] business value requirement to be implemented by aligned development best practices.
To, finally, get to the question of particular practice, test, or meeting that helps deliver value: Lets assert that it is possible to find IT development organizations competently executing best practices.
The need is to understand the customer value better. This implies a better understanding of the whole customer system to assess the collateral impact. Note that the business may not be able articulate the key issues up front. Quick example:
* service provider who commissioned a survey management system when the entire value was a tick mark on their client’s capability questionnaire. (weren’t at a maturity level to do process improvement based on surveys)
It’s too easy to say this is just something the BA should do. Customer value analysis falls into the EA knowledge area of the BABOK which is still evolving so the best practice and techniques may not be in place.
“Customer value analysis falls into the EA knowledge area of the BABOK which is still evolving so the best practice and techniques may not be in place.”
While this is true, it’s also at a different level of granularity. EA analysis of customer value is going to define value attributes and/or characteristics that the project, as defined by the customer, could/should/would bring to the organization if the potential solution is implemented.
At the project level though, there must be some sort of trickle down to align customer expectations of quality and value just like aligning any other aspect of a project, e.g., business rule, process, etc. Lower level stakeholders may not have the same perception of value/quality as the sponsor. Hence, delivery of a solution that is perceived to reduce the quality of work-life, for example, while positively addressing whatever the sponsor views as higher quality, might be deemed as a failure.
This is ever more important without EA or an immature EA being in place.
Doug,
This why i think it is a business, not IT, issue. Ideally it would be in place as the context a project is commissioned within. I think we agree that there is a clear BA role in producing that context, just, as you say, at a larger than project granularity.
There is, clearly a scoping issue for value questions — The CEO isn’t going sit for an interview by every project.
Value and quality perceptions by lower level stakeholders are very problematic. New systems means change, which is fuel for push back and dissatisfaction. And some sponsors can have very selective memories of what they asked for when faced with restive troops.
In my experience there are only two effective mechanism for alignment: Strong top down enforcement (people don’t complain when it doesn’t work) and increasing the clarity with which the lower level stakeholders can see the value they are contributing to the larger enterprise (people want to know their job matters and respond positively when it does). I’ve seem people practically come across the table with excitement because they “finally understand my job” with a system that might fairly be characterized as taking away their freedom of action and putting them under a management microscope.
Yet another up front BA alignment job to make it work though.
I’ve been both an IT software development manager and a QA manager, so I’m very familiar with the tradeoffs of quality vs. speed-to-market. I was going through a masters program when I was a QA manager so I did my thesis on the cost of quality. I don’t have the paper handy any more, but I remember the cost of fixing a bug goes up exponentially the further along in the development cycle you get and spikes up particularly after deployment, because then there are all the costs associated with customer satisfaction on top of all those associated with a redeployment to fix the bug. I have to admit that some of the metrics in reports I see are a bit suspect because they are often based on the “number of bugs” or “cost of bugs” and we all know that bugs can range from trivial to catastrophic… I think it’s key to assess the risks and costs associated with quality and costs associated with delivery time… and those would include the costs associated with reputation and poor customer satisfaction.