Programing

[sarals]

if it's anything like a list of hardware requirements you might be able to come up with a generic boiler plate

It's kind of like that... I like the analogy of building a house. Someone comes to you, a contractor, and says I want a house, start building it. You say, but how many rooms? how many bathrooms, how many windows? The person says, you write up a proposal. So you create a blue print that the person glances at and says okay. Now.. you start building the house. The customer comes to the site and says... hey, I don't like that window there and I want more bedrooms! My point being, that the person who you are building the house for... or software for, needs to communicate clearly and in detail what they want starting before the pouring of the foundation. Certainly that person will need the help of an architect and/or contractor to make those decisions and to detail their ideas, but if you don't make them primarily responsible for their requirements, you get blamed everytime it doesn't turn out the way they "wanted" it. That causes re-dos, cost overruns, missed deadlines.

Every place I've worked prior to this one had a system. In general the system was that the user wrote up a request of some sort for services. That request was received by the Development Department and analyzed. In response, we would propose a solution detailing exactly what we would do to meet the user requirements. These were tools used to facilitate understanding between the user needs and the developers. It would include the time and resources to complete the project. The user would then approve or work with us to come to some mutually agreeable solution.

The problem with how it works where I am now is this...

we make a guess at user requirements...
the users glance at them without much thought and say yeah...
then we start doing the work and presenting results...
the user then realizes they want something different...
we are constantly changing the user requirements and specs...
work is re-done... deadlines are missed.... management is unhappy and blames development... development is unhappy because they were caught in the middle. The problem is that what the user wants has not been thought through thoroughly and communicated. The User Requirements document is a tool to facilitate that communication. If I do the requirement document, I might as well be talking to myself.

In the two places I worked previously, I made my cost estimates within acceptable variance and I don't think I ever went over the deadline.

Every project I've worked on at this place has been overdue in management eyes.

My boss has never worked at any other company and says that the systems at these other companies (one was a subsidiary of GTE, the other of American Express) doesn't apply to us.




Sara

Sprint PCS... NOT free and NOT clear!