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.