jump to navigation

Keeping Specs Updated April 16, 2012

Posted by Tim Rodgers in Communication, Process engineering, Product design, Project management, Quality.
Tags: , , , , , ,

Some time ago I listened to the manager of a firmware development group explaining his team’s reluctance to keep requirements documents up-to-date for our product’s user interface. Basically he didn’t think it was worth the time, especially when the logical flow and the look of the UI were still moving targets. “Can’t we just do the coding first and update the specs later?”

I’ve written before about my love-hate relationship with process (see ProcessĀ Conformance). I understand why people hate process. Often they think that it inhibits their creativity and makes them less flexible and agile. Generally, processes should be an enabler for greater efficiency and reliable execution, not a nuisance. When people follow the process there’s a lower cost for communication and alignment. Keeping requirements up-to-date sounds like a lot of extra work, but those documents are vital as a tool to make sure everyone understands the specs and aren’t working on an older version. The time it takes to update the specs should be balanced against the time and effort that would be wasted by not updating them or trying to communicate changes informally.

If the design team thinks they’re spending too much time updating specs, maybe they should be spending more time understanding why these changes are happening in the first place.



No comments yet — be the first.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: