I travel a lot for work. Travel, despite the implications of movement, actually involves a lot of waiting around, either in lines or in airline lounges. Waiting around with a bunch of business travellers often leads to some interesting conversations. I spend a lot of time talking about software requirements with my fellow travellers, and there’s an interesting distinction between the way that people think about requirements.
Software companies are actually pretty good at requirements. When I talk to managers of companies who sell software as part of their business, they’re generally very in tune to the necessity of having good requirements. They’re in tune to this, because if software is your living, you become good at it or you go out of business.
But lots of companies create software in support of their business, not as the core of their business. This is an interesting and fertile ground for a guy who’s trying to sell requirements consulting. The people who work for this type of company have taught me a lot about selling requirements.
These companies face a few obstacles:
1. They often (but not always) don’t get top software engineers, because top software engineers tend to like to work for top end software engineering firms. This creates a potential talent shortage in the people who are doing the development work.
2. Management in non-software companies tend to view software divisions as cost centers, not profit centers. This means that management is generally looking to try to reduce costs in these areas.
3. Management in non-software companies don’t typically understand the software development lifecycle. This means they are less willing to spend money on “weird stuff” like requirements.
4. Since software isn’t the core business, the core business is typically not crippled by late or poorly functioning software. A grocery store chain is still going to be able to sell bread even when an IT accounting project is delivered 4 months late and over budget.
5. There’s often no “culture of requirements” in these companies. They solve problems by throwing smart people at problems and hoping they get solved.
This second class of companies are generally the ones who most need the help of professional requirements engineers, because they are also the ones for which management most believes they can get by without spending money on requirements. For those trying to sell requirements services, the sales emphasis becomes working to sell ROI analyses that measure the impact of building the right software, with requirements analysis being sold as a follow-on service.