Make your requirements functional

IT projects can and often will fail to meet defined expectations. Executing a project without set business, functional and non-functional requirements can cause the failure.

James Fairhurst, director of information systems and services at insurance company Hastings Direct, recognises this scenario only too well.

“Not enough time or detail is obtained at this stage, which results in longer projects, costs going over budget and a lower quality of final product which rarely meets the expectations of the customer or the business,” he says.

For Hastings Direct, these issues have been caused partly by its exponential year-on-year growth of 123 per cent. Something had to be done to prevent its IT from stalling the growth but, as David Churchward, CIO for Azzurri Communications, explains, a standard solution is the wrong solution.

“Too many organisations look for a template for quickly assessing the potential benefits of new technology, and so they go through the wrong process, or canvass too wide audience before starting it”, says Churchward.

He argues that CIOs need to be clear about the benefits they intend to deliver their organisations. CIOs should not gather functional requirements in isolation as this can be just as dangerous as canvassing the wrong people, or too many individuals. The latter leads to a quagmire of different perceptions of what should be achieved, but this doesn’t provide anyone with a clear solution or understanding of the challenges that face the organisation.

Churchward stresses that CIOs need to define what the organisation wants to achieve up-front, and use IT in way that makes an organisation more responsive to its markets and more competitive by analysing how new technology can help them achieve their ambitions.

Best practice usually involves adopting a mixture of approaches, including back-to-basics observations that work well with business process re-engineering. This can be achieved by talking to a focused audience of key stakeholders, even involving the CFO so CIOs can show where they can deliver cost savings.

Brainstorming sessions to discover where any systems enhancements can be made are recommended. But firm roles for business analysts and project managers in eliciting and documenting functional requirements must be set out. Having the guidance of someone with functional analysis skills and experience will ensure that this heads in the right direction.

Marque Staneluis, senior director of technology product development at DNAinfo.com agrees. “Project management is about making sure the trains run on time, and a project has so much more to it than this,” he says.

“If you don’t engage with the business needs of the client based on the reality of technology and ROI results, then getting the project done on time and under budget will be meaningless.”

Joseph Bachana, president and founder of digital content consultant DPCI, agrees that functional analysis and documentation best practices aren’t clearly defined for business and functional analysis. He thinks CIOs who have a well defined business and functional analysis are strategically in a better place than those that don’t as they can mobilise themselves more nimbly than their rivals.

Rob Toguri, vice president and head of BI management at Capgemini, says that project management needs to have clean and non-ambiguous outcomes. “CIOs need to look at the requirements capture techniques and approaches that utilise visualisation and prototyping,” he says.

By analysing and documenting business, functional and non-functional requirements, it is possible to achieve results like those attained by Hastings Direct. “Hastings has adopted an agile approach for both project prioritisation and software delivery, which has enabled us to run 50 per cent more projects on time and on budget in the last six months alone,” claims Fairhurst.

He says this has all been achieved with the same resources, and that it has all been possible because he focused on the required specifications from the start of the projects until the end of their lifecycle.

Churchward took Azzurri through a similar process, which enabled his firm to quickly define the deliverables and benefits of a Microsoft Dynamics CRM implementation. By thinking about what the business really needed his team was able to reduce the delivery time of six?to?nine months to just three.