Requirements at the wrong level of detail

[This is a repost of my 30 Nov 2012 post on Intelink-U]

I just got tasked to review and comment on the UCR 2013. (That’s “Unified Capabilities Requirements 2013”, for the uninitiated.)

It’s 916 pages. I was given 2 weeks.

There is an apropos quote from the Defense Business Board report on LINKING AND STREAMLINING THE DEFENSE REQUIREMENTS, ACQUISITION, AND BUDGET PROCESSES:

Another needed change is common documentation in all three processes and, at the same time, reducing considerably the number of pages and reviews of the common documents. An example of how the requirements process should be simplified and streamlined is found in a statement by an Air Force Vice Chief of Staff: “Our long-range bomber is a great example. The requirements document left the Air Force and in a short period there were so many additional items hung on the platform it was quickly unaffordable. The requirements document had grown to over 1000 pages. We really needed the aircraft so three senior leaders sat down and re-wrote a three page requirements document that could not be changed without the approval of the SECDEF.

(emphasis added)

The UCR 2013 draft includes a section on (i-kid-you-not) “2.16.11.3 MG Support for Mapped CAS Trunk Signaling Using H.248 Packages for MF and DTMF Trunks”. This is a problem. Why is this a problem?

It’s a problem because bad strategy pushes out good strategy. Publishing a requirements document at this level of detail obscures the fact that we do not have agreement on what UC is, nor what it should actually do, nor what characteristics the architecture should actually have, nor how we will acquire it. We can pretend that we have agreement because we’ve published 916 pages of “requirements” and an additional 414 pages of “Framework“.  And they were coordinated; and all comments were adjudicated.   But those 1330 pages of documents obscure the issue, rather than specify it, because the actual decision makers will never read them.

Moreover, having a detailed set of requirements does not actually get us to a capability. It’s like saying that by publishing the Interstate Highway standards you will suddenly have the Interstate Highway System. There is a huge gap between deciding what features you want in a car, and actually going to the dealer and buying a car.

Here’s a proposal for a new set of UC Requirements:

  1. As a Defense employee, I should be able to get a single phone number that I can route to my desk handset, my mobile phone, my home phone, and/or my hotel room, as needed.
  2. I should have a single voice mailbox that I can get my messages on from any of those devices.
  3. I should have a web console to control how my voice calls are routed.
  4. I should have a web interface to my voicemail.
  5. My voicemail should be transcribed by speech recognition.
  6. I should get notification through email or text message if I so choose.
  7. I should get notification through blinky lights on my mobile or desk handset if I so choose.
  8. I should have instant messaging that I can get on my desktop or mobile device.
  9. I should have presence service to see when other people are available.
  10. I should have a web conferencing capability.
  11. If I’m in a space that permits it, I should be able to do video teleconferencing with off-the-shelf consumer equipment.
  12. Capabilities should use industry standards so we can interface with allies and mission partners who may have other tools.

Basically, the same capabilities as Google Voice and Google Hangouts.   I don’t see how our current approach to UC gets us any closer to having the same level of service I can get for “free” on the internet.

2 thoughts on “Requirements at the wrong level of detail

  1. Kevin Sweere

    Its interesting to note that about the same time that was posted we got Google Apps for Government accredited in the Air Force (with all those capabilities provided for ~$70/person-year plus far more features, CAC-enabled, encrypted-Gmail, and far more securely), but our enterprise network folks stalled for so long on opening the firewall that our ATO/ATC expired. We could only use it outside of our NIPR network.

    Reply
    1. Dan Post author

      Kevin,

      That is tragic.

      On the upside, the new DoD CIO, Terry Halvorsen, is extremely pragmatic and forward thinking about using commercial cloud services. The time may be ripe to try again!

      Reply

Leave a Reply to Dan Cancel reply

Your email address will not be published.