The rapid emergence of highly configurable applications has changed the way that systems are designed and implemented. Nowhere is this truer than in the creation of budgeting, planning and group reporting applications where a proof of concept and prototyping approach can demonstrate the capabilities of a supplier before taking the plunge and signing contracts as well as leading to a more accurate and enduring solution. It’s an approach often favoured by suppliers such as Tagetik that operate in the performance management space helping to simplify complex application requirements. In this feature, Gary Simon, FSN’s managing editor and Tagetik have worked together to combine experience and develop the arguments for a Proof of Concept compared to more traditional methods.
Most business users are familiar with the concept of a specification for the design of a new application. It seeks to bridge the gap in understanding between end users and IT specialists by describing systems requirements, processes and functionality in familiar and accessible terms.
Over the years many organisations have developed their own methodologies for the preparation of a specification, but they are nearly always paper based and time consuming to complete. Nevertheless, committing systems requirements to paper has its advantages. For example it acts as a formal record of what the system is required to do and often forms the basis of estimating the work involved in building and implementing the final application. As a result the traditional specification often acts as the benchmark against which to measure the success of the development and the basis of contract between the end user organisation and a software vendor. But this method of approach is not universally successful or appropriate to all systems developments.
The specification is a relatively blunt instrument which on its own often fails to unearth the real capabilities of a software solution and off-loading responsibility for its preparation to third party consultants merely adds to the costs. Evaluating complex software needs a different approach based on a Proof of Concept that allows users to more readily understand and assess the value of a potential solution and the organisation behind it.
The pitfalls of the traditional functional specification.
No matter how much care is taken over the preparation of a functional specification it still has a number of drawbacks, as follows;
- However well intentioned, the use of language to describe functionality still leaves room for ambiguity and, generally, the longer the document the more susceptible it is to misunderstandings.
- It is quite challenging for users who are not well versed in IT techniques, terminology and customs to visualise the ‘look and feel’ of an application or even to understand how business rules and functions will work in practice.
- Paper based specifications are ‘unforgiving’. Amendments are difficult to incorporate and track when users change their mind and manual specifications incorporating many changes quickly become unwieldy to use.
So functional specifications are often end up being weighty documents which are time consuming to prepare, read and understand. Furthermore, when several stakeholders are involved in a development it is challenging to deliver a consensus view of what is required.
There are also drawbacks concerning software suppliers and their ability to respond realistically and accurately without an in-depth understanding of the customer’s business and computing environment. Brief or standardised answers to poorly crafted questions provide little insight into how a solution might work in practice or the degree to which the requirements have been digested and understood.
Perhaps the biggest limitation of the traditional functional specification is that it is not suitable for all circumstances, especially packaged software solutions or where requirements are fluid and difficult to pin down.
Almost by definition, a software package, for example, a consolidation or budgeting application incorporates considerable know-how and functionality drawn from a wide range of user experiences. Therefore a packaged application will invariably have a high ‘degree of fit’ (usually in excess of 80 percent) with an organisation’s requirements. In these circumstances, provided there are no major omissions or stumbling blocks, work should concentrate on configuring the fringes of the application; i.e. remaining 20 percent, rather than wasting effort seeking to define what is already available. So is there a better way?
Rapid Application Development – prototyping
Prototyping is a form of Rapid Application Development (RAD) designed to accelerate the development of a new applications over traditional paper based methods. But prototyping a “Proof of Concept” can also be used to quickly evaluate whether a new application is suitable, i.e. whether it can meet the users’ needs before committing to a contract.
A Proof of Concept, as the name suggests is building a trial application – something that is a close approximation to the final deliverable but without the finishing touches. As such it provides a good insight into whether a packaged application can cope with the functional requirements of the user organisation without the effort of preparing a paper based functional specification.
But there are some more subtle advantages of a Proof of Concept that are impossible to glean from the more traditional specification. The evaluation of a supplier is not only about its ability to deliver a working solution but also about how quickly it is able to understand the business, its industry, accounting requirements and special needs. The process of developing a Proof of Concept, provides deep insights into a potential supplier’s broader capabilities, its resourcing and the domain expertise of the people likely to be engaged in working with the end user organisation.
Approaching a Proof of Concept
The Proof of Concept is a serious endeavour – extracting the value requires commitment on both sides. For example, the supplier has to commit pre-sales resources and consultants to build the system and to develop an understanding of the requirements with the users. On the other hand, the users have to commit to describing their required processes and functional requirements as well as preparing realistic data with which to populate and test the prototype system.
A Proof of Concept is normally an intensive project squeezed into a few days or weeks, with workshops providing a practical environment for working through the issues, discussing how to handle complex or idiosyncratic areas of functionality and making design choices.
But the effort is well worthwhile and the benefits of a Proof of Concept are compelling, for example;
- The users can see what the final application might look like and experience firsthand how they might work with relevant data in their particular setting.
- Areas of misunderstanding between supplier and user are easier to identify and correct.
- Users become very familiar with the way the package is constructed and can therefore determine whether there is a high degree of fit and the ease and speed with which the package can be configured and any additional requirements can be met.
- Users can familiarise themselves with the user interface, reporting and queries – something that would be difficult to envisage relying on a paper- bound specification.
- With more than one CPM process under review a Proof of Concept can highlight the relationship between different elements of the solution and how well they work together in an integrated solution.
Finally, the users can get a feel for the culture of the supplier organisation they might be working with, their level of expertise, the approachability of their staff and their level of commitment to success.
This contrasts very favourably with the normal approach based on a standardised demonstration. The Proof of Concept allows users to really ‘get under the bonnet’ of the system to view and understand the workings of the ‘engine’ rather than relying on a demonstration that glosses over the detail and merely shows the most fancy or appealing parts of the system.
The speed with which a Proof of Concept is completed can also be very telling. Procrastination and delay at this stage often indicates that the live project could be a difficult and drawn out affair. But what if the supplier will not commit to a Proof of Concept at all? Not all suppliers are enthusiastic about agreeing to a Proof of Concept - it does after all require significant effort, knowledgeable resources and a flexible system. It is often said that the relationship between supplier and customer is never better than during the ‘honeymoon’ period, so if the supplier displays less than 100 percent commitment at this stage then some may take the view that circumstances are unlikely to change for the better after a contract is signed.
Concluding a Proof of Concept
Not all Proof of Concept systems are transformed into the final application. The Proof of Concept is of course conceptual - a journey of discovery and almost by definition iterative in design. The final concept may have been better designed if everything that was discovered during the build phase had been known at the outset. So users should not be afraid to redevelop the application taking advantage of everything learned during the prototyping phase. After all, the Proof of Concept should have demonstrated how rapidly the application could be developed. Additionally, by this stage the capabilities of the supplier organisation should be well understood. Provided the supplier has come through the evaluation of the Proof of Concept with flying colours then both organisations should be able to proceed with confidence.
