Re: mass change of hyperlinks in Excel

Dan -

I have great sympathy for your situation.

I am currently working for a global pharmaceutical company that has a
seemingly rigorous methodology for implementing changes, largely due to the
United States Food and Drug Administration requirement that systems be
'Validated'. Not all of our systems are Validated, but that is about to
change. Pretty soon all systems here will need Validation.

FDA Validation is very time-consuming process. Any time that a Validated
system is changed, the entire system must be re-tested. This makes our
users less apt to want changes in the first place.

To make a simple program change (one line of code, for example) requires
that:

1) A Functional Specification that is at least three pages long must be
written (usually by a non-technical business analyst), defining the request
for change and giving the business reasons for making the change. The last
page of the Functional Specification has the 'test script' for testing the
change, which usually consists of something like 'Enter an order' with the
Desired Result being 'Did it look Ok?'.

2) The Functional Spec must go through a ROI review by management (technical
people are not usually involved in this step either, so at this point they
don't even have clue as to how much time will be required of the BA,
programmer, and user).

3) A technical person (usually the programmer to whom the project is
assigned, once the ROI is deemed to be worthy) then reviews the Functional
Specification and writes a Technical Specification, detailing the
programming and setup changes required to implement the request. At this
step, we usually determine that the Functional Specification was not very
"functional". It then takes a slew of emails to ascertain what the user
/really/ wanted.

4) Once all of the requirements are gathered, the programmer does the
programming, usually under orders to not communicate with the end user or
business analyst except through one of the 'lead developers', who haven't
done any programming in over five years.

5) Once the programming is completed, the programmer writes an 'As
Delivered' document, which documents what he /really/ did to implement the
requested change/enhancement. This document is usually longer than either
the Functional or Technical specs, due to all of the additional requirements
that were gathered during the programming phase.

6) The changes are then promoted to the QA environment for testing by a
business analyst. It sometimes takes /months/ for them to get it tested,
and once they find a problem and reject it, the programmer has to
re-acquaint himself with the project to make the requested changes to fix
the problems found during testing.


On the other hand, I don't believe that the "super-users" who use
spreadsheets are required to follow the same methodology described above.


My rule of thumb for estimating how long to do programming on a project is
now:

1) Estimate how long you /think/ it should take
2) Double it
3) Change the unit of measure to the next highest one


Thus, if I think it should really take /one hour/, I estimate it at /two
days/


By the way, my department recently got a new manager, and he has a new
director. Neither of them know anything about the System i or the
application software we use. My boss is now training /them/. She has to
prepare some new kind of report every week. I asked her recently if she had
ever seen the movie 'Office Space'. She had not, but rented it and watched
it a couple of weeks ago with her kids.

They asked her if working here was anything like the movie, and I believe
she told them 'Worse!'.

Bottom line:
I don't think I would describe this as an "Agile" company!

- sjl


Dan wrote:
Dilbertesque, perhaps?
The lawyers rule at this company. That said, I am not aware
of any pointy-haired bosses in my general vicinity.
In fact, my manager is, by far, one of the best I've ever had in my
career.
I am usually quite cynical on this topic,
given my career experience, but there seems to be a genuine
concern for associates' longetivity in this company.

The fact is, I've always been happier and more productive
in companies when the CEO is down the hall from my cubicle.
Taking the job at this 50,000 employee corporation
three years ago was something I weighed very carefully,
even though I'd been laid off for several weeks when I got the offer.
I'm generally happy here, but not nearly as productive as I could be.