Access Keys:
Skip to content (Access Key - 0)

Tourplan – Product Development Philosophy

This paper is intended to help your understanding of the methodology behind the Tourplan Product Development process. If you are a Tourplan user, this is important in setting an appropriate level of expectation of what is achievable and realistic when you request changes or enhancements to Tourplan, and to appreciate how the system evolves, develops and improves over time. If you are a member of the Tourplan support team, this is important information toward you understanding how you can best contribute to the development process, and advise and guide Tourplan users accordingly.

Tourplan is built based on User Input

That is correct, and Tourplan would never be here today, nor be the powerful system of choice for so many of the world's leading Tour Operators and Travel Wholesalers had it been dreamed up, or enhanced in isolation of the users of the system. User Input continues to be a key input into the forward development strategy and decision making, but several factors need to be taken into consideration:

Good Ideas

A "good idea" in terms of how Tourplan may be improved is valuable input for everyone using or involved with Tourplan. Good ideas need to be qualified:

  • Are they a good idea because the contributor is new to the system and doesn't yet understand the other bits of the system that will make this not such a good idea longer term? versus, fresh eyes viewing the system for the first time can pick up obvious inefficiencies that a more experienced user will stop seeing over time.
  • Are they a good idea because they just make it easier to implement quickly, as opposed to more beneficial longer term business process changes?
  • Are they a good idea when we look at the mid or longer term development of the business?

General Benefit

One qualification of good ideas is its ability to benefit a number of Tourplan users. If it will do so, then it is generally a good idea. If it will benefit all Tourplan users, then it is almost certainly a good idea. Often we are able to link related ideas into a single development that then becomes of greater general benefit.


Unfortunately many good ideas fall short of a critical mass of general benefit when compared to the cost of implementing the idea. "Cost" is a many faceted thing. There is the analysis and development time, but often overlooked are things like

  • the risk factor – the likelihood that this may cost much more downstream damage because it is a change in a critical area that may result in a bug, or may result in functionality unwanted by other users.
  • documentation, training and general maintenance of the feature are often far more expensive items over time than the pure development cost.


Usually the best upgrades are those that achieve very little other than a cosmetic makeover. Why is this? – Generally the majority of users don't have serious new feature requirements just want small productivity enhancements from upgrades, without major functionality changes. Major functionality change, even if providing more efficiency, goes hand in hand with retraining, potentially additional data setup etc. Of course there are users who want the big changes, so a balance between the needs of both types of expectation needs to be kept.


Ultimately it is in everyone's interests for a large group to participate in an upgrade so the costs and experience is shared across the group, and a healthy critical mass exists to take that version forward. Ensuring broad user participation is a goal that is in everyones interests, and therefore may dictate why one good idea is favoured over another.


Many hundreds of potential good ideas emerge every year. That is of great benefit to everyone to have so much participation and input into product direction, and that input is highly valuable to us. The elements above provide an indication of some of the criteria that guide our decisions over which of the items submitted are genuinely good ideas for a particular release. Yet we typically still end up with too many good ideas for the good of a release, either in terms of how long it would take to implement, or the level of change the aggregation of changes would create between versions. So we need a further process (see PDSC below) to take the distillation of ideas through to the subset that will make the actual release.


Product defects are not subject to the criteria described here, and have their own fast track through the development methodology based on their severity.


Long term and Short term scheduling

Often we are asked something like "when will my feature xyz be available". Well, first feature xyz has to pass the "good ideas" tests above, which could happen any time the "cred list" is reviewed – typically every 6 months. Then, feature xyz has to pass another phase, the "scheduling process". Scheduling has some characteristics that are important to appreciate. Long term scheduling involves detailing what will be coming out in the product in 18-36 months. There are benefits to everyone in this – you, the user, know what is coming out in a new version, so you can plan for it, you know if your feature xyz is or isn't incorporated, and the developers, documenters, trainers and QA team have a scheduled they can plan their workflows around.
This sounds great, except that the Travel and Tourism industry, particularly at this point in time, is a dynamic and rapidly evolving one. That means changes are happening constantly. To lock ourselves into a development path fixed for 18 months to 3 years ahead would be to condemn us to be unable to respond to new requirements and features except to say they will be considered and may become available in two-four years. That's too late for most users.
Clearly a balance is required, but unfortunately it's not as simple as scheduling some items long term and leaving floating gaps for others. In practice, the gaps are always quickly filled but the philosophy breeds the expectations that there is always room for feature xyz, and unfulfilled expectations are worse than no expectation.
In practice the balance between Long term and Short term scheduling is dependent on the state of the system at any point in time - some cycles yield a wealth of new features, which subsequently require a fairly quick follow-up release to get the most out of the new features with second phase enhancements and amendments, at other times legislative or industry wide changes dictate the pace and necessary forward planning, through to the ultimate mandated types of forward planning such as the Year 2000, or new version of Windows or SQL types of forced issues. With a very stable and solid product we are often loathe to change and can indulge in a longer term scheduling program, allowing ofr a greater depth and breadth of features to be introduced.
Rather than exist as policy, such decisions are necessarily made according to the industry and product context at any point in time, and ultimately to everyones benefit in establishing the appropriate mix of flexibility with ability to plan longer term.

The scheduling process

Once or twice a year a meeting of Tourplan's "Product Development Steering Committee" (PDSC) is held. Prior to each meeting, advance material is prepared and submitted gathered across all geographic and business dimensions of the current and future Tourplan user base. The PDSC assimilate this input, schedules development, plans resource requirements, and produces a product roadmap.

Operational Offices





  • Pacific

Product Development Steering Committee



  • UK



  • Southern Africa




  • Asia



Investment and Resource Requirements

  • Latin America



Technical Services




Core Development




Tourplan Application Services


Product Roadmap

Strategic Sites




Strategic Relationships




Sales & Marketing




THL Board Directives




Alongside the "good Ideas" framework discussed above and established through your input, and operational offices and technical services qualification, a number of other factors need to be considered. These are typically the longer range strategic issues, such as technology platform changes, or underlying database performance enhancements. There are a number of background, robustness, future proofing types of driver that are additional competitors for developmental scheduling. In addition, any product defects are fast tracked into the schedule. The PDSC is responsible to blend all input and drivers into a cohesive forward product plan acceptable to Tourplan users and to Tourplan internally, spanning short, medium and long term business objectives of all parties. A simple task involving a few compromises

Package methodology

Sometimes customers come from a bespoke environment, where their previous system typically "cost a fortune" to maintain, "but if I want something done I pay for it and it gets done". It's important to distinguish between that bespoke environment and Tourplan's package development methodology.
Fundamentally Tourplan have to act as the keepers of the Software, act as a shared development resource to many users, and try to please everyone as much of the time as possible. Some of the issues discussed in previous sections highlight the complexities. The short term attraction of doing something, because someone is willing to pay "whatever it takes", is not of long term benefit, and not something Tourplan is typically willing to undertake unless that item falls into the "genuinely good ideas" basket, and fits in with the current scheduling and release cycles.
This can be frustrating, particularly for those used to the bespoke environment, but those frustrations have to be traded off against the benefits of having a packaged solution of the breadth and depth of Tourplan.

Future Directions

Tourplan recognizes that its success – over 370 companies using Tourplan across 70 countries globally – is a unique recommendation for the system, but also places constraints on product development. Small changes can have dramatic effects when multiplied across the user base, what is right in one part of the world can be wrong in another, different groups of users have different priorities and needs to others, and ultimately this constrains our flexibility and our ability to meet individual company needs.
As another measure of success of the core system, our user base has broadened from our traditional Inbound Tour Operators to a mixture of inbound, outbound wholesalers and retailers, domestic call centre base operations and a rapidly growing group of predominantly online wholesale and retail travel and reservation businesses. While the broader range of business models we support provides flexibility within the product, we must be careful in ensuring our focus and specialization in specific business areas of the industry is preserved.
Tourplan will remain a specialized, elite product, with the largest worldwide user base of any comparable company. Meeting the challenges of flexibility to address individual company needs, while preserving broad industry contextual relevance is a key design factor behind all our forward direction.
Web, web services, all Internet and online interfaces are already highly customisable and ever expanding to be able to integrate with more and more core Tourplan business logic.
Core product development and cycles will be split into two user groups – the more traditional inbound focus, where efficiency gains and supplier system connectivity are primary drivers, and the outbound focus where dynamic packaging, CRM and online retailing dominate the forward strategies.
Development and release cycles will be tailored to better meet each groups needs, with some geographic tuning occurring in this area for both groups.
So, broad brush strokes:

Tourplan Today




Tourplan Tomorrow










Specialised, customisable on-line and in-house interfaces








Specialised Inbound Product Development Strategy




"All things to all people"

Core mid/back office Services

Core Business Logic Foundation







Specialised Outbound Product Development Strategy









Specialised, customiseable on-line and in-house interfaces

We recognise the benefit of commoditization, and the downside of MacDonaldisation, the need to offer specialty services, and the need to remain cost effective. We recognize the need to grow in relevance, experience, reliability and universality. End of the day – we'll be here for you long term, in the best way possible in the climactic and commercial turmoils that herald our next twenty years in business together.