Bad Requirements, Bad Project Management

[Dynapen]

Here's my problem that I don't know how to handle. I have a project I am going to be working on that is going to take the current team (5-7 programmers) 6-9 months. That includes half the team learning a new language (Java) and the whole team learning a new set of tools.(Oracle 9ias, OID, etc....). Normally this wouldn't be a problem. But the client has asked for, and my office has agreed to shorten the development cycle from 6 months to 60 days. (including weekends). This will also involve transferring a current ASP application to JSP.

The development team also has another learning curve. The half that knows Java doesn't know the business rules. The half that knows ASP and the business rules, doesn't know Java.

So how do you convince the project lead not to jump to Java, or if that isn't possible to at least get us started on the development. Right now we are just sitting while he works on another project. No idea of what sections we will be coding, data models we need to design, or what is and is not going to get put into the project yet.

Basically, I have a bad project lead, that agreed to bad requirements on a bad timeline, and I am not sure what to do about it.

Anyone got any ideas?

The money's gone, the brain is shot.....but the liquor we still got.

 

[KornGeek]

My best suggestion is to brace for impact. What you have described sounds like a recipe for failure. Anticipate a bad outcome, and prepare for it. If you're job is on the line over this, I would begin looking now.

As long as you are prepared should this not go smoothly, you'll be protected if you manage to pull it off or not. To actually pull this off will require great focus and dedication from the entire team. It will require late nights, and probably no shortage of arguments. However, it will be something you will be proud of for many years if you succeed (or even come reasonably close).

In my opinion, your best chance for success seems to come from teaming the Java programmers with those who know the business rules. Let the Java guys do the programming with guidance from the others. If they work well together, each should learn some of the other's information.

Because project management already seems to be making some poor choices, I wouldn't spend too much time trying to make them see reason as far a changing the design. I'd expend the energy trying to find a way to achieve the impossible.

We're computer professionals. We make the impossible possible with a combination of caffeine, late nights, and things better left unsaid.

Good luck to you. I hope this goes well in the end. Remember, if you find a way to pull this off, you'll all be heros (for about a week).

 

[rhhyatt]

'Victim-of-the-week',

This is a very common situation, written up in many articles and books. The best one, for your situation is 'Wicked Problems, Righteous Solutions'. This book, and I, advocate, short development cycles, until all has agreed
'enough'.

The point is to get something USEFUL into production as soon as practical, knowing functions and features will be added in furthur cycles of development. By keeping focused on what is actually useful to the business, they will 'guide' you as to what to implement on the next cycle.

There are too many reasons why this is a good method, and I don't know if this is the place to detail.

Regards, rhhyatt

 

[carp]

Instead of sitting around waiting for the lead to get finished with the other project, I would try to be a little more pro-active.

If you have a group that knows the business rules, they could start outlining basic requirements for the java programmers. The fewer questions your programmers have later, the better.

Will everybody have to know java, or could smaller teams of, say, a java programmer and an ASP programmer who knows the business rules get by for now (assuming the non-java person is trying to learn java as they go, just as the java person must be learning the business rules)?

How much slack was built into the original schedule? Does the schedule acceleration make this truly impossible, or "just" extremely difficult?

Do the non-java people understand OOD, or are they truly starting from scratch? This will make a huge difference in your learning curve.

It sounds like you have a real hairball on your hands, but it may not be as impossible as it seems. I would recommend you document your concerns, try to get them up your chain of command, and then start improvising. You certainly can't afford to wait on this one. And if you pull it off, as previously mentioned, you'll be gods (until somebody notices you bleed when cut!).

"The money's gone, the brain is shot.....but the liquor we still got." - Well, one out three ain't bad, and you picked a good one to keep!