Systems & Software Talk 

The TORG Effect

Not so long ago and not so distant in a future that spirals to meet a past with great binary agility, I sat under a rocky edge with a waterfall draped in front of me. The mist was misty. The moving drape thundered. I heard a writer ask what a CIO needs to know about requirements. I erupted. Here is the resulting verbal lahar:

Please do not inquire about binary agility as I have no idea what it means.

Picture the SDLC classic bell-curve. A big chunk of that heap of work in and at the center of the peak is typically unnecessary and exists primarily as a result of reaction to failed or missing processes or as a result of poor requirements - poor for many reasons. Some reasons consist of the usual culprits - incomplete, missing, or ambiguous requirements. If a formal requirement process is absent, how does one finally come to understand there are requirement issues? Let us locate ourselves in and under the weightiest part of the bell curve along the project timeline – just under the peak under the heaviest segment. Do you feel the weight of it? What is the PM’s understanding of the project at that point? It is a perception-based understanding! Think about it.

1. R&D is cranking out code – much of which is not being unit or unit-integration tested. (That signals additional and unnecessary work for the test team – a team that will undoubtedly have their test time squeezed to almost nothing!)

   Status reports show many KLOC or objects, methods, and classes developed. In general and with a few perceptions of minor variances, the project appears to be in good shape. With a few extra hours of overtime here and there, R&D will make their deadlines. All appears generally well. Sure, developers might be expressing concerns about issues with requirements, but they typically have immediate access to the BAs to get clarification – most of which is unwritten and/or not communicated any further. The PM now perceives the project to be in yellow to green status in R&D. Propagate those statuses upward through management layers - the usual path of status embellishment and assurance add-ons and the status is a big bright green fattened with assurances! Clue: the number of assurances equals the number of failure risks! And at this point. no one wants to hear or see the wrath of the marketing.

2. The Test Organization (TORG) is most vocal at this point because they see what is happening but are not likely to be given audience since most of the attention is on R&D. TORG is expressing concern about the usual issues - incomplete, missing, and ambiguous requirements. And TORG is being heard but not understood. At some point in the struggle to get testable requirements or for that matter any requirements, TORG is instructed to back off because of being a distraction to R&D. TORG is simply trying to understand what is to be tested. TORG is now perceived to be a bunch of complainers who serve as nothing more than a distraction. This is the point of origin for statements such as, "Any monkey can do this!" or "This is not rocket science!"
3. What are some other events or indicators that the project has arrived at this point? Here are a few:

• TORG finally has something incomplete to test.
• TORG writes defect reports. TORG write defect reports on defects that should have been detected in unit and unit-integration testing. They should have been prevented in the core of the requirements phase!
• TORG is now fully engaged in doing the work of R&D – finding defects that should have been caught in unit and unit-integration testing that never occurred!
• Defect report validity challenges and arguments ensue.
• Fix/build frequency increases to the point that the amount of code to be tested exceeds the capacity of TORG. Most of these builds could have been prevented.
• "Throw more testers at it."
• Management begins to suspect the huge growing gap between perceptions of progress and real progress. Moses didn’t need to spread his gesturing arms to part the Red Sea. He needed only a bell-curved software development project.
• It takes time for management to muster the courage needed to state the bad news that is simply not getting better with age, because no one wants to hear or see the wrath of the marketing.
• Pointing fingertips begin to emanate blinding beams of blame, so blinding that they stifle enthusiasm and foment low morale and mistrust.
• Stress, mental, and physical exhaustion take a toll on productivity. Sick days begin to accumulate rapidly.
• Knock-knock! "Who’s there?" "It’s me the development methodology vendor with your package of silver-scrumalite and agile bullets!" "Do come in!" High-rate per hour consulting contract signed. FTEs are rightfully agitated as these glossified starched collar consultants are preaching all-too familiar FTE-originated themes, and to make matters worse, the consultants are getting audience, action, and much higher pay! "Wow, these consultants are super! Do you have any more available to help us?" More previously empty cubicles are now adorned with expensive leathery luggage for hauling notebook computers. "Sure, I understand your consulting team is so large that I accept your recommendation that you have a billable manager onsite! Please take that unoccupied office over there overlooking the lake. That is where the former TORG manager sat."
• More distraction and failure sets in!
• Coded output slows down due to the fact that the developers must now implement consultant ideas that just were not good ideas when the developers recommended them!
• TORG is now on a mandatory 50-hour workweek to test untestable code that breaks as a result of someone saying, "I will test this GUI portion tomorrow". The application cowers in fear and then fails.
• Defect reports now exceed the processing capacity of the entire project team.
• Knock-knock! "Who’s there?" "It’s me the tools vendor with your silver bullet record and playback test automation tool!"
• The deal is signed! The tool is painfully implemented. It is soon discovered that "record and playback" is one-shot in nature. Repetition requires programming. Deer are in the headlights and they are frightened.
• " TORG, get your people to automate this stuff now!"
• "What do you mean training? There is no time to train these people. Just get the stuff automated."

1. Release Date has arrived! The software ships after a few delays and back and forth promise/litigation-threat-based negotiations.
2. "What! Bugs in production! The customer wants this fixed now or they toss our product out and sue us."
3. With all anger-powered ferocity "TORG, how did your people let these bugs get by you?"

I think everyone knows the rest of the story!

Let us revisit that bell-curve as effort, especially that at the upper third of the mountain. Much of that is effort that should have been distributed in such a manner as to flatten that curve both back and forward in time, and push that promise date out further to one of reality. Now your project costs may exceed the estimated costs by 1,000% or more.

The key to success rusted quickly and could no longer open the door to reality. Most of what you just lived (so many times over) in the above depiction could have been prevented with good requirements engineering and management practices and actually listening to TORG along with involving TORG at project kickoff. I submit to you the CIO that true status can be derived from the state of the requirements as opposed to the mouths of people. TORG should be involved and given audience at project kickoff. Only TORG can tell you if the requirements are testable. Why not then use TORGs deliverables for the source of truth in status and estimation refinements? That is not to dismiss the status and progress of other project deliverables such as code and user documentation. Metrics related to the latter, are certainly important in determining true status.

An untestable requirement simply begs more effort hours. Those effort hours are simply washed away as TORGs timelines get crunched between tangible code that they can touch and the time to promise date. CIO, you already knew this. Green light status euphoria distracted you from your past pre-CIO experiences.

A key metric to you anywhere in the project should be the status of the requirements! Let TORG own this. Trust them like no other for this is the source of truth. These monkeys are knowledgeable about this aspect to a level beyond compare!

A key remembrance for any CIO, PMO, or PM:

Project truths transition from being based upon factual evidence at the beginning of the project, to truths and decisions being based upon perceptions and reaction as the project progresses. The only untruth at the beginning of the project is and was the marketing promise date. All else at the beginning was truth based upon fact at that point. A promise date should never be issued without proper estimating. All project teams should be given equal credibility for their estimates.

Any finally, I grab your wrist again to eyeball your timepiece and once again communicate the time to you! You need to recognize that requirements must evolve all along the project timeline. Therefore it is key to have a process in place to manage those, contain, and confine them in order to meet deadlines based upon real estimates and experience. The world has been trained to accept versions of software. That fact gives you the latitude to allocate features and functions across multiple versions. Therefore one must negotiate version content with a customer. With proper requirement practices and management processes, you will score high marks of credibility with your customer. This will fuel successful version content negotiations. And when you deliver product that was not a classic bell-curve victim, you can have great confidence in that product!

PS: Tackle those tough and complex requirements first.