The XY problem in IT management
Online community users know the XY problem:
A person has a problem X and tries to solve it with Y. He asks about help with Y online.
Often X has a straight forward solution which is not Y. But the person asking doesn't describe X.1
The term "XY problem" was implicitly coined when the Open Source philosopher Eric S. Raymond wrote his "How To Ask Questions The Smart Way" text and added "How can I use X to do Y?" to the "Questions Not To Ask" section.
ESR himself states in "How To Ask Questions The Smart Way":
Describe the problem's symptoms, not your guesses
It's not useful to tell hackers what you think is causing your problem. (If your diagnostic theories were such hot stuff, would you be consulting others for help?) So, make sure you're telling them the raw symptoms of what goes wrong, rather than your interpretations and theories. Let them do the interpretation and diagnosis. If you feel it's important to state your guess, clearly label it as such and describe why that answer isn't working for you.
[...]
Since the preceding point seems to be a tough one for many people to grasp, here's a phrase to remind you: "All diagnosticians are from Missouri." That US state's official motto is "Show me" (earned in 1899, when Congressman Willard D. Vandiver said "I come from a country that raises corn and cotton and cockleburs and Democrats, and frothy eloquence neither convinces nor satisfies me. I'm from Missouri. You've got to show me.") In diagnosticians' case, it's not a matter of skepticism, but rather a literal, functional need to see whatever is as close as possible to the same raw evidence that you see, rather than your surmises and summaries. Show us.
Source
As online communities like IRC or forums are quite aware of the XY problem now, the people involved will often quickly focus on getting behind the issue presented. They will ask questions around the "why" do you want to do Y, what is the reason for you seeking help on Y etc. trying to uncover X.
They have been trained by numerous long winded discussions of why somebody would want to solve something as awkward as Y which slowly lead to uncover the unarticulated underlying problems X.2
-
There are many alternate definitions for the XY problem available on PerlMonks. Some - like ESR - define Y to be the original problem and X the offered solution. I stuck with Greg Wooledge and John D. Porter and used X to be the underlying problem and Y the exposed question or request. That occurs more intuitively to me and seems to be the more frequent definition. As they don't change the message both nomenclatures are fine and time will tell which one prevails. ↩
-
Greg "GreyCat" Wooledge has collected examples of the XY problem in IRC communities in his Wiki. ↩
I've been observing the same XY problem many times in my management career. It surfaces quite frequently on the overlap between business and IT functions.1 Business people request a solution from IT and do not describe the underlying problem. IT does not ask the right questions, adds some own interpretation or adheres to company "IT standards"2 and voilà something loosely resembling Y is implemented. And the business customer is unhappy. He considered Y a solution to X. It was not. X is not solved.
In the extended version of the above story the business function then complains that Y was not implemented properly. And long-winded iterations on fixing Y begin.
So what to do?
Being aware of the XY problem's existence helps a lot. You now are. Congrats. Don't forget. Good online communities fall for the XY problem much less these days. Because they have trained to detect and defuse it. We need to achieve the same in IT management.
People. As so often having the best people is the key. Here you need IT staff that understand the business processes and their current challenges as much as they know the IT industry and can separate this year's hypes from the substance topics. These people can ask about the "why" behind product purchasing or development request and thus have a high probability of not labouring around on Y when the (internal) customer actually wants X.
Trust. If the business functions in your enterprise always trusts the IT department to come up with the best solution and hence issue business requirements and honestly and fully describe the rationale for these, you can't fall for the XY problem. As the business people all describe X. Be a bit careful with requirements management. I've seen piles of well written background papers and miraculously precise requirements lists with sound weighting and logical prioritization. All around Y. It can be a tool to detect an XY problem but it can also lead down the Y path with all the confidence elaborate methodologies can instil into people.3
Flexible scope. As you need to assume that the initial target may need adjustment over a project timeline, you must make sure to allow scope changes. Yes, scope creep is often the death of a project. But it's also the indicator of either the implementers aiming much lower than the customer or their aim being way off his (perhaps unarticulated) target.
Agility. Agile methodologies help keeping the customer involved in the progress of an IT project. Therefore they can help to detect XY problems by X being addressed in one of the frequent interactions. Even if that doesn't happen by lucky co-incidence, the frequent SCRUM meetings can well generate early warning signs. E.g. if the customers don't show up for sprint review meetings anymore, you should investigate. Either business priorities have changed or you've been working to provide a non-matching solution. Either way it's a call for inquiry and subsequent action.
-
The reason is that many managers have some level of IT competence as IT is quite pervasive in their original domain of knowledge. IT is often among their primary means of labour so they acquired certain domain-specific IT knowledge along their career paths. Hence they are well set-up to think Y could solve X. Obviously the problem manifests only when they are so confident about their desired solution (or the relationship with IT is somewhat broken) that they do not articulate X. ↩
-
"IT Standards" are often specific to an industry or even internal standards created within a company. The IT industry still moves too fast for many standardization efforts. E.g. the WiFi device you buy is usually based on a to-be-approved set of standards (aka. drafts). If the company manufacturing it had waited for the standard to be approved, the market would have been made without it. In addition to that there are two patterns that make local IT standards difficult to do right: the (perceived) need to participate in IT industry trends (the cloud and big data these days) and competing standards. More on standards sometime later in another article. ↩
-
This leads to the old efficiency ("do the thing right") vs. effectiveness ("do the right thing") debate. With extensive requirements management you can become very efficient. Only sufficiently understanding the business processes and their development scenarios (business strategy) and matching relevant aspects of the IT industry (IT strategy) will (with the help of good IT architectures and sound project planning) lead to more effective business processes. ↩
Trackbacks
No Trackbacks
Comments
Display comments as Linear | Threaded