Tank You For Making Innovation Work

In the tech industry, the earlier in the innovation process a developer works, the greater the prestige. Lower in the status hierarchy are developers who work on performance and scalability issues, build integrations with other systems, handle security issues, and (heaven forfend!) help the QA team set up test environments. 

Of course, the customer has a much different set of priorities. Sure, new products and features are interesting, but their value is moot if the technology doesn't work. How many concurrent users can the system bear before it keels over? Are the big security holes plugged? Has anyone else run version 7.0.1.3 on Ubuntu 10.04? These questions determine whether a customer buys your product and how likely they are to remain a customer after they've tried to deploy it.

Remember The D In R&D
Some of the larger technology companies have decided to make a serious investment in fixing the problem. While sensitivity training might help some development teams better appreciate the contributions of some of their members ("Looks like the performance guy needs a hug!"), there's no replacement for a well-staffed, well-equipped, dedicated effort to ensuring that the technology works as advertised. Or, just as importantly, doesn't work as advertised, so that the customer knows what sort of configurations and use cases to avoid.

Read more

Shoveling Ideas Into The Requirements Engine

[Another interesting finding about the requirements tool market, from research by Yours Truly and Mary Gerush. For other observations about this very interesting market, click here and here.] 

As organizations improve their requirements practices, and as the requirements tool vendors adapt in response, the front end of the requirements process is getting a disproportionate amount of attention. Many requirements defects start early, with the information that you feed into the requirements-generating machine. For example, if you don't have a clue how criminal investigators work, you're going to make basic mistakes in feature prioritization and design when you build a case management system for them. 

And it's not just the information that has fallen under suspicion. A lot of people are equally worried about the other raw material, ideas, that you feed into this machinery. Here are a few commonly cited concerns:

Read more