I'm gonna throw in some dissent here. What this lays out is a "Big Design Up Front" approach to the project, which assumes that you can (a) know it all up front, (b) design it all up front, and (c) deliver it to a customer who hasn't changed their mind in the meantime. The problem with this is that the customer in this case may have a pretty good idea of what they want at the moment, but they're also liable to change their idea once they start seeing a working system fall together. Requirements are going to change. Allow for this in your approach.

I recommend borrowing some ideas from the eXtreme Programming and Agile Methodology camps. Build the system in discrete iterations (AKA "sprints"). At the beginning of each iterations, get your customer to prioritize a set of features that they would like to see appear in 30 days. Estimate each one, and draw a line through the list show what's "in scope" for the iteration. That's what you'll build. Any changes in requirements that show up while you're building go under the line on the list, to be revisited when you reprioritize before the next iteration.

This approach gets some functionality into customers' hands early, and gives them the chance to either clarify what they really want, or to change their minds without throwing away a huge amount of work. It also avoids generating a set of documents that have, at best, historical interest once the project is complete.

Your first iteration might be to install Bugzilla or RT, and do some minimal look-and-feel customizations. That'll give your boss something to play with, and it can engage real users. It also gets you a quick win, which is great for project momentum.

For smaller, ill-defined projects, I think that agile development models are a Good Thing. However, the part about getting the boss to sign off is purely a CYA maneuver. I think this person is in an awful situation and as soon as the boss says "why the heck did you do that?", the reply is "well, here's your signature".

Almost invariably, unless the project is very small, once I turn in a specification, the boss always changes something. I know of some people who deliberately put glaring problems (typically cosmetic) in specs merely so that the boss will hone in on those glaring problems and not screw up the core. Once the boss changes something, he or she has said "I've read this and approve, so long as these changes are made." It's tough for the boss to later turn around and shift the blame away from the signature.

Frankly, in a dicey "me versus the boss" situation, I don't want the uncertainty of an agile model. I want good, clean specs that I can point to. I've had to hold up signed specs before and the result has always been something along the lines of "my signature? Oh, yes. Of course I read that. But requirements changed. Could you please work this in?" I still have to do the work, but I no longer face the heat.

Mind you, if this were a normal situation, I think your advice would be spot on.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

the part about getting the boss to sign off is purely a CYA maneuver. I think this person is in an awful situation and as soon as the boss says "why the heck did you do that?", the reply is "well, here's your signature".

Get a signature, but get it at the beginning of each iteration. Getting a CYA signature up front is worth nothing; if you have to pull it out towards the end of the project to wave at your boss, you're already fucked hosed.

In my experience, it's far better to keep a list of prioritized iteration features on the wall where everyone can see it all the time. Get your boss to sign that list at the beginning of each iteration.

1,000th post!</code>

Make sure that you write down the requirements of the project so that you don't get burned by 'we wanted this or that'. Bug your boss. Bug potential users.

Consider keeping a calendar notebook (if this is a political hot potato) so that you can make notes about your project and what people agreed to or what you accomplished. You may want to refer to http://useit.com in your development work as a reference on user interface do's and don'ts.

metadoktor

"The doktor is in."

That is not a bad idea, but considering my title is "Tivoli Administrator," how can I claim development experience without fear of- well, the obvious:

I admit, I am a bit naive about things such as this.

No worries. This happens all the time and no employer is going to be surprised by this. Just tell them the truth.

Cheers,
Ovid

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

Don't worry about the title. If you send your resume off to another company, they'll look at the experience, not the technical title. Often titles have little meaning outside the company that you are in.

My last job title was "Principle Telecommunications Technical Officer" I was paid to do cellular base station design and project management. Now my title is "Unix System Administrator". IMO Employers are much more interested in a demonstrated ability to do the job than in titles and qualifications.

There are clearly other issues involved in making your decision about taking this task on but I wouldn't let details like this get in the way of gaining experience... most of the people I know who work in IT started off doing something else.

--
my $chainsaw = 'Perl';