This Month’s Pattern *

06 Referred Pain

The project solves the apparent problem but fails to address its underlying cause.

Referred pain is a term used to describe the condition whereby pain is manifest in parts of the body other than the location of the source. For example, spinal injuries are felt in places other than the spine. Sciatica is a case in point: The patient feels pain in the leg, yet the problem is a prolapsed disc pressing on a nerve in the spinal canal. You can treat the leg as much as you want, but the pain will persist–its underlying cause lies elsewhere. Similarly, a person who suffers a heart attack usually feels referred pain in the left arm. Treating the arm will do nothing to save the patient’s life.

There is a tendency when forming projects to address the obvious problem–the one that is most manifest and causing the most pain to the client. However, by looking only to the referred pain, the project delivers a product that, once delivered, turns out to be largely wasted as it does little to alleviate the real need.

Consider the following example: Bank customers who forget their password apply to the security department to have the password reset. This involves complex and costly processing to authenticate the customer before a new password can be issued. At one U.K. bank, resetting passwords cost in excess of four million pounds per year. A project was formed to build new software that would make resetting passwords easier and cheaper.

This project set out to treat the referred pain instead of the root cause of the problem (too many people forgetting their passwords). Because of a baroque password setup protocol, users ended up with passwords that didn’t stick in their minds and the bank experienced “I forgot my password” requests far in excess of what its competitors were receiving. If the bank had addressed the real problem, it could have–at a fraction of the cost–so reduced the number of requests that the existing password-reset approach would have been quite workable.

One commonly observed reason for treating the referred pain and not the cause is a reluctance to investigate. This is sometimes because of the organization’s culture, and sometimes because pressure is being brought to bear on the project to start delivering quickly: “Listen, I know exactly what I want, so just generate these reports for me, pronto.” In many organizations, it takes a brave analyst to first ask, “If you had these reports in hand, what would you use them for? What are you actually trying to do?”

Sometimes, we want to look where the light is shining brightest. For example, we may look to technologies that we know, seeing the problem in a way that best matches our familiar solutions: Ask a Web services designer how to solve a business problem, and he will typically suggest a Web services solution; ask a database designer, and you’ll get a database solution. Needless to say, either could easily disregard any part of the underlying problem that does not slot neatly into his preferred implementation. Moreover, we may be tempted to look to the most attractive problem to solve–the one that will deliver the coolest product. Either of these could result in the engineer rushing to find an ingenious solution to the obvious or stated problem, but exercising his abilities to the wrong end result.

A strong indicator that you are treating referred pain often involves workarounds. These crop up when the current system shows signs of needing some correction, and instead of correcting the prime system, a workaround–allowing something to go wrong and then fixing the result–is applied to correct the manifestation of the problem. A workaround is a Band-Aid and does little or nothing to address the underlying cause of a problem. Yet when one seems to work, more of them are used, sometimes on top of each other in layers of workarounds. Each time a workaround is used, the Band-Aid appears to be cheaper than surgery.

The root causes of many problems are subtle, and often quite removed from the apparent symptom. However, effort spent investigating the real need, and solving the right problem, is invariably returned severalfold.

70 Brownie in Motion

Team members are added to the project before its vision is properly formed.

In the early days of a new project, its leaders are under pressure to accomplish two things: define what the project will deliver, and make visible progress quickly.

The urge to gain momentum leads many managers to equate population with progress. They begin staffing the team before it is really clear what the new members should be doing. Naturally enough, the new recruits are largely uncoordinated. The result of having too many people with too little direction is random activity, or movement in haphazard directions, rather like the movement of pollen grains in water so famously observed by Robert Brown.

The opposite of this pattern is a project that develops a clear and coherent vision of what is to be done, while the staff remains limited to the essential few. The envisioners isolate themselves until they have developed the project’s goals, its scope, its constraints, and a clear notion of the product to be delivered and what benefit that product shall bring to its intended audience or owners. This vision is complete—demonstrably complete—before additional team members are brought onto the project.

    “Send ’em to the movies. At least until a core group has planned out the structure of the project, and defined what newly hired staff ought to be doing.”
    —Steve Mellor

Two of your authors were involved in a long-term project at a major utility company to design and build its largest application system. The effort ultimately required several hundred man-years, but the basic concepts and high-level architecture were conceived by a team of only three people, over a period of three months. Similar cases abound: Today there are thousands of programmers around the world working on Linux, yet the vision for Linux came from only one person. The visioning of C++ was a one-man effort. On the other hand, a committee envisioned Ada.

Adding people to the project before the vision becomes clear is counterproductive. When too many people are trying to set the plans for the project, the result will be muddied and incoherent. Clear vision comes from an individual or a very small group, no matter how many people eventually form the team.



* Each month we plan to publish here one of the patterns from our Jolt Award book, Adrenaline Junkies and Template Zombies — Understanding Patterns of Project Behavior. (Watch this space for a mere 86 months and you'll have read the whole thing.) The book is published by Dorset House Publishing, in the US and Hanser Verlag in Germany. It is available at Amazon and also as a Kindle book.

events

Brussels, Mastering the Requirements Process
20-Feb-2018 to 22-Feb-2018

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works

for details. 

Oslo, Mastering the Requirements Process
13-Mar-2018 to 15-Mar-2018

Suzanne Robertson teaches Mastering the Requirements Process. For more information on this popular course, contact Den Norske Dataforeningen.

Stockholm Kravdagen
22-Mar-2018 to 22-Mar-2018

James Robertson talks about Business Analysis Agility at Kravdagen

Rome, Mastering the Requirements Process
9-Apr-2018 to 11-Apr-2018

Rome, Mastering Business Analysis
12-Apr-2018 to 13-Apr-2018

James Robertson teaches Mastering Business Analysis. Contact Technology Transfer for details of this course.  

London, Mastering the Requirements Process
17-Apr-2018 to 19-Apr-2018

The Spring edition of Mastering the Requirements Process with James Archer. Please contact IRM UK for details.

Brussels, Business Analysis Agility
23-Apr-2018 to 24-Apr-2018

James Robertson and James Archer teach Business Analysis Agility. Contact IT Works for details of this course.  

London, Business Analysis Agility
26-Apr-2018 to 27-Apr-2018

James Archer presents Business Analysis Agility. Please contact IRM UK for details of this course.

Stockholm, Mastering the Requirements Process
15-May-2018 to 17-May-2018

Oslo, Business Analysis Agility
29-May-2018 to 30-May-2018

James Robertson teaches Business Analysis Agility. Contact Den Norske Dataforeignen for details. 

Czech Republic, Mastering the Requirements Process
30-May-2018 to 01-Jun-2018

James Archer teaches Mastering the Requirements Process. Please contact Aguarra for details and registration.

Brussels, Mastering the Requirements Process
5-Jun-2018 to 7-Jun-2018

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details. 

Hilversum, Mastering the Requirements Process
11-Jun-2018 to 13-Jun-2018

James Archer presents Mastering the Requirements Process for Adept Events. Details and registration: English - Dutch.

Oslo, Mastering the Requirements Process
11-Sep-2018 to 13-Sep-2018

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

Stockholm, Mastering the Requirements Process
25-Sep-2018 to 27-Sep-2018

Brussels, Mastering the Requirements Process
9-Oct-2018 to 11-Oct-2018

James Robertson teaches Mastering the Requirements Process. Please contact I.T.Works for details.  

Rome, Mastering the Requirements Process
15-Oct-2018 to 17-Oct-2018

Budapest MRP
16-Oct-2018 to 18-Oct-2018

James Archer teaches Mastering the Requirements Process. Please contact Aguarra for details and registration.

Rome, Business Analysis Agility
18-Oct-2018 to 19-Oct-2018

James Robertson teaches Business Analysis Agility. Contact Technology Transfer for details of this course.  

Hilversum, Mastering the Requirements Process
5-Nov-2018 to 7-Nov-2018

James Archer teaches Mastering the Requirements Process. For details please contact Adept Events. Dutch description, or in English.

Oslo, Mastering the Requirements Process
13-Nov-2018 to 15-Nov-2018

Mastering the Requirements Process with Suzanne Robertson. Contact Den Norske Dataforeignen for details. 

London, Mastering the Requirements Process
14-Nov-2018 to 16-Nov-2018

James Archer teaches Mastering the Requirements Process. For details and registration, please contact IRM UK.

Brussels, Business Analysis Agility
19-Nov-2018 to 20-Nov-2018

James Archer teaches Business Analysis Agility. Contact IT Works for details of this course.  

in depth

Business analysis is often seen as a technical skill. But the business analyst has another set of responsibilities -- to dig into what the stakeholder's mind and uncover what is really needed, and not just what they say they want. 


A Ruby Beam of Light, Book I of Tom DeMarco's Andronescu's Paradox saga is now available in English in paperback and ebook, from Double Dragon Publishing.

"This war isn't going to blow anything up, only turn everything off."



Suzanne and James Robertson's "Requirements: The Masterclass LiveLessons-Traditional, Agile, Outsourcing". 15+ Hours of Video Instruction. 



Als auf der Welt das Licht Ausging, the German edition of Tom DeMarco's science fiction epic, Andronescu's Paradox, has now been published by Hanser Verlag in Munich.  Translation by Andreas Brandhorst.



James Robertson’s webinar for Software Education explains how agile stories are best used to ensure the right solution. Writing the Right Agile Stories on YouTube. Download the webinar slides.