Our Approach

Application software vendors traditionally adopt prescriptive methodologies for software implementation, taking a top-down approach to project management, business process and requirements definition by establishing a command-and-control system. The underlying assumption is that with enough planning and management the outcome can be predicted and risks avoided. These methodologies are most effective in situations where the customer's business and requirements will remain fairly static.

For an increasing number of software implementation projects, however, prescriptive methods provide neither the flexibility nor the speed-to-market that organisations require. Too often, the end result is a huge set of documentation that collects dust on a manager's shelf that is a far cry from what actually happens in the workplace.This approach is commonly refered to as the 'waterfall' methodology.

In contrast to the 'waterfall' methodology, software developers developed a light approach entitled the 'Agile' methodology and refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation, a leadership philosophy that encourages teamwork, self-organization and accountability, a set of engineering best practices intended to allow for rapid delivery of high-quality software, and a business approach that aligns development with customer needs and company goals. This approach is well suited to the development of software from scratch or the development of, say, a website where it starts with a blank canvas. However it is not suitable for the implementation of a mission critical application such as an ERP system.

Implementation Methodology

The Adaxa methodology combines elements of both 'waterfall' and 'agile'. A mission critical application will have a substantial number of inalienable requirements and these are not subject to an 'iterative design' approach. Most organizations will need to purchase goods from suppliers, ensure that the goods have been received at the agreed price and remit funds to pay for the goods received. There may well be slight variations in the process from organization to organization but the process will of necessity have to acheive certain well understood outcomes. There is little or no point in trying to go through some iterative approach to redefine the fundamentals of the process. However, there will be some business processes that will benefit from a progressive (or iterative) approach to their ongoing development and refinement and it is necessary to define those processes and determine if an iterative process will be appropriate.

In Adaxa's methodology these decisions are made during a 'Conference Room Pilot' which is a process of discovery to produce a 'gap analysis' between the application functionality and the organization's requirements. This forms the basis of an understanding of what can be implemented without change and what extensions or modifications are required to the application prior to its deployment in production and therefore drives the project implementation.

The focus of this approach is to ensure that end users see the application right from the start. They are involved in the process of ensuring it fits their requirements and are involved in the inevitable decisions that have to be made about the most appropriate way to configure and deploy the application throughout the implementation process. This ensures that ‘change management’ is something that they are involved in rather than having thrust upon them.

Furthermore, close communication between the supplier and the end user enables them to play a part in the implementation activities. This leads to a reduction in the overall costs of implementation so that work better performed by staff in the organization is done by them rather than external consultants.

Development Methodology

Where possible, and typically in web development projects, Adaxa adopts an 'agile' approach:

• Light methodologies are adaptive rather than predictive - heavy methods tend to plan out a large part of the implementation process in great detail over a long span of time. This works well until things change and the nature of vendors adopting such an approach is to resist change. The light methods, however, welcome change. They are processes that adapt to and thrive on change, even to the point of changing themselves.
• Light methods are people-oriented rather than process-oriented - they explicitly make a point of trying to work with peoples' nature rather than against them and to emphasise that the implementation of new business solutions should be an enjoyable activity rather than a threatening one.

This light approach starts by documenting as much or as little of the requirements as the organisation wishes to do. Typically an organisation is not able to articulate its requirements in detail and the requirements document may consist of as little as one or two pages of broad requirements. Better still the approach starts with the installation of the application software and a 'conference room pilot' to walk through the relevant business processes with the appropriate end users and the application software that is to be implemented.

For more information...