Fog Creek Software
Discussion Board

Departmental Solutions - Good or Bad?

"More Knuth" reminded me that for years I believed that allowing departments to create solutions locally, without IT input was a bad idea.  That we spent our time "updating" these when they became too much for the department to handle.  Or worse we inherited a frog, the department thought was a prince. [ie. No documentation, original developer gone, written in some obscure language, etc.]

As I began consulting, these departmental solutions began to pay off.  We would get the 400 meg Access application that contained billing, but no longer worked or could do what they wanted.  We would then rebuild it according to the needs with full analysis, design, and structure behind it. 

I started thinking about my original position, and perhaps I was mistaken.  Consider a large company that allows departmental solutions, perhaps even supports the concept.  When a departmental solution becomes Enterprise impacting, then have the IT staff take it on, as a project to build/re-build the solution for the enterprise. 

Is this a better approach?  This uses the least expensive resources for skunk works or local solutions.  When a project is large/complex/impacting enough to reach the enterprise, we spend capital dollars making those a production ready enterprise solution.  The departments prototype and IT implements.


Mike Gamerland
Wednesday, April 30, 2003

Departmental Solutions push Profit and Loss responsibilities down to the lowest possible level.

That way, when you say "Joe's group is costing us $450,000 in salary every year, but he pulls in $550,000 in revenue"

You don't forget to add "Oh, but Joe has more-or-less two programmers working more-or-less full time on support apps at the division level. hmm.  Maybe joe isn't that profitable after all ..."

Just my $0.02 ...

Matt H.
Wednesday, April 30, 2003

Departments normally create things locally because IT input is either non-existent, or worse, positively harmful.

You must also remember that you come in and see the program from a very limited point of view. You redesign it to more "professional" specs, and then collect the bills and disappear before users can let you know what are the problems with your design.

At our college I bumped into the on site consultant for  the database application vendor. He told me he was leaving and said he felt glad that the project had been a success. I told him it was a success for him because he had his check and passport, but the rest of us had to live with the crock of shit. He looked hurt!

Stephen Jones
Wednesday, April 30, 2003

A departmental solution is a pure requirements document - they built something that met their needs almost perfectly. If it's a unique department, it solves their problem, and it's covered by backups, there's no reason to move it to the enterprise level.
However, if the departmental solution solves a common problem (nursing scheduling in a hospital, travel vouchers in a corporation, etc) then it's in the interest of the company to centralize the solution so that they're not paying a dozen people to solve the same problem.

The trick is taking in a departmental solution and not making it suck, which generally happens when you ignore the users and worse, when you ignore the work that went into the departmental solution.


Wednesday, April 30, 2003

If you've got a few departments building similar solutions, there's probably redundant work going on (in terms of both development and maintenance) and it might be more efficient to combine those development efforts early on and build one system that supports two departments.

It sounds like the benefit of departmental solutions that you're describing is that you get the best information from the end users about what they really do because they've built software that mostly lets them do it and the software itself is really good documentation of their workflow.

So, are there ways to get that information from the end users that don't require the end users to build a whole application?

Beth Linker
Wednesday, April 30, 2003

So many IT departments just don't respond to the needs of their departments.  There are many reasons given: valid and invalid.  But the bottom line is that the department created something because nobody else would do it for them.  They would rather have stayed on course with adding value in their true area of expertise, but had to be diverted to overcome a problem.  Thus the solution.

Philo is right: their solution is now a requirements doc - to the best degree that they were able to express it.  Use it as such.

Mrs. Robinson
Wednesday, April 30, 2003

Stephen, when you mentioned in passing, " I told him it was a success for him because he had his check and passport", it caught my attention since I had heard from an old classmate who did a contract in Saudi -- he said that they confiscate your passport upon arrival and you are not actually allowed to leave the country until the project has been delivered to your employer's satisfaction! I told him he was insane; no country would allow any employer to do such a thing but he was adamant! Is this the sort of situation you are speaking of? Sure is an interesting way of doing things!

Tony Chang
Wednesday, April 30, 2003

I went through a similar re-evaluation when I discovered just how useful some departmental Access databases were to the departments.

Software-wise, they were dreadful. They weren't relational, there were several copies with data mixed up, and yet they performed a valuable job and could be maintained by the staff.

On the other hand, I also witnessed the scene after a departmental manager got sacked. This guy had been an amateur developer and had created all sorts of working but dangerous apps and configs in his department. IT didn't have the authority to stop this but were dreading the problems when they needed upgrading.

The day the manager got the sack, our IT manager, who normally never touched any of the admin duties, personally sat at the main admin console removing all the bad apps. It looked like he was enjoying it.

Wednesday, April 30, 2003

I am curious about your comments:

Departments normally create things locally because IT input is either non-existent, or worse, positively harmful.

How would you define harmful? 

You must also remember that you come in and see the program from a very limited point of view. You redesign it to more "professional" specs, and then collect the bills and disappear before users can let you know what are the problems with your design.

I do not know what kind of IT support you get, but I have yet to see this happen.  Where could the IT people disappear to?    I am also curious if the "problems" found are true problems or "features."  Real life:
I was involved in a SAP implementation, where employee and contractor time is recorded and invoices must match against the time in SAP and purchase orders must exist before work can begin.  When the system was implemented the users complained that it was making projects late.  Why? It was very common for the business to start a project before the dollars were budgeted. Purchase orders were allocated when the paperwork was done and hours were invoiced for work done before the PO was cut.  This allowed projects to start immediately, not so today.

To the departments this was a problem.  To the executive sponsor this was a requirement.  One she demanded to get control of the project.  To the department heads,  the IT staff created this unfriendly system. 

Mike Gamerland
Wednesday, April 30, 2003


This is way off theme, but since you asked...

When, and this was in the late 70's, I worked in Saudi Arabia the situation was that you needed both an entry and an exit visa. You turned in your passport to your employer, who in turn gave it to the government, who issued you with the requisite exit visa and, if you were just on a short trip out of the country, a new entry visa. I never did understand the logic of this, which was even more perverse than that required to obtain a US work permit(you can't get a job without visiting the US, you can't visit without a permit, and you can't get a permit without a job).

That local employers could prevent you from leaving was definitely possible, but the only cases I ever heard of were Phillipino maids and the like who were employed by individuals rather than companies

In order to get a work permit for you, your employer had to provide your food and accomodation. On the whole they had a hard enough time recruiting and retaining expatriates that they couldn't afford to pull a stunt like not letting you leave. Anyway, we all used to sit around comparing who was offering the best staff house, facilities and leave rosters and generally griping over our fate, so you can be sure that news would have spread in no time flat.

P.S. If you like the climate in Houston during the summer, you'll love Dhaharan. Sorry, that's an in joke.

David Roper
Wednesday, April 30, 2003

I would agree with all the people that said that all these departmental solutions become SPECs or requirement docs for the enterprise solution.

I would also add my vote to those who highlighted the fact that departmental solutions were maintained by the local users.

Until IT, or business software becomes totally extensible by users, it is useless.

By this, I don't mean word processors or spreadsheets. Anything with business rules should be extensible by the folk that use it. Rules change all the time. People make exceptions on the fly to these rules. Exceptions that did not seem apparent when the original system was specified.

I might even argue that as far as business goes, Access/Excel are the best languages for developing software, because of the sheer number of people on the front line that understand these tools.

As was posted in previous threads, and I will re-endorse now, I have seen Access(main culprit) apps that were ghastly from a professional perspective, but made sense to the users. From the users perspective though, they got the job done.

I think the best IT department/professional is one that, as Joel would say about management, allows people to do their work. IT's role is to remove impediments to their work. While IT likes to be in control, we need to realise that they provide a support role, and that PRINICIPALLY, their role should be to allow the rest of the firm to get on with theirs.

The best IT is one that is aware of what the users are doing and using computers for.  This is a support role. If that means training, so be it. If it means helping users with basic SQL, then fine. Once in a while it will mean recognising areas of duplicated effort, and bringing folk to the table to combine efforts/resources.

If you want to be a software purist, write an Access or Excel equivalent app, and let business users get on with their jobs.

Wednesday, April 30, 2003

", but made sense to the users. "

Elf bowling, the Christmas lights and Anna Kournikova made sense to users to.

You are correct IT should be a facillitator, not an impediment. 

Wednesday, April 30, 2003

First the question about Saudi. If you are on a work contract in Saudi then your employer will keep your passport and issue you with the residence permit. It is not allowed under Saudi law to let you keep both the passport and the residence permit. The reason for this is to stop you leaving the country and giving your work permit to somebody else.  You could argue to keep the passport but then you would be breaking the law about carrying your Saudi residence permit with you at all times.

If you wish to go out of the country during the duration of the contract then you need an entry/re-exit visa which is only granted if your employer is in favour (and in the case of multiple entry/re-entry visas if the Interior Ministry hasn't decided to kybosh it). It is quite common for unscrupulous employers to refuse these even to Brits and Americans, but most Brits and Americans avoid the unscrupulous employers like the plague. The keeping of the passport is not so much the problem; the real problem is that the employer can refuse you an exit visa (the official reason is that he is your sponsor, and thus responsible for any debts you may have incurred in Saudi even if they have nothing to do with his company).

If you are a contractor for a short-term job then you will probably come in on a business visa valid for three months which will allow you to go in and out of the country, and you keep your passport. On a longer term contract you are likely to find that you have a labour contract with the partner of the foreign company and thus are subject to his whims. If the partner is a subsidiary of a Western Multinational you are unlikely to have too many problems, as apart from anything else the multinational may be afraid of being sued in its home country. Otherwise it depends.

Most Westerners in Saudi work for government instutions, universities, big government controlled industries or branches of multi-nationals so the problems are with bureacracy more than anything else, but don't depend on leaving Saudi at a fixed date.

In general a computer programmer has one trump card. All Saudis know about batch files that trigger at a certain date since on April 26th 1999 something like one third of all the computers in the Kingdom had their hard disks wiped clean.

Stephen Jones
Thursday, May 01, 2003

          Here are a couple of ways IT can be harmful rather than helpful. I have come across most of them.

a) Prevent a department from doing anything by saying they are working on it and the leave it for years.

b) Actually build or contract out the mammoth company wide database application ensuring that the user interface is so clunky and unituitive that it quintuples the amount of time necessary to enter things. that the reports don't have the information you need, that data entry errors multiply exponentially, and that some of the business rules are so inappropriate that you have to spend half your time filling in paper forms to request some remedial action.

b) Implement draconian security and then announce no exceptions, even if the security prevents you doing your job at all. My favourite example was the local steel factory that took out all the floppy disks from the computer drives to avoid viruses, but wouldn't give my contact external email access either because he was on holday when they configured it. Other beauties are not letting in .doc files to the HR departments email,  zapping .zip and .exe files sent to R & D departments, insisting that requests for new software go through the centrial six-month long official channels and not letting the gou working on your demonstrations, flyer, intranet page bring in his own computer because he wants to work with something better than MSPaint in the meantime. and putting the same anti-virus software on each computer but setting it up so it can be only updated when connected to the network, and also setting up the network so that when logged on you can't install anythng and thus update the anti-virus program.

d) Half do the job; like half set up Outlook on somebody's computer but not test it on all users for that computer so that later you have to go in and find out what has been half done before you can even start to repair it.

e) Get a program so complicated you haven't the least idea how it works, and then force all departments to find workarounds to it.

The main problem though is given in your reply. When something is completely cocked-up SAY IT WAS IN THE SPEC. A particularly perverse version of this is to say that you can't change something without permission from higher up and then after the users have gone higher up tell the big boss that  things really shouldn't be changed because of security or time reasons or whatever.

Any MIS book on database design will give you the quote from the manager of a large company after he had seen the database specs the designers had collected from users  "You know, this is the first time I've really seen how my company works".

The executive in your example didn't have any idea of how his company worked. His requirement existed long before you came along, it was just that before people could safely ignore it. What you managed to do was to make it impossible for these people to do their work, because you did not insist on watching all the users work and interviewing them as part of your design process. Sure your method is cheaper, and flatters the bosses ego more, but don't expect people not to blame you for the foul-up when you've knowingly accepted doing a jerry-built job to get the contract.

Stephen Jones
Thursday, May 01, 2003

A while ago I posted about outsourcing IT as being a negative influence on innovation and actually restricting an organisation in doing what it needs to do.

Its long been my belief that IT provision should not be seen as a separate department, or source of supply, but integrated within each department just as any other communication function should be.

This doesn't mean there shouldn't be an organisation wide IT integration with standards policies and the like but the actual provision for the department should begin in the department.

Simon Lucy
Thursday, May 01, 2003

Any solution when done properly works fine.

Its the old argument about centralization and diversification. There is merit in both.

Usually IT department solutions cost considerably more and have high inertia, this is what pisses people off, so they go looking to do it 'quick' but hopefully not 'dirty'.

With good developers I favor the departmental solution.

Thursday, May 01, 2003

*  Recent Topics

*  Fog Creek Home