Tag: quality

  • Price versus Quality

    “Price has no meaning without a measure of the quality being purchased.”

    ~W. Edwards Deming

    It always fascinated me how price was the main axis of the game of closing software development deals. Unfortunately, in the vast majority of cases, pricing is used in total isolation from any other criteria, especially quality.

    It was like this when I worked on off-the-shelf ERP software. In this case it was, to some point, understandable. You can’t universally define functionality-to-price and quality-to-price factors if you sell the same product to thousands customers. It will be different in many cases.

    In such a case the question is what you deliver for the price you put on the tag attached to your product. Is it of high quality? And more importantly: do you keep, or even improve, the quality consistently?

    As a matter of fact, we didn’t. We didn’t think in such terms. It was more of a chase for more functionality to satisfy new customers than a conscious effort to keep the quality of software stable. You may guess how that affected the quality. Let me just say I’m not proud of the end result.

    It was still much better than what I experienced later, which was building custom projects for big clients. As a leader of software development and project management divisions I was often involved in the sales process. I was always asked how much time and people we need to build a thing. I was often asked about features the thing had or was going to have. I was never, ever, asked about the quality of the product or the tools we’d had in place to ensure this quality. Ever. Not a single time.

    It isn’t an industry-specific observation. I went through a few industries, including banking, insurance and telecommunications, and it was always the same.

    I’m compassionate for these poor chaps that were the decision makers. They followed their fears represented by the “nobody ever got fired for buying IBM” attitude. They just played it safe. In fact, I blame the system.

    I blame the system that disconnects the price from the quality of purchased goods or services. In such a case price is almost meaningless, yet it is almost always used as a deciding factor.

    The question I often wanted to ask the decision makers was: if they were buying the product with their own money would they be choosing the same? Obviously not. In fact, when we refer to our everyday lives, which I like doing, we never forget the relationship between quality and price.

    When I buy sticky notes to use on whiteboards I choose 3M even though they are pretty expensive when compared to alternatives. Actually, given a choice, I take 3M Super Stickies, which are even more expensive. It’s just the quality I need and I’m willing to pay for.

    When you think about the slow food movement being more and more popular over the course of the past 20 years, it follows the same pattern. Most of the premium products exploit the same behavior. Heck, how many of you, my dear readers, bought one of those overpriced smartphones or tablets? Apple fans, anyone? What is it if not paying for quality? And how do you choose a new car I wonder? By price tag only?

    So why, the hell, do you become Mr. Hydes when you return to your workplace and you choose a vendor? Oh, the system, I forgot.

    The system is, in fact, bigger than just an organization choosing a vendor. It spreads across most, if not all, of the vendors, too. A good picture of this would be a story my friend told me about the tender process in Romania in which he was involved as a representative of one of the bidders.

    When all the offers were formally submitted, the client organized a meeting with all the potential vendors, announced what the lowest bid was and asked everyone to reconsider their offers giving them half an hour to resubmit proposals with new pricing.

    When they had all the discounted bids re-submitted they did it again.

    It’s just spreading a sick behavior throughout the whole ecosystem. Optimizing solely for price means cutting corners on quality. Heavy price optimizations mean painful quality tradeoffs.

    And we know that low quality means a lot of rework and, as a result, higher overall cost.

    Now, that I’ve changed jobs, I’m more directly involved in the sales process. And I couldn’t be happier to learn that we don’t take part in this game. We are (relatively) expensive. Don’t expect the lowest bid from us. We understand what it takes to build high quality software and are ready to walk away if someone expects us to drive the price down to the point when we compromise the quality.

    Because, at the end of the day, low price is costly for both: a client and a vendor.

    You just can’t consider price in isolation from quality.

  • We All Are Salespeople

    A developer who sends an email to a customer to elucidate some details of proposed solution. He is a salesman.

    A project manager who goes on biweekly status meeting. She is a saleswoman too.

    A support engineer who answer for ticket submitted by one of clients. Guess what, he’s a salesman.

    A manager of software development team who receives escalation call from disappointed customer. Surprise, surprise, she’s a saleswoman.

    It doesn’t really sound as they all were salespeople but they are. Whenever we contact current or potential customers we all play role of salespeople at least a bit. It doesn’t mean we all should wear suits and have this marketing blah-blah talk ready to fire at the customer. It doesn’t mean we should all have minds set for thinking what product we could up-sell there. But it does mean people on the other side will evaluate our work as the part of current and future sale process.

    We’ve done a project with them and we won’t do another.” Odds are that’s not the fault of sales representative alone, but developers or support engineers or project managers or all of them screwed their work. They failed at up-selling anything more, no matter how great their product could be.

    We considered them as a company suitable for small projects only but they’ve proven their worth and now they’re one of our important vendors.” Oh, that wasn’t only the effort of key account manager responsible for that customer. Or was it?

    Even when our work isn’t seen directly by the customer it works that way. If a quality engineer does a perfectly good job hunting all the glitches it will be appreciated as an effort invested into high-quality. The company will be considered as one of these which delivers quality solutions (even when they aren’t always on time) and that’s pretty important factor when customer chooses a vendor. Or at least it should be.

    In this way or another we all help in selling our products. Most of the time we do that unconsciously but it doesn’t change our influence on setting new deals. We all are salespeople.

  • Good Enough

    My friend asked me to give an opinion about design of application his company had developed. I took a glimpse on their technical presentation with a lot of screenshots. I must admit my attitude was very positive, whole thing looked professionally. That’s what I told my friend. His answer was a bit surprising as he said he would have worked more on UI design. On the beta stage? It was really good enough. Or even better enough.

    The discussion brought me to think about good enough paradigm in software business. One side believes that if software is good enough the job is done. Another wants to polish all the details until they bring their software into perfection. Although I haven’t seen any statistics about that I believe the former group is more numerous one.

    Software constantly conquers new areas of our life including those where there’s hardly place for good enough believers. Hospitals, planes, cars or military areas. I guess you wouldn’t be happy if your good enough software managing your car brakes crashed. Yet still most software which is developed is not mission-critical products. It just sends e-mails, creates documents, pass information, manage some content, store some data etc. There’s a choice between good enough and close to perfection.

    Personally, I’m a good enough guy. I have just one point here. Costs. Imagine a theoretical scale of perfection of software ranging from 0% to 100%. When you start your development you’re in 0% when you finish you’re somewhere in upper half of the scale. On the beginning improvements are easy. You invite first test UI which looks like it was designed by blind monkey. Then you have first iteration of target UI. It’s a huge improvement, probably a couple of dozens percents on the scale. However, when you’ve already made several iterations with UI and it looks decent the next would be probably making extensive usability testing. It’ll take much more effort than the first steps. Results will be probably much less significant. Few percent if you’re lucky. Next step? Maybe user feedback? You employ a number of people, who deal with all e-mails and phones from users, than trying to find a schema in all that mess, then verifying if accidentally some requests are not exactly opposite to others etc. More effort. More money. Results limited. Maybe another percent earned on the scale.

    The example says about UI, but the rule is general. First performance optimizations will be fast and effective, unless you do them randomly. After some successes they’ll become harder and more costly. On the beginning of stabilization you’ll deal with big numbers of issues vastly improving stability of software. On the end the whole deployment will wait for a single bug fix. Of course that’s not a paradigm – there’re exceptions. Sometimes you can find some easy improvements even when you’re high on the scale, but it shouldn’t happen very often.

    That’s why I’m a “good enough” believer. I don’t refuse to make small improvements, even when users can live without them. They’re welcome as far as they’re cheap. Great example was described by Basecamp team. Those changes are close to border separating good enough from better (hard to say on which side they are), but they were quick and cheap. And I guess the more important improvements were done earlier. If the changes were significantly more expensive I think 37signals would leave it as it was.

    I believe that unless you have much time and money to spend you shouldn’t chase the ideal. There’re more important things to do.