Seilevel
Seilevel Home
Back to Blog Home - Requirements Defined

Wednesday, November 01, 2006

Getting by without requirements

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.
Requirements Defined Newsletter Bookmark and Share

2 Comments:

Anonymous Anonymous said...

This blog entry certainly rings true. I have worked in several companies which at some point were trying to have new software developed to help run a portion of their business. Generally I would say individuals in teams assembled for such "special projects" were "volunteered" rather than were volunteers; which is to say such projects generally held low esteem. The project typically has all kinds of negative connotations: "time drainer", "dull", "black hole", "I don't want to be associated with something which could fail", "I don't want to be left holding the baby", etc.

I imagine most experienced business people can relate to this scenario. The challenge this poses then to the custom software development industry is how to reverse this - how can this weakness be turned into a strength? How can internal software development projects evolve from "problem child" to a high prestige career opportunity?

Many factors could contribute to this I think. One facet would be to show positive progress early - in the requirements phase in fact. Building comprehensive documents and flow charts are good rigorous practises but I wouldn't say they jump off the page, especially to observers who are not in the team. Meanwhile nothing generates staff excitement like a prototype or simulation which appears to solve a company's business headache. An early prototype which exhibits the potential to eliminate repetitive work or to enable superior service can really energize a project early on and set it on the right trajectory from the outset.

Internal software projects have such notoriously bad success rates and yet are so important to businesses that it is imperitive to maximise every opportunity which can help secure project success; sure enough, solid opportunities for this certainly occur in the project requirements defintion phase.

Regards

Richard Khan
rkhan@simunication.com

11/28/2006 2:45 PM  
Blogger Craig said...

Hi

Your post makes sense, but surely there is more project management maturity out there than that these days.

That is - businesses hire project managers to run the project through a more well planned and defined process, rather than just throwing people and money at it until it goes away.

Or am I just lucky to be in sensible companies?

4/29/2007 2:35 AM  

Post a Comment

<< Home