Ray Horsley wrote:
> Thanks Richard for these thoughts. I believe I fall into a variant
> of the "camp A" which you've mentioned, working with organizations
> run by really dumb and most of all lazy IT staff. Not all of our
> clients are like this, but frequently we'll run into IT guys who
> are simply too lazy too download anything to all the machines in
> their schools.
I've seen that too. And my brother, who's an IT admin at a hospital and
he sees that all the time, his peers reusing requests from the
stakeholders they're supposed to be servicing, using a wide range of
irrational claims to justify inaction. It's (in)famous throughout the
IT world, but stakeholders don't have the technical background to argue
back, so IT rules the roost however they want.
And it's even worse than you may imagine: I've worked with one very
large institution (who shall remain nameless here) who is still
standardized on IE6 to this day. Yes, even after Microsoft themselves
has been spending millions trying to educate their customers to move on
to any more recent version and get away from that bug-riddled security
nightmare (see <http://www.ie6countdown.com/> as one example of MS's
attempts), this org's IT director refuses to budge, exposing all of
their users to thousands of known exploits every day.
I see stories like that all the time: doctors, educators, and members of
many other orgs held back from getting the tools they need to improve
organizational performance while being exposed to security risks along
the way by IT staff who either don't understand their job or have other
reasons to hinder the org from fulfilling its mission.
A contractor like you or me is in a tough position in those
environments: with a rational discussion of benefits and risk exposures
it's possible to close a sale and deliver exactly what the client wants,
but doing so may cost an IT person's job along the way. Such IT staff
will fight it tooth and nail, and unless the org has a good CTO and that
person is involved in the discussion, middle managers won't have the
technical background to understand that their IT staffers are being
irrational.
IMNSHO, that's a sale worth losing: working for dysfunctional orgs just
makes a long workday longer, and ultimately any project with them will
become mired in other unnecessary difficulties.
There are too many smart orgs to work for to waste time like that.
The trend for orgs to add the position of CTO was originally merely
fashionable, but in recent years as tech become both more diverse and
more pervasive that role can be invaluable as a mediator between
stakeholders and tech staff.
When a CTO takes a hands-on role in vendor negotiations, I find many of
these sorts of roadblocks disappear.
But unfortunately, some orgs don't understand why they have a CTO
position, and don't fully utilize that resource.
> I couldn't agree more with the technical case you've made here but
> who was that shoe salesman in New York who made the famous comment
> "Give the lady what she wants"? We've got to make sales and if
> the client wants software that runs in a browser we can either
> argue with her or make the sale and move on. Obviously the latter
> of these is by far preferable.
The core question here is: "What exactly does the client want?"
In many cases, when a vendor says "We have a web deployment solution"
the customer hears "native HTML and JavaScript", and they're not at all
imagining needing to download and maintain a browser plugin.
When the practical implications of a plugin are known to the client,
many of these discussions stop right there. It's not really what they
had in mind, and doesn't really solve the problem they were hoping to
solve though the simplicity and ubiquity of native browser implementations.
Some of those who hear that it's a plugin and still say they want it
will become frustrated down the road when deployment actually happens.
No blame there; they're just not technical people and have probably
never used any plugin that wasn't pre-installed, so the implications of
requiring that every machine in their org be set up to be
user-modifiable to allow compiled executables like a browser plugin are
unknown to them.
So this leaves us with the relatively slender subset of potential users
who fully understand what using a plugin means and still want it.
For that small subset, a conversation about the benefits of other forms
of executables can often get buy-in - provided they have a good hands-on
CTO (see above). ;)
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
