Ive seen this problem many a time. Management, Engineering etc all get a brilliant idea for a new system. They spend vast resources or analysis, design, contracting out etc. Then they are totally shocked that the lower level managers and staff refuse to use the new system. In this less is more day and age of layoffs and staff reductions there is no place for new systems (no matter how pretty the reports are that senior management would get) that dont reduce workload. Even if the workload is the _same_ its too much as its a) different and thus people must be retrained b) different and thus people arent comfortable with the tools.

I think there are two strategies that can minimize the impact of this type of thing. The first is get the programmers to actually use their programs for the tasks they are meant for. This can be difficult because normally there are barriers put up between production and developement staff but if this problem can be overcome it will pay off in spades. An example for me are two biling systems we have in our firm, one is a large well known all-singing all-dancing integrated billing system, the second is a custom tool designed to bill data customers. Both systems are used for the same purpose, however the first takes about 10 screens and about 45 minutes to provision a new customer and service, and about 30 minutes to deactive a customer, and about 25 minutes to issue an adhoc credit note if the customer would like to be deactivated early. On the second system all of these tasks take no longer than about 3 minutes (and usually a lot less). The reason? The programmer was given the task of USING the tool to add customers HIMSELF early in the process. Anything he didnt like to do would not be liked by the user base. End result, he spent an extra bit of time reworking the flow of his screens to actually reflect the usage cases of his customers.

The second tactic is to actually design the app from the front end first. Forget about back end functionality, the front end screens should be designed in close partnership with intelligent and interested users who will be given the responsibility of running the software. IMO getting this to happen is alot harder than making the GUI design team eat their own dogfood.

---
demerphq

In reply to Re: Can I keep my OMI? by demerphq
in thread Can I keep my OMI? by pg

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.