Galileo turns to Accept for requirements planning
Variety is spice of life
Considering what can be involved, we all assume buying an airline ticket is a straight forward process. But for businesses like Galileo, which provides the service behind some 44,000 sale outlets worldwide, making sure that all those outlets have the latest version of the applications suite, together with any specific variations required by an individual outlet’s local market needs, can be an interesting problem, particularly in terms of managing the requirements and subsequent applications roll-out for that many sales outlets.
In terms of requirements management it is often a problem more commonly faced by ISVs, which is perhaps why Galileo turned to Accept Software. Its requirements planning tools are, according to International vice president, Chris Purrington, primarily aimed at the problems ISVs always in planning the development and delivery of new and upgraded applications.
According to Purrington, the Accept system differs from most other requirements management tools in that it can manage down to a development process feature level such as defect tracking modules. By comparison, he contends that most others only manage software portfolios down to the project level. The system works using a three-part process.
Firstly, it allows a company to build and enter into the system a strategy plan for product development that runs from the high level `road map’ down through all relevant departments in the business to a detailed level that might, for example, cover available staff skill-sets. Secondly, it is used as the repository for requirements requests coming out of both the company itself and its customers.
The third element is to compare part one above against part two above, using the in-built analytical tools. “This has the sometimes unforeseen advantage,” Purrington observed, “of identifying to a company that its strategy bears no relationship at all to what its customers want from it. Internally, it can also identify where departments within a company are pulling in different directions.”
These analytical tools, therefore, not only help in both long and shorter-term product development planning, but also help companies identify potentially expensive problem areas in the development process, before they have any real impact. In addition, they can be used to give the product planning teams the opportunity to play speculative `what if’ games with different development scenarios or schedules.
As Purrington points out, this can be taken a step further so that the requirements surrounding a potentially lucrative (but possibly business damaging) market opportunity can be exploited. This is the development of the non-standard product.
It is not unusual for a software development team to face such a problem. There can, for example, be many variations of contractu al reason for a customer-specific version of the product to be developed and rolled-out outside of scheduled release cycles. With a company like Galileo for example, with 44,000 outlets in over 130 countries, issues of localisation, legislation requirements and cultural differences have to be accommodated.
The other side of that coin is the occasion when a Major Client - you know, the ones likely to dangle contracts so fat all you can see is Porsches and big yachts – does just that about a special version of an application that is really needed `next week’.
Being able to analyse that process devoid of emotion, panic or greed is a good starting point, and Accept includes decision-making tools that can analyse such a task to give the risks, the rewards and the dependencies involved. It allows the development team to score the relationships between customer, work involved, market potential and the like to give a more objective analysis of the likely result, all set against the aggregate revenue possible.
Some companies – SAS Institute being a notable example – have a history of running annual user ballots to determine what product developments have the most demand. Though effective, this can be an expensive exercise to organise, so the ability to work with requirements requests submitted from the user community gives the Accept system what Purrington calls a 'voice of the customer'.
In fact the company can provide this capability to ISVs as an integrated portal service which can take user requirements suggestions, score them against defined criteria and output an importance valuation. An enhanced development of this is expected to appear during the summer.
Perhaps the most attractive aspect of the Accept system, particularly for small software developers, is that it is available as a hosted service for $130 per user, per month on an annual contract. A single user licence will cost $3,000, plus the cost of an associated database. ®
Sponsored: DevOps and continuous delivery