When buying a commercial app or working with a vendor to create one from scratch, organizations are specifying too many requirements, including ones that are non-essential or cosmetic. According to one Info-Tech Research Group Ltd. consultant, the key to successfully selecting a vendor for packaged or custom applications is to identify core requirements quickly and keep the initial selection team small.
“If you have a team of more than five people who are commissioned with finding the right solution and requirements, you’re probably wasting a lot of effort,” said Andy Woyzbun, lead analyst at London, Ont.-based research and consultant firm. Especially for customized projects, design by large committee almost never works, he added.
While some organizations gather staff from across multiple departments to work through all aspects of a project — from the initial requirements gather project through to vendor selection — Woyzbun warned that this practice will cause most companies to miss the essentials.
“Don’t sweat the details until you’re well into the development process,” he advised, adding that it’s a far better strategy to select a vendor or develop a set of key project requirements without wasting too much staff time outside of the initial development team.
Bringing in employees from various departments is great to validate what’s been chosen and what features can be added on top of the core functionality of an application, he said.
For example, when building out a payroll system, some employees might want to see customizable fields and fonts show up on their pay stubs. While this is something that should be taken into consideration for the latter stages of the project, the focus of the payroll system needs to be on its core features.
“Don’t worry about the colours of the walls before you’ve bought the house,” Woyzbun said, adding that the companies he’s worked with tend to “overcook” their requirements and the vendor selection process in general. This is especially true on large ERP, CRM, or business intelligence initiatives, he said.
The organizations that keep their requirements teams small and zero in on key objections will waste the least money and get a usable product turned around quicker, Woyzbun said.
This advice comes just one month after New Castle, Del.-based software development consultancy IAG Consulting found that the average North American enterprise wastes 33 per cent of their budget on app projects due to immature requirements definition. The firm polled CIOs, IT managers, and business analysts at more than 400 medium-to-large organizations.
“We’ve found that it doesn’t really matter what development methodology you choose — agile, iterative, or whatever — what matters is how you look at the requirements maturity behind it,” Keith Ellis, the study’s author and a vice president with IAG Consulting, said last month.
The research, according to Ellis, indicated that lower-skilled business analysts in higher maturity companies consistently outperformed higher-skilled ones in less mature organizations. “This shows that more important than individual people and individual skills, it’s the collective capability that you need to focus on,” he said.
Developing a proper maturity model framework that covers areas such as staff competency, organizational support, stakeholder communication, and project timeliness is the key in leaving project failures behind, Ellis said.