RFEs - My informal tracking list

Ok so further to my previous blog entry http://grumpystorage.blogspot.com/2009/10/rfe-for-rfes.html , and in the spirit of sharing, here's my draft list of 'non-NDA' RFEs :-

EMC/NetApp/HDS/Cisco

· Ability to terminate multiple VSANs onto a single array FE port directly without needing to use IVR and/or dedicated array FE ports per VSAN

· XML interface for customer retrieval EOL/EOSL information, eg XML to complement :-

NetApp http://now.netapp.com/NOW/products/eoa/

EMC

"PowerLink -> Home > Support > Interoperability and Product Lifecycle Information > Release and End of Life Dates"

"PowerLink -> Home > Support > Interoperability and Product Lifecycle Information > Documentum and Former Legato Product Information"

· XML interface & client for 3rd party interop matrix status and updates, eg to complement :-

NetApp http://now.netapp.com/matrix/ http://now.netapp.com/NOW/products/interoperability/

EMC

"PowerLink -> Home > Support > Interoperability and Product Lifecycle Information > Interoperability Matrices"

HDS http://www.hds.com/corporate/resources.html

· API / XML driven interface for licenses :-

a) To be able to remotely programmatically determine each & every licensed featured installed / not installed within the device

b) The be able to remotely programmatically determine the license metric and it’s usage for each & every licensed featured installed / not installed within the device

· API / XML driven interface for environmental impact

a) To be able to remotely programmatically determine the real time energy consumption by the asset (power etc)

b) The be able to remotely programmatically determine the high, low & average energy consumption by the asset (power etc) over a given period

IBM

· Would be very interesting to use the SVC to perform Raid5/6 over multiple arrays - to remove the array enclosure as an SPOF in a data-centre

Microsoft

· SQL Server formally & fully supporting NAS for it's database storage

· Formally & fully supporting 3rd party backup/recovery tools for it's database products

Zimbra

· Support of object storage (Castor, S3, Atmos etc)

· zBackup to operate multi-threaded and support for backup / restore of 10TB database messagestores

Caringo

· Full support for running Castor as a VMWare guest image

· Castor AWS S3 compatible API option

· Castor support for Zimbra, Sharepoint & Exchange+Enterprise Vault

· TCG SSC Oasis support

EMC

· Centera usability & readability of config reports

· SRDF & Mirrorview replication inbuilt cross compatibility

· Ability for SRDF sync replication with delayed updated at remote site

· Atmos support for Zimbra, Sharepoint & Exchange+Enterprise Vault

· Atmos support for an AWS S3 compatible API option

· Networker full support of Atmos as target

· TCG SSC Oasis support

· Greater qty of Ethernet ports on NAS devices

· EMC Powerlink to present at least the same deployment statistics and uptime information as NetApp NOW site

a) Enhancing the current information presented at :-

"PowerLink -> Home > Support > Interoperability and Product Lifecycle Information > Storage Target Revisions and Adoption Rates"

b) To include by product, by firmware release :-

Release Date

Number of customer systems currently running this release

Number of customer sites currently running this release

Average run-time days per system

Qty of issues, by severity

c) To make the following additional information also available via an XML interface :-

Product major & minor (eg DMX & 4), Code Name, Code Rev, Release Date, # or % product running this release, # or % sites running this release, Average up-time, Target / Recommended Release

HDS

· To have an equivalent of EMC PowerLink or NetApp Now for self-support and information access

· API reporting of hot-spare qtys correctly on USP range

· API alert reporting for service processor utilisation on AMS range

· Ability for sync replication with delayed updated at remote site

· TCG SSC Oasis support

· Support for Thin-Provisioing in USP-1100

NetApp

· TCG SSC Oasis support

· Release the software only variant of OnTap as a commercial product (capacity limited if needs be)

· Greater qty of Ethernet ports on NAS devices

· Much larger aggregate & flexvol capacity sizes without having to upgrade to v8

· Support for OnTap v7.3 & v8 on older generation equipment and also for newer products (eg 2020 & 2050)

· Support for native OnTap 'in box' tiering of a file-system over multiple disk types (eg to support FAN)

Cisco

· 'terminal release' concept for SANos (check current name) - where support partners must converge upon a certainly release variant within X months (to aid interop)

Twidroid

· To have a "eMail tweet" (inc URL to tweet) that integrates with your google mail account

· To have a "Reply All" option against each tweet

· TwidroidPro posts to be 'sent from' TwidroidPro rather than just 'Twidroid'

· To correctly support Androids 'select & hold' ability to correct default spell-check suggestions

TweetDeck

· eMail tweet to include URL to tweet

· Option to save state of currently 'in memory' tweets upon shutdown, and reload upon restart (I'd pay for this feature alone)

· UK spellchecker

· Ability to set frequency of refresh of searches (in similar fashion to DMs, Mentions etc)

Snarfer

· An update to code?

· Better support for database store to prevent / fix corruption

An RFE for RFEs

In this brief blog I'd like to discuss the topic of product RFEs (Requests For Enhancements) - now as far as I'm concerned this is very much one of the most ignored and abused topic areas of the customer / supplier relationship.

Some tiny examples :-

• One supplier I know took 4 years to process an RFE that they admitted was both useful and easy to do, but somehow it never quite made the development release train - and nobody could explain why.
• Another recently updated their internal RFE system, and in the process simple deleted the details of all previous RFE requests
• With one supplier I have at least 3 different ways that I'm required to register RFEs - as the method is different for each product (but feels like it's totally random)
  
• Heck, at the time of writing, even the mighty WikiPedia doesn't have an definition for RFE http://en.wikipedia.org/wiki/Request_for_enhancement !!

Frankly the status of RFE management staggers me. In @SteveTodd's recent book Innovate with Influence he quite rightly points out that a lot of innovation comes from customer demand - and yet for many vendors the method for accessing and capturing the customer requests is opaque, fragmented and often best described as broken.

Suppliers rarely seem to demonstrate they include consideration for a product's existing customer RFE lists when designing next generation products - this may occur but the communication & dialogue with the customer is sporadic and often after the next product has been 'feature locked'.

The process seems to be normally 'handled' by the local technical representative on the account, resulting in a lot of human processes & resource consumption, interpretations, delays (always dropping down the priority list), difficulties for global orgs (customers & vendors) to align on RFE priorities etc. Thus sorting this out will not only help get (some of) the right features progressed in the right timeframes, but should also save both parties money due to less people effort associated with the 'process'.

Some simple things here could make a big difference, for instance :-

• Operating the RFE handling under a clear process and SLA
  
• Publishing a document explaining the process and SLA
  
• Using a standard electronic template for information capture
• Having a common format for agreeing & valuing the benefit and priority to both customer and supplier
• Understanding that it's key to have regular communication and update on the status of the RFE
• Committing to a finite time-line for a decision (ie yes now, yes future, possible, private funding, never etc)
  

Of course, exactly the same comments and disappointments exist for most vendor's Interop & RFQ (Request For Qualification) handling as well - some key additional points that would help here are :-

• Up-front published & consistent clarity over the information required when raising an RFQ
• Clarity over the terms & definitions of an acceptance or rejection
• Maintaining a customer accessible database of their existing RFQs so that they can be tracked over time and checked for ongoing validity, updates, being superseded, and included within support contracts
• Putting RFQs into the standard interop documents ASAP after qualification
  
• Providing a customer accessible and downloadable version of the interop matrix/documents - including maintaining customer access to historical versions (as a large number of RFQs are with older tech)
• Providing a greater level of detail within the interop documents for those products that don't have a 100% fully supported status (ie tested but failed, not tested, worked but no longer commercial support etc)

It also continues to surprise me that at vendor's customer council sessions they rarely, if ever, discuss the topic of RFEs - both process and/or content. I'd have thought these would be an ideal forum for suggestions, discussion, refinement, prioritising & voting on RFEs - I know one user forum where this happened and in effect the 30 customer companies jointly agreed on a 'prioritised top 10' RFE list for that vendor and issued it as a single entity. Surprisingly enough that list got focused work on and all the entries were completed within 6 months - a win-win for all!

The topic of more public and peer reviewable RFE lists certainly intrigues me - again most vendors have online web portals of some description for their support forums, yet rarely do they allow customers to view, comment & contribute on RFEs. The exception appears to be some of the newer/smaller companies, who make use of web technologies to perform this. One such technology is http://uservoice.com/ which allows customers to submit, comment/refine, and vote for RFEs - a perfect example being the RFE list for tweetdeck at http://tweetdeck.uservoice.com/pages/1192-general Once again my question is why major vendors don't make use of such simple and positive customer engagement methods?

Yes there is a danger of 'shiny bauble' syndrome, or indeed 'vendor bashing' with RFEs - but if managed and facilitated well, with the right people, then this really is an area that massive strides can be made in short periods of time.

Yes of course there are some interesting areas re IPR ownership, but they tend to be handle by the inter-company framework agreements, or for smaller relationships the terms & conditions etc.

Naturally this is also regularly overlooked in the TCO/ROI cost and benefit calculations - and anybody that's had RFEs eaten by the 'chaos demons' or RPQs impacted by the 'time-delay elves' would certainly agree that there are costs & benefits to be measured here!

Now show me a supplier that openly promotes and communicates a single RFE (& RPQ) process, with user self-serve & transparent status checking and that operates under an SLA - and I'll be a very happy man waving purchase orders!