By: Jeffrey Phillips
Marlowe gathers the Accipiter executives to sit in on enthusiastic open innovation software demonstrations. Will the team arrive at the necessary conclusions about their innovation community?
We’d assembled a team of Accipiter executives to sit in on software demonstrations from three software vendors. In this we followed the usual software demonstration mantra, which is to tell the vendor as little as possible about our needs and goals, and invite a number of corporate executives to watch software black belts demonstrate the ten thousand things their software could do exceedingly well, whether we needed the functions or not. Then, we’d decide which software we liked based on the colors of the screen, the nicest sales person or a feature that became important during the demo. In other words, we’d failed to gain consensus on what the software should do, so rather than script the demo for the software vendors, we simply asked them to show us the software they had for innovation communities. The demonstrations gave the term “dog and pony” a completely new meaning.
Don’t get me wrong, I think the software guys were very enthusiastic and doing what we asked them to do. They trotted out their wares and demo’d software like a Benihana chef at a hot griddle. Some Accipiter executives seemed vaguely uncomfortable during the demos. I suspect it was motion sickness from the speed the screens flew by. Since we couldn’t offer any specific instruction about what we wanted the community to do, we gave carte blanche to the software guys to strut their stuff. And did they ever.
After the demo was over, several executives hustled out to another meeting without a backwards glance. I suspect they weren’t sure why they were there in the first place, and were making a quick get away to keep from having to submit an opinion. All remaining eyes turned to Frank and Thomas, the token IT representatives. Bill fired the first salvo.
“Well Frank, what do you think?”
Frank, as the CIO, had a number of opinions about software, mostly related to the challenges he faced with existing infrastructure and trying to keep the number of technologies his team had to master under control.
“Bill, as we’ve discussed before, we can support any Java-based application that is deployed internally and uses IIS and SQL Server. Those are the baseline requirements. It would be great if the application can link to Active Directory so we reduce user management issues. Whatever your team decides to implement will need to go through a validation test, and I’d suggest a short internal pilot. Other than that, I don’t know that we have a strong opinion about these applications.”
“What did you think of the functionality? Does it appear to be something that would be easy to maintain, and easy for the team to learn and use?”
“That’s really a question for your users and your trainers. Most of these applications are relatively simple to configure, and seem to have enough APIs and extensions to allow us to link this to our intranet or perhaps share data with other systems, but I don’t know if that’s important to your team.”
“OK, what if we want to invite customers or business partners to use the application?”
“Again, I can’t speak to the functionality – all of these applications seem to allow internal or external users to enter ideas, rank them and comment on them. I guess my chief concerns when we talk about external users are user management and data security. How many users are we talking about? What requirements do we place on them? How do we ensure that they don’t submit a Trojan Horse or try to inject a virus on the community? If you are going to invite external customers or users to the system, then we’ll need to consider carefully where we host this – it will probably need to be in the DMZ, outside of our firewall.”
“That’s to protect other internal systems?”
“Yep. If we allow external users inside the firewall, we place all of our IT resources and data at escalated risk. Also, you’re going to need to think carefully about monitoring the community, to ensure we identify and eliminate flames, derogatory comments, foul language and so forth. We may even need to identify and block individuals or certain IP addresses if we suspect they are trying to penetrate the system or are simply disrupting the community.”
“OK. Anything else?”
“Who is going to maintain the community?”
At this point Susan jumped in. “I will be responsible for day to day maintenance and engagement with the community” she said.
“How many users do you anticipate? How many ideas? We need to get a sense of the usage and the anticipated growth of the system.”
Susan turned to me, and I gave her one of those one shoulder shrugs which signals that I don’t know and you’re on your own. She frowned.
“We don’t know that yet. We still have to decide the overall purpose and framework for the community and who we’ll invite. That will drive the number of users and potential growth.”
“So right now you don’t really have a set of requirements for the community, other than it must be hosted internally and potentially incorporate external customers or prospects who can submit ideas?”
Now it was Susan with the one shoulder shrug. “That’s about it so far.”
“OK, that explains the dog and pony we got today. Could I make a suggestion?”
“Write up a script to have them demo exactly what we want to do?”
“Well, yes.”
“We’re working on that. To a certain extent we are trying to learn about communities as we see a number of them demonstrated to us. Once we’ve seen a few and what the vendors can offer, I think we’ll be more intelligent about what we want.”
I think she almost believed that, but she fell on the sword nicely. Bill had suddenly become preoccupied with his notepad and Frank understood what he had stepped in.
“OK. When’s the next three ring circus?”
“We have another demo tomorrow at the same time. We can use this conference room.”
Frank and Thomas rose to leave. “We’ll be here. I’ll have Thomas draw up a set of minimum requirements for the software to help us rule out any that conflict with our existing investments or require learning new technologies.”
“Thanks.”
It was down to just me, Susan and Bill at this point. Bill glanced around, looking for all the world like a politician just caught with his hand in a donor’s cookie jar.
“I see we need to do a better job of defining what we want the community to do. Sam, Susan, draft a ‘going in” position that defines the community as an open community that any customer or prospect can use to submit ideas. We’ll want to categorize the ideas and align the categories to our lines of business or products. That way we can link the ideas to our product lines. We’ll need a way to communicate with the submitters, so we’ll need an email address. We’ll also need to think about reporting, and rewards for those who submit ideas we accept for further investigation. Draw up a short presentation and have it for me to review by Friday.”
Having heard, reacted and commanded, he rose, turned quickly and left the room, never admitting that we’d be right all along. I guess one of the criteria for rising to his level was recognizing but not admitting you were wrong, and quickly correcting the error before anyone else discovered it.
About the author:
Jeffrey Phillips is VP Marketing and a lead consultant for OVO Innovation. Jeffrey has led innovation projects for Fortune 5000 firms, academic institutions and not-for=profits based on OVO Innovation’s Innovate on Purpose™ methodology. The Innovate on Purpose methodology encourages organizations to consider innovation as a sustainable, repeatable business process, rather than a discrete project.
Jeffrey is the author of “Make Us More Innovative,”