I have the last two weeks of the year off, so my last day of work this year is two days from now, Friday. I’m doing my best to sew things up for the parts of the project that I’m responsible for, such that the people who will be covering for me will not be left with a steaming pile of feces. That said, as time goes on in the project, I find there to be some interesting and odd conflicting goals that management doesn’t seem to want to face yet are blatantly there, which must be dealt with lest all of my effort to not leave folks with a steaming pile of feces be entirely in vain.

We have a list of priorities we’ve been given from our internal customer, ranging in priority from one to 13, and “low.” Yes, “low,” which is somehow lower than 13 but doesn’t rate actually getting numbered “14.” Sort of like an ancient counting system that hasn’t yet developed a robust concept of cardinality.

What’s come to my attention is that there are a lot of unwritten priorities that rank, I guess, at “high,” which, in this system, would occur before “one.”

Keep that in mind as I digress for a moment to address the schedule on which we’re supposed to meet these unwritten priority-“high” tasks.

My team reviewed the requirements for the project, developed a list of what needed to be developed, created a full schedule for development, and started off.

About two weeks or so into actual development, someone (I don’t know who) looked at this schedule and said, “We want all the stuff that you scheduled for the end done first, and we need it done in a third of the time that you allowed for it.”

This is akin to telling a home builder that you realize he just broke ground but you really need to get those gutters on the roof in a week.

In addition, it was very intelligently decided that it would somehow help us if they threw a bunch of extra people on the project who wouldn’t actually stick around for the whole duration - they’d rotate on and off the project as they were needed elsewhere - and they generally wouldn’t be familiar with the technology we’re using. This sort of thing makes me question if anyone has actually read The Mythical Man-Month, but maybe I’m asking too much.

So, let’s bring that all back together: Unwritten (and generally constantly changing) requirements; an unrealistically aggressive schedule; and a team that changes fairly regularly, which requires time to bring the new members up to speed and transition work from the old members.

No good.

What it’s coming down to is that someone’s going to have to choose one of these things that we’ll actually be able to complete by the unrealistic deadline. Maybe two, if you’re lucky, but call that a stretch goal. Here are the options:

• Actual development on the product, with only the features we’re able to get done in the time we have left.
• Training of the new people on the team and transfer of knowledge about the use of the not-quite-pre-alpha product we’re writing.
• Thorough documentation of all of the decisions that get made, have been made, or are currently changing due to someone’s hidden agenda.
• Meetings to discuss said decisions one more time because someone new on the team calls into question everything that’s already been decided.
• New unit tests that verify the stuff we’ve already done does what it’s supposed to do.
• Additional unit tests on stuff that already has tests to ensure the code coverage numbers are up.
• API documentation on the product.
• Quick Start/User Guides for the product.
• A reference implementation [of the small portion of the product that we actually finish in the time allotted] that can be used as a template for other implementations [and will probably have to be thrown out by the time we finish].

You must choose, but choose wisely. You only get one of those things by the deadline.

We’re a good week behind the “deadline” already, and it’s only the second phase of eight.

My understanding is that the project we’re working on has been tried a couple of times before and has failed. If they ran into this ridiculous nightmare, I can see why - management (more specifically, marketing and sales) actually sets you up for failure by requesting the impossible, then has the balls to ask why you’re not on schedule. We are on schedule. Just not your schedule. Get a clue.

Here’s an idea: Why don’t we schedule a series of meetings with all of the developers on the project for several hours each week so we can go over administrivia, change the existing requirements, add new requirements, and get the techs to explain precisely how things are implemented from a technology standpoint to the non-techs? That’s not only a great use of time, it definitely helps to keep the project on schedule.

Oh, wait - we already do that. Sorry, I forgot. I was trying to get something done. My bad.