We lived in North Carolina many years ago (our youngest daughter was born there).  On weekends we liked to take rides in the car, my husband and I and our oldest daughter, then two.  We’d go into the mountains, visit the furniture stores, or drive off to the sea side.  One of our favorite places was Ashville, NC – in the foothills of the Blue Ridge Mountains.  It was lovely there in June – just the right temperature.  Not too humid.  Enough elevation to get away from the early summer heat. 

There was a great big old house in Ashville the looked like it could have been a plantation or stately manor.  It had a huge porch all the way around the house .  The owners had turned it into a restaurant and the porch now had picnic tables set for visitors.  We went there the first time with our 2-year old daughter and were seated at one of the picnic table overlooking pine trees.  There were no menus but the table was already set with plates and dinnerware.  Shortly a woman came to our table and said “Today we’re having chicken and pork.  Would you care to stay for dinner?”  Not sure what that meant, having expected a menu so everyone could order their choice, we wanted to find out what this Southern option was so agreed and soon large bowls of roasted chicken, pork, boiled potatoes, and black-eyed peas were brought to our table – Southern cooking, family style.  I’d never had black-eyed peas before.

Years later I attended a software management lecture by a man from Tennessee who, with his very Southern accent, talked about the “fuzzy P’s”.  I initially thought he was referring to those black-eyed peas from the South.  But no.  He was referring to the 3 P’s that drive a software project:  People, Plan, and Product.  “People” are the number of heads you can put on the project.  And while you can’t gather 9 women and produce a baby in a month, there are some impacts that can be made if the right resources are allocated to the right schedules.  “Plan” is the schedule – moving the schedule in or out is an obvious choice and one of the ways a manager can effect the end result.  And “Product” refers to how much product (how many changes, bug fixes, enhancements) is included in that release or that service delivery to the customer.  Remove some features, save some time. 

The three “P”s can be adjusted to affect the end result.   But that’s it.  Those are the only viable axes in the three-dimensional world of software that can be controlled and still produce a good, product.  If axis one doesn’t get shortened, the others will not be impacted.  If a software schedule can’t be met, then either more people are needed or less changes / enhancements/ fixes can get into the delivery. 

Usually CEOs want it all – they want the product with all the specified features in the timeframe they want it using only the resources that fit their budget.  But if the three axes don’t align, something’s got to give.  And it’s the software manager’s job to juggle the axes – more people here, less product there.  But CEOs push back and too often software managers try to appease them and agree to accept the dictated schedule with the resources allocated and all the specified product features. 

And there’s only one result – the hit is on quality.   When there aren’t enough resources to do the job right, quality suffers.  It isn’t always apparent to the CEO.  Perhaps the team even thinks they are doing a good job by delivering the product and making the milestones.  There’s a big party to celebrate the release, and everyone is congratulated.  But it’s the customers that will be impacted when they encounter the bugs that ultimately will result. 

And ultimately this approach will affect the bottom line.  It’s another well-known software rule that bugs found by a customer are 1000 times more costly to fix than bugs found during the design phase.  If a bug found during design (or at that point, an issue or problem) take a few minutes – say it would cost $10 to fix, if it isn’t found in design but rather during coding it will cost a couple of hours or $100 to fix.  If found during the QA cycle it costs $1,000 to fix (develop, re-test).  And the same issue found by the client costs $10,000 to fix.  Measure it.  It’s a fact.  Issues found by clients need to go back to the design, impact code, changes are likely to cause other issues, QA needs to be re-done.  Manuals updated.  Other clients notified.  It’s a very expensive proposition.  Not only that, it affects the customers’ perception of the company and it’s software.

So why isn’t quality the primary focus since it’s the most expensive error to make?  It’s the fourth fuzzy P.   “Perception.”  As long as the CEO “perceives” that the product is going out regularly, that everything is on track, managers are rewarded and all’s well.  Or seems to be.   But letting quality slide is a slippery slope.  If no one is tracking the overall quality metrics, quality can slide without anyone noticing until the product has degraded to the point the customers rebel.  Take the Microsoft operating system years ago where the blue screen of death was the well-know scenario. 

Bottom line – the trade-off should never be quality.  Good software managers need to watch their P’s and their Q.