Integrated Requirements–Where’s The Starting Line…

Usain Bolt broke the world’s 100m record again in 2009 with a blistering 9.58 seconds. In an interview after the race, he said, “I win the race at the beginning, long before I cross the finish line.”He got out of the starting blocks in .155 seconds (less than .1 seconds is considered a fault). That’s getting out of the starting blocks in less than half the time it takes you to blink an eye (want to see if you can get out quicker? Try the NY Times Beat Bolt out of the Blocks game)

Product development is a race, too and getting out of the starting blocks right – can set up your product development project for success or failure. As Simon Ramo (that’s the R in TRW) said, “the really big mistakes on a project are made the very first day.” You start any product development race with a plan. To develop a plan, you need to understand what problem you are going to solve. This front-end of any development race includes defining who the customer is, what they need and are willing to pay for, and then deciding what the product needs to do to meet their needs. Put another way, the longer you mess around in the starting blocks or get out of the starting blocks with the wrong set of requirements, the more difficult it is to win the race against your competition. As famed management guru Peter Drucker, put it ‘there is nothing so useless as doing efficiently that which should not be done at all.”  

The question is ‘where/when the start of a project is?

Depends on the type of product you’re working on. If you work in industries like utilities, mil/aero, or build-to-order, you receive a set of requirements that you need to respond to. In that case, the start of the project is actually before you’ve won the business. If you’ve worked in these industries, you’ll probably recall war rooms with bulletin boards with storyboards, project charts, etc. around the room, working long hours, with periodic reviews to work through the response, and breathing a sigh of relief when it was out with vague feelings about your probability of winning based on how the response felt. 

Unless you started right then (or even before) to track customer requirements, you don’t have a line of sight from the customer’s voice to how you’re responding to it. That means you have to rely on fluffy stuff like opinions, past experience, and comparing yourself to the competition to judge your chance of winning. This fluffy process pushes organizations to statistical chumming philosophy/thinking in proposal responses. For example, if we win 1 out of 10 proposals, we need to respond to 100 proposals to keep the doors open—not very scientific.   

Down in Texas are these legendary high-risk individuals call ‘wildcatters’ who are willing to drop millions of dollars on a 50/50 shot on drilling an oil well. Yet here we have normally very conservative organizations blowing lots of money on a 1 in 10 shot?

Imagine a different approach, capture the RFP, parse requirements into a requirements system that is part of your Product Lifecycle Management (PLM) system (i.e., Teamcenter) and use that to link up the requirements to a standard product structure that contains a library of standard answers that have been vetted/approved/tweaked/improved thru history to move you from a war room/death march approach to a predictable response based on traceable requirements. This gives you a number of benefits besides upping your win rate:

• Moving from Ad hoc, unpredictable, mysterious proposal art to proposal science

• Changes from ‘not sure we’re saying what the customer wants’ to reflecting the customer needs (with traceability)

• Reduces proposal cost/overhead (a survey of sources—such as the Association of Proposal Management Professionals, personal experience, and Blogs on the topic puts the cost of proposal responses between 1% to 10% of the value of the contract). Reuse, automation, traceability, and collaboration can easily cut this in half.

• Moves organizations from questionable chumming-like return on investment with intense effort and dollars with little to show when it’s done to cost effective effort with accountability and traceability.

If all the really big mistakes happen on the first day, as Simon Ramo says, you need to move to keep up with customer requirements back to the first day of the project (in this case to the proposal) or even before the first day to understand the customer and have a set of standard requirement responses you can use to win the business, then once you win the business you won’t have to start over and you can get out of the starting blocks on your next project like Usain Bolt.