| COLUMN |
How poor management skills jeopardize software quality |
 |
By John Scarpino
16 Aug 2007 | SearchSoftwareQuality.com
|
Communication is essential for human survival. The earliest signs of viable communication occurred 5,000 years ago in Southern Mesopotamia, where inhabitants wrote on clay tablets in a wedge-shaped writing called cuneiform. We have luckily advanced far beyond that stage! However, it is unnerving to see how, even with modern technological advances, the transmission of imperative information can become lost –- or perhaps deliberately brushed aside.
On a personal level, I have witnessed several recurring factors concerning the purposeful misuse of information by managers when it comes to heading up an IT project or organization. There are circumstances where company politics and the desire to retain one's power as a manager hold greater importance than being open and honest to the IT team. Of course, this downgrades the quality of the final product. There is ultimately a lack of respect for the company at which they work, one's employees and product quality for the sake of maintaining a political image. "Power by information misuse" must be addressed sooner rather than later in America's IT community or the quality of the total business practice will be a disaster.
Most people would agree when I say that our overarching goal in the corporate world is to execute our job to the best of our ability. This is especially true for those who work in IT quality assurance. If the importance of "quality" disappears, what do we have at the end? A shoddy product that must be tested and re-tested, with issues popping up that could have been avoided if the proper communication was in place, wasting our time and resources. But managers who refuse to comprehend the importance of process and procedure with their employees don't see that part. What they see is deadlines and customer service, which does makes the client happy -- but in an unorganized fashion. And if these two aspects are not met, they managers are sure to make things ugly.
When a scenario like the one mentioned above takes place, one of Machiavelli's greatest quotes resonates, "It is better to be feared than loved, if you cannot be both." I have seen the fear that this great philosopher speaks of in two interrelated ways when it comes to IT projects:
- There is a fear present among managers about allowing their employees to manifest what they know about quality assurance. Managers are afraid that if that occurs, employees will eventually usurp the power they maintain. (This fear is usually due to a manager's ignorance about how a company should operate.)
- Managers, in response to #1, display their dominance, thereby creating fear among employees that they may be fired if they happen to take the time to expound upon a product's quality -- against their company's wishes. In that case, a similar (but in some ways, more profound) quote from Machiavelli comes to mind, "It is much more secure to be feared than to be loved." After all, who wouldn't want to secure their position as top dog, especially in IT?
|
|
|
|
|
'Power by information misuse' must be addressed sooner rather than later in America's IT community or the quality of the total business practice will be a disaster.
|
|
|
|
|
|
|
|
|
|
Projecting fear onto others may be one way managers persuade employees to do as they are told in certain cases, but it should never be a way of avoiding the creation of a quality product. Similarly, a QA manager's personal agenda should never influence the way he delegates projects to the department. Such a managerial style contributes to the demoralization of employees, and the company environment becomes depressed. Clear, open-minded individuals who are devoted to caring for the company's clients, products, process and well being are the real winners in any corporation. That may be unrealistic, considering the egotistical norm for American big business, but I prefer to remain hopeful. The bottom line: Whoever manages a QA department should fully agree upon and understand the impact and importance of sustaining a high level of quality in all projects.
Real-world example: NASA
Think for a moment back to January 1986 when NASA's Challenger space shuttle disaster occurred. As you may very well remember, it was discovered that the O-Ring on the shuttle had cracked as a result of a recent bout of cold weather. The mechanical engineer who inspected the shuttle found the problem days before and made his superiors aware of the issue several times over. All brushed his concern aside each and every time. (I mean, after all, The Challenger had already been delayed twice due to bad weather. They had a deadline to meet, you know.)
The engineer inspected the shuttle once again before lift-off, when he saw that the O-Ring had not been fixed. Even though he knew what could happen, the man feared that he would lose his job if he became a whistleblower and pushed too many of his managers' buttons. We all know how this story ends. It is such a shame that seven people lost their lives because of a few managers who put their own agenda first.
The fear displayed by Challenger's mechanical engineer also occurs among employees in the IT environment. And though lives may not be at stake in all software instances, the same sort of principle governs.
The effects of poor communication
At one point I worked for a company that had software emergency builds a few times a week. In this particular company, my manager nor any manager communicated anything to my group -- that is, until something drastic needed to happen. An email would then be sent out to us, demanding that testing be done quickly in order to meet his deadline (often within one hour before the close of business hours). This time crunch forced the QA group to test only until the product barely passed standards.
Soon after, we'd be stuck testing the same thing over and over again because the problem wasn't fixed the first time. It was as if our manager was saying, "OK, boys and girls, it's all up to you now. Good luck, even though it's a nearly impossible project to take on. But don't fail me, or you'll be sorry."
Many of my co-workers feared for their jobs if they were to oppose the way things were being handled. But we all knew that if we were given the information up front instead of waiting until the last hour, the software would be good to go much sooner and many headaches would have been avoided.
The best way I have found to thwart the onset of a communication meltdown in IT is to make sure that the following rules are set in stone:
- Establish a central point of communication in the company where everyone is informed about what needs to be done
Lack of information among multiple parties in a company causes discrepancies that, again, create unnecessary risks when it comes to the quality of the final product. When important information arises on detrimental issues, it should be communicated to everyone affected by the problem, most importantly the IT team. Often IT companies hold meetings, create a trouble ticket or place documentation in a portal. To centrally manage an issue, it's important to communicate it and document it to assure that the proper steps will be taken afterwards.
Assure the business flow
An expectation of how daily business should flow must always be known up-front in any IT company. When these guidelines are made, the agreed-upon process must also always be followed (with a few exceptions). Having a viable, documented business flow helps promote proper communication throughout the process for internal stakeholders, as well as externally with the clients.
Project quality and procedures
Any change within a business process or system must always be assured in a proper manner. Guidelines for how this procedure is done need to be met with company standards, as outlined in step 2. These strategies must also be tracked, tested and audited. For example, testing should always be conducted to assure that the requirements of a given software project meet the requests given by the client, or that all departments meet the procedures during the software's development.
Project planning
A strong plan from start to finish is necessary to assure a project's success. Managing the stakeholders, the start and end dates, documentation, delivery and expectations are crucial for a successful project. The initial project plan needs to be implemented as soon as possible in the project life cycle so as to meet all expected criteria.
Project documentation
Knowing the exact information that is to be used and delivered is crucial in order to maintain open lines of communication throughout departments and with the client. This information should be mapped and documented so as to leave a "paper trail" and expedite the process of any re-dos. Often standards for documentation are used to assure all proper information is gathered and recorded. In the past, I have created documentation matrixes for several of my employers. These matrixes listed the required documents in terms of client, project size, project cost and project timeline -- depending what was required. The matrix pointed out each of the expected deliverables for the projects we were working on at the time.
Establish a clear understanding of client expectations
This step is pertinent if the proper external and internal communication is to move forward. As mentioned above, a client's expectations are mapped out and documented, but in my experience those requirements are rarely met during the first time around with the client. The client should sign off on the final list of requirements before any project timeline or budget is implemented.
We've become much too accustomed to sending our most important information, such as client requirements, through means such as email, but that opens up an opportunity for miscommunication or a total failure to receive it at all. A formal document on requirements must be well-written, reviewed and signed off by the client in person -- or at least over the phone -- so as to address any discrepancies. All expectations need to be met and contingencies need to be spelled out in case unexpected issues occur.
Promote a solid knowledge of project goals
An IT company and its client may have two separate objectives, but both must work together to achieve the same goals. The scope of a project and its objectives should to be properly documented and communicated (as steps 5 and 6 indicate). Neither side should ever try to skip the above guidelines in an effort to cut corners. Goals may change over time, but any such change must be communicated as soon as possible so that a new end-goal can be obtained.
As a director of quality assurance I've gone through much trial and error in my career before being able to fully perfect the above seven steps. These rules assisted me greatly in pumping up the quality of my company's work and the interplay of communication between internal teams, external teams and our clients. When all seven steps are used properly, the fear that is so readily projected onto IT employees will eventually disappear. But in order for this to work, these steps need to be widely accepted and agreed upon starting from the top managerial position and going all the way down to the IT intern.
I will end this article with yet another quote from my favorite philosopher, Machiavelli, who states,"The question is, then, do we try to make things easy on ourselves or do we try to make things easy on our customers, whoever they may be?" I believe that America's IT industry has yet to come up with the right answer.
Quotes from Machivelli can be found at http://www.brainyquote.com/quotes/authors/n/niccolo_machiavelli.html.
-----------------------------------------
About the author: John Scarpino is director of quality assurance and a university instructor in Pittsburgh. You may contact him at Scarpino@RMU.edu.
|
|
|
|
