Prev: FAQ 3.18 How can I free an array or hash so my program shrinks?
Next: Using new features of Perl
From: ccc31807 on 13 Apr 2010 11:46
This isn't a complaint, gripe, or an appeal to sympathy. It's simply a
report on a conversation I had yesterday. You can draw your own
conclusions.

In case you missed the first installment, I vented on c.l.p.m. because
of a series of 'unknown' requirements that I had to implement after
the fact. The project was preparing a series of task documents
detailing specific tasks for several hundred people. The software was
already a week late when I discovered a major requirement that no one
had previously specified.

The project wasn't owned by IT, but by the business side with the
parameters and template dictated by HR. My role was to do what I was
told to do. I had no input into the requirements, design, or work
schedule.

Anyway, the conversation I had yesterday was with a friend of mine,
one of my upstream contacts, with a long time business background who
had been an IT manager for about three years. What he said was this:
"When you find out about a project, you start immediately. Don't wait
for people to tell you what to do, you start writing the code at once.
When you get the details, you can change what you have written."

The purpose of this conversation was to discuss a to-do list of about
six items that we know have to change, and a promise of a number of
other changes that we will get in several weeks. I said that I would
wait until I saw all the changes before I started on the updated
version. My friend said: "No, start making the changes now, and you
will be that far ahead."

Here's the point -- The business managers have a mind set that you can
get a head start on a project by building it before you know what it
is. Once you get word of it, you start on it. That way, when the boss
mentions it, you can say, "We've already started and it's underway."
That's what happened to me, with no knowledge that I was being fed
requirements piecemeal, with no thought as to how the tasks would be
specified. (Yes, I was stupid.)

I don't know what the lesson of this is, except that you do your job,
if you're lucky enough to have one, and do the best you can with what
you have, not expecting to change the culture of the business side.

Thanks, CC.
From: Brad Baxter on 13 Apr 2010 12:37
On 4/13/2010 11:46 AM, ccc31807 wrote:
> Here's the point -- The business managers have a mind set that you can
> get a head start on a project by building it before you know what it
> is. Once you get word of it, you start on it. That way, when the boss
> mentions it, you can say, "We've already started and it's underway."
> That's what happened to me, with no knowledge that I was being fed
> requirements piecemeal, with no thought as to how the tasks would be
> specified. (Yes, I was stupid.)

Makes me think of
http://en.wikipedia.org/wiki/Agile_software_development#Principles

My experience is that your experience will likely be all over the map.

:-)

My philosophy: You can't steer a canoe that isn't moving. But I
also have no illusions that I'm particularly competent at project
management. I'm okay with that.

--
Brad
 | 
Pages: 1
Prev: FAQ 3.18 How can I free an array or hash so my program shrinks?
Next: Using new features of Perl