Search This Blog

Saturday, March 24, 2018

Looking for Bad News

According to John Kotter in his seminal book “Leading Change” most organizations tend to be complacent and avoid bad news. Back in the 1980s, I was with a corporation that bought into the concept that expressing issues as “problems” was bad for organization morale and increased anxiety among employees and depressed creative solutions. The recommendation by the psychologist that proposed this issue was to substitute the words “challenges” or “opportunities” for the word “problems”. That substitution became a policy at this particular company and we were all advised to use the word “opportunity” instead of the word “problem”. I’m not sure how seriously we in IT took the edict. There certainly were a lot of jokes and sarcastic comments made about problems and opportunities, but in the end the substitution did take effect and most people were in fact using “opportunity” instead of “problem”. I don’t know whether employee morale improved, or anxiety decreased, but there certainly was an attitude that things were getting better around at the company, because we had no problems to talk about. Of course with no problems to talk about, there was also no compelling reason to make change, since change only occurs when a problem has been identified, and that led to a form of complacency. And this is the issue that John Kotter was talking about.
Change becomes very difficult if everyone is satisfied with the way things are. There seems to be a trend in many organizations to shield managers from bad news. This is especially true in IT where the engineers would rather solve a problem then bring it to management’s attention.
Business analysts confront this issue on a regular basis. A business analyst is told to find a way to improve a business process and when gathering information from the system users in the process workers finds that they have no need of improvement because everything is going fine.
While we tend to avoid seeking out the bad and try to follow the good advice for making friends and informing people which is to look for the good in everyone, as business analysts we should be looking for things that are not right, processes that could be improved, systems that are simply “bad”: not flexible enough for today’s business, too slow to keep up with the competition, to archaic or clumsy to use it efficiently (even though the users of the system may be completely satisfied with it because they have learned to overcome its idiosyncrasies), or simply not in tune with current technology.
To get the necessary changes approved and implemented we need to address the problems as problems. “Opportunities” can be skipped, delayed, subjugated to other opportunities, or simply ignored. After all, missing an opportunity does not hurt, it just does not help. A missed opportunity may fall into the category of “coulda, woulda, shoulda”. But a problem has to be addressed because failure to do so will hurt.
Of course, we as business analysts have to recognize that we will not be the most popular of people when we present the “bad news” to management. But often, as Kotter suggests, may be the only way to make effective change to the organization.

Sunday, March 11, 2018

Seeing is believing or is it?

Quality is something we all want in our products. A product that delivers what was promised and what we expected, won't break when used, is consistent in use, is easy to use and pleasant to look at, and so forth.  We who are involved with product development and product delivery know that quality takes time. So, a constant plaint of those who work on the development side is that management never allocates enough time for quality. Management just wants the product delivered to beat or meet the competition, or to meet some agreed on deadline with a client or customer.  And, worst of all, management many times seems to think that a product is ready for delivery when the developers know it is not so.  Why don't they see it? 
They actually do, and that is a source of the problem in software.  Most managers today come from a non-software background.  Their familiarity with software extends to the apps and systems they use regularly.  They generally hail from a hard product background - physical cell phones, cars, computer hardware, clothing, buildings, and so forth.  When they see the product ready for delivery, a building, a car, a table, they can see the defects and if they cannot, the product is considered ready to go.
With software we can demonstrate a feature or function working well. Management sees the screen and the actions taking place and sees some results. Therefore, like the table with no scratches, it is ready for delivery.  It is difficult to convince someone who sees something working before his or her eyes that there may be issues lurking behind the screen.  That is what the cognitive behaviorists call dissonance.  Our minds must come up with a way of explaining it all.  And, since management has a vested interest in getting the product out, confirmation bias kicks in and management resolves the dissonance by ignoring the issues of lack of quality and rejects the request for additional time to fix something management cannot see.
The end result?  Products delivered with less quality that we would like.
I don't know the answer other than to make the product break in front of management's eyes, and that introduces a whole lot of other, rather unpleasant issues. But at least we can solace ourselves in knowing that there is a human explanation for the conundrum, if such solace helps at all.