Selling video projectors to government accounts and schools is a far cry from selling to corporate customers systems designed and integrated sourcing from 100's of suppliers.  A just in time purchasing model with every system unique to the customer, isn't an easy task to accomplish.  Despite the challenges we managed to grow from 30 million to over 200 million in less than five years.  

Background

Digital media and Video system integration was new in the late 1990's.  

• Video conferencing was introduced by Sony Corporation in 1993
• Digital Media Camera's Mavica series was introduced by Sony Corporation in 1993
• High Definition TV was introduced by Sony Corporation in 1993 

I had the pleasure of managing the logistics for the trade show that launched these innovative technologies.  As an introvert, I was horrified when my manager informed me that I was going to be at the show and presenting these technologies primarily the video conference technology but also the two others while those presenters took breaks or held meetings with corporate customers.  

First, let me say that I nearly failed in pulling this show off.  The video conferencing technology was dependent upon several outside variables.  The same is true in many current technology offers specifically "cloud".  The good news is that we need to understand the innovation and understand when we are improving what we already have.  Two reasons; a) re-use of existing infrastructures and b) avoiding putting barriers on things we can recognize as revenue quickly.

We went to market with mobility as a new shiny offer and allowed the safeguards we had in place to be ignored(M2M).  Since then we have seen far more security breaches than we can afford.  Innovation isn't always the type which we need to re-invent or invent new things.  Only an expert can help you to determine what is new and what isn't.  

Some technology facts that we should know.  Video conferencing today, is perfect if the technology is sold by an authorized partner.  It is going to struggle if we continue to use big data stores as a component in the equation.  First of all the law says we need to protect people privacy and an open data source is OPEN not protected.  

I happen to know allot about video conferencing technology.  I also know much more than I'd like to know about Big Data.  Like the fact that Machine Learning, Artificial Intelligence and Internet of Things are all in contrast to the laws we have protecting our privacy and federal regulations protecting human research.  But that's another story.  

I became an expert in Video Conference by choice, after having an experience that was actually a failure avoided.  Not everyone is determined not to fail.  

Before Sony launched the technology at a major trade show, I was one of the people behind the scenes making things happen.  I was not going to allow the technology I was responsible for to not show at this event. Sony always launched new emerging technologies in threes.  Our booth was always a favorite stop for show attendees.  I wasn't going to be the person who failed to deliver the 3rd or the most exciting part of the launch.  Video conferencing was what we depended on during the Covid 19 pandemic. 

Its beginnings were almost a failure.  

The problem at that time was with one component which allowed the phone lines to connect to the video codec.  It was a part selling for about $350.00 dollars but it was the one device which was often not working on first try.  Okay, I thought I was offensive and made sure I plan B, C and D.  By 4:00 AM the day of the show, I was on plan D.  Counter to counter delivery of this last device we hoped would work.  Considering A, B, and C, did not work.  The engineer in our HQ office claimed I was the first woman to install the emerging technology.  But, I never seemed to get recognition for that accomplishment.  

The show went on and I become an extrovert as I presented the technologies.  My manager had to call out the way I managed audience questions, even those "uh oh" types of people who tries to make a presenter look stupid.  I managed these types without breaking a sweat.  She called me a natural.  

Now, let's fast forward to the next role I took.  Sony had put their partners through a rather aggressive vendor selection process and ultimately chose a small partner to sole source the video conference technology.  I selected one of our more advanced partners, but my liaison from Japan saw things I didn't see.  This tiny box seller was chosen to represent Sony's major play in the market Video Conferencing.  After about a year, that organization sought to hire an operations expert who could maneuver the customer and service provider space required to deliver the emerging technology.  That was in 1994.

I specialized in Video Conferencing and most would joke about the fact that I was who they considered the Queen of Video Conferencing.  We sold many new systems between the years 1994 and the year 2000.  We fixed just as many if not more systems attempted by unauthorized partners.  

By 1995, we had a pretty well established system within the organization and after we hired the industries top experts in the field.  Many of our larger deals began with a basic video conference system.  We managed the deals by holding the customers hand through the entire life cycle.  10 million dollar deals started by successfully and professionally handling the video conference side of the deals.  

We were the sole source provider of these services and grew our business from 30 million to just over 200 million.  What once was a partner selling boxes for markups to a full systems integrator.  

We had many successes and I personally hated to clean up the messes caused by unauthorized partners who had no clue what they were doing in the early example of cloud computing services.  See the following table, in it I've applied the various technologies to the three components in a cloud offer.  

I am now going to return to the story, as it should have been a happy ending.  It unfortunately, was not.  Year 2k was infamous for being a disaster to any company running DOS based accounting software.  Boy how I miss the old DOS Based systems that never failed.  Inputs caused expected outputs based on a user performing an activity in their task.  Those systems were never faulty and bugs were something that came later. 

So, our organization was doing professional services or project accounting before the software was designed for this purpose.  Our organization went through a vendor selection process with our internal experts and myself validating the requirements and qualifying the vendors responses.  

We were unique in that time and had no customer references of our business models.  We had five different software applications and one was managing 70% of the companies revenue.  That was my job, using excel.  Yes, the majority of the work was moving through my part of the organization.  I was in charge of billing and managing the crews at 99% billable rates.  We had a special module for our work, but that didn't go live.  I'll share more about this later.  

We finally selected an application which was a windows based technology and unlike any our operations users had ever worked with.  Basically, the vendor we selected was dealing with a group of people who were not likely to have a success story.  We just didn't know how the software worked and elected to use user defined fields rather than transition into the software as it was designed.  I was part of that problem.  I knew my former teammates were old school and if it didn't say what they wanted it wasn't going to work for them.  So, I supported using these advanced features (user defined fields).  

Our IT team (2 - IT managers) was part to blame for the failed implementation of the software and our insistence on using free text fields and user defined fields was responsible for the rest.  Apparently, the original IT manager had decided his role was at risk and as a result he installed a network threat which required his presence and his constant attention.  Within two days after he was let go the network went down and with it were the configuration files.  First the network began to move directories causing us to use outdated configuration files.  I knew something was wrong when the new IT manager claimed he hadn't changed anything on our network but the directories where mapped wrong and almost by the hour changing.   

Our implementation was sabotaged and might have been recovered if we hadn't purchased a software module for our project accounting that was proprietary unlike the main software which was sold and we confirmed could be modified by an inhouse developer.  We didn't have such a role, but wanted to have the option.  We learned after going live with the other modules, the first we heard about proprietary software was when we(I) denied the business sign off for the project accounting module.  We also learned then that the majority of our software purchase was no longer eligible for software updates based on the add on module.  Despite our not going live, the customizations to adapt the proprietary software eliminated our ability to maintain the original software. 

The next couple of days were a series of failures which I was completely confident were software failures rather than the problems we faced with work file migrated into the software.  I based my assumptions on the fact that the vendor made such erroneous decisions selling us an add on module that ruined our major software.  I also was one of the people making sure the vendor was doing their job and we were getting our money's worth.  Going back to all those user defined fields.  

By day 4, we had recovered in part from the network failure.  An expert was brought in to determine whether or not the company could recover from the bad implementation.  A small tiger team was brought together.  Our task was to first replicate the software we purchased without any of the customizations.  My job was to run transactions through this version without all our user defined fields.  The software worked every-time.  Bad news was we could not recover from the nightmare and had no one to blame or hold accountable. 

A report writing expert was brought in to manage the reporting failures caused by not using the features in the application.  Which is when I learned about data warehouse tools.  Problem we faced was that the information still wasn't complete.  We couldn't recover and pulling data we created in a report wasn't going to allow us to recover from the 1 million per day lost in that software.  We ruined the software with our inability to change our thinking and insistence that we were unique.  

Business people are not going to adopt software especially when it is agile or scrum delivered. 

The software implementation success is best determined by an ability to use the canned reports.  If you need to go to a data warehouse after an implementation, assume the implementation failed in some way.