Transdisciplinary approach to problem solving

The Newsweek of Aug 25, 2008 featured an article on the campus of the future. Michael Crow is approaching the running of the school like a CEO would run a business. What is striking from this article is the abolishment of traditional departments and combining these functions into what he calls “transdisciplinary” institutes. His objective is to get experts in different fields to work together to solve problems by thinking outside their disciplines.  For example, the new School of Sustainability features professors from 35 disciplines!


I recently had a discussion with a local university and a similar concept was discussed. While some universities still have very strict enrollment rules per department or course, these are normally more related to preventing an administration nightmare, than truly ensuring that the candidate has adequate foundation knowledge to progress in his/her new field of study.  There are ways to navigate through these lines of study which can take a student from one field of graduate study to another field for post-graduate study. Is this regarded then as interdisciplinary, multidisciplinary, crossdisciplinary or transdisciplinary?


  • Interdisciplinary refers to professions where the traditional academic boundaries are crossed and its goal is to connect or integrate the knowledge from the different disciplines to establish knowledge in a new field of study such as in the case of geobiology. 
  • Multidisciplinary refers to joining the knowledge from different disciplines without integration. The aim here is not to establish something new but to look at the same reality from different perspectives to explain the phenomena.
  • Cross disciplinary discusses a subject in terms of another. It looks for metaphors or likeness to explain a concept or object in another language if you will, one that would be understood by someone trained in another field of study or discipline.
  • Transdisciplinary uses the multidisciplinary approach with the difference of engaging these disciplines as stakeholders in solving a problem. It is not only viewing the reality from different perspectives to explain why the reality is such but is actually working together to overcome a problem without integrating the individual disciplines knowledge.
Given the descriptions above I would say that Transdisciplinary best describes the ideal approach to Revenue Assurance. Are there different views?
Güera Romo
Güera Romo
Güera has many years of experience in business transformation in the engineering, defense, government, banking and telecommunication industries. She has experience in mergers & acquisition, rightsizing, re-deployment of personnel, business process re-engineering, system selection and implementation.   Güera holds a BCom Hon (Industrial and Organizational Psychology) degree and is currently pursuing a doctorate that draws on her practical experience of developing human resource capabilities within large corporations.

3 Comments on "Transdisciplinary approach to problem solving"

  1. Hi Güera,

    I completely agree with you that RA should be transdisciplinary if it is to really succeed. There is one problem with that: people will have to respect disciplines that are not their own. IMO, the worst obstacle will come from the software guys – and the guys who make money from software. They have a strong vested interest to reduce RA to its most tangible and reproducibly profitable elements, and to turn everything else into a superficial dressing around that. Just look at how many software companies have jumped on to the consulting/standards/best practice bandwagon – so long as none of these interfere with the sales of the software. A transdiscipline approach might suggest alternative methods of solving problems to the routine answer of yet more software (much like the suggestions made by Dave each week). It also may pose problem for the software guys. There is nothing they hate more than a list of requirements they cannot satisfy. A transdisciplinary approach will inevitably encourage objectives to be identified and requirements to be suggested that may highlight shortcomings of current software. These may not be just shortcomings with current software, but may reflect the fact that the best, cheapest and quickest solutions may not involve software.

    Do not get me wrong, as there are plenty of good guys who work in software, not least my fellow talkRA authors. There are many who understand how software sits in a wider context, and is not an end in itself. But commercial realities – the need to satisfy VC backers and shareholders – will exert a strong influence. The best way to balance that is to ensure the software guys are not given freedom to set the RA agenda alone. Instead, we must all encourage the other disciplines to each articulate their own priorities, and how they need to improve the integration of their discipline within an RA context.

    Here is a radical thought (feel free to ignore it, if it is too ambitious). You, Güera, are a respected individual with a lot of credibility across many of the disciplines needed for transdisciplinary RA. You have a sophisticated point of view about which disciplines need to be engaged. You have a strong network of contacts. I have no affection for undemocratic and self-appointed committees, but perhaps you could suggest, or even sound out, an informal collective of “elders” or “wise persons” to guide the debate on transdisciplinary RA? The collective would include one person for each discipline, and their first task would be to rough out a schema of how the disciplines do, could and should work together.

  2. This is a very interesting idea, and let me start off by saying that I support the transdisciplinary approach. In a standard RA opportunity, there are multiple stake-holders involved, some from the Telco’s IT team who are interested in say :

    a) Proper File Sequence generations
    b) Trending of xdr generation
    c) File/Record corruption issues

    Then there would be people from the finance teams who would go with :

    a) Ledger reconciliations
    b) Voucher Balance checks
    c) Closing balance vs Opening balance checks

    Then there are people from the RA team who seem to be in sync with mediation teams, for they want to check :

    a) Suspense/Error reasons
    b) Filtering based on business rules
    c) CDR Tracking from generation to billing

    What I’m trying to say is that, as soon as I hear the requirement, I’m usually able to identify which team that particular person belongs to. And I for one, welcome this. For a software vendor, it is critical to not just deploy a product, but the deployment needs to be catering to a wide audience, since RA cannot be pegged down to only IT or Finance. RA is inherently transdisciplinary.

    I do totally agree with Eric when he says that a software is not an end in itself, but merely the means to an end. For a good deployment, there is a serious need to understand what the telco is striving to achieve, and the software is but a vehicle to take him from where he is now, to where he hopes to be. But like any vehicle, it needs gas…and it needs a driver. The people deploying a solution should have a deep understanding of the core principles of RA. RA was not conceived as a network monitoring system, but you’ll see examples where the RA tool is essentially used to check for minor technical faults. RA was not conceived as a DSS/Reporting tool either. Most importantly, the “driver” is essentially a vision of what the RA exercise is meant to achieve.

    A good RA implementation factors into it a 360 degree view of the network. It should cater to the IT guys, the Finance guys and whatever other team is involved, for, like Guera mentioned earlier, its about perspective. An IT guy might be looking at missing file sequences to fix a technical issue, but the repercussion for the finance guy is that he/she might be losing an entire file of billable xdrs.

    I doubt anyone would disagree that RA is transdisciplinary. Now the challenge is to seamlessly integrate all the different perspectives into a focused approach which is both clear and comprehensive.

  3. Hi Eric, Ashwin,

    You both touched on the need to integrate the various perspectives of this transdisciplinary view of RA and that is precisely what the research study aims to achieve.

    This you can imagine is no small feat. Not only is time a limiting factor but the quality and quantity of useful debate seriously inadequate. I have been testing various approaches to elicit such input and will up the game a notch.

    The good news is that the university likes the study and I have grown enough patience to navigate through the enrollment procedures, hectic consulting schedule and quiet time to think out the next research facilitation questions.

    I hear you both on the software development perspective of RA and acknowledge that it has influence greatly where RA is today. I would leverage off that knowledge and if the research findings were to step on toes, I hope to do so gracefully :)

Comments are closed.