[theforum] weo 2b: read me 1st

[David Kaufman]

Martin Burns <martin at easyweb.co.uk> wrote:
>
> On 6 Nov 2004, at 19:26, Joel D Canfield wrote:
>> Can we try to sort out a plan for how/when/what is going to happen?
>> Does anyone want to take the 'lead'?
>
> I'll duck the 'lead' bit, but I'll do a bit of a kickoff.
>
> There are a number of questions we need to answer before we can even
> do specific requirements, let alone start building the replacement
> weo. The 3 that spring to my mind are:
>
> 1) OSS as a point of principle?
> 2) Replicate the current site's model?
> 3) Packaged+customisations or bespoke
>
> Anyone who can think of similarly significant questions (or violently
> disagrees with any of these ones), feel free to chime in.

I read an interesting article on the importance of gathering project
requirements recently ...though for the life of me, I cannot remember
*where*... in which the author's advise *seemed* to imply that
you may have the priorities a bit out of sequence here, Martin :-)

Job one is to agree upon the functional requirements: "A projects (sic)
comes into existence to do something: to have the end result"  To me,
this has always meant the need to spell out and agree upon The Goal.
Good goals can be unambiguously expressed in simple, clear, and
measurable terms.  Normally they specify what the system does, purely
from the customer's, or user's perspective.

The #1 question for this project ('this' being the project that must be
done by January 31st) is: Can our goal be expressed as simply as:

"Porting WEO, front and back-ends, just as they function now, to a
new operating system and relaunching it in new hosting environment"?

Or are there other, functional changes that we need to make to meet The
Goal as well?  I'm going to tell you why I think The Goal should be the
former simple, clear, and measurable goal, rather than the
latter, which necessitates a requirements gathering (ahem! haggling)
period.

Consider that Evolt Corp was your client you asked the Evolt CEO, "Is
the goal of this project to *move* WEO, a custom built, windows-based
CMS written in ColdFusion, onto a Linux server in a new data center?  Or
are you asking us to rebuild it, maybe all the way from the ground up,
adding new features as we go, fixing some old bugs, and implementing a
slew of (your users') long-overdue feature requests and process
optimizations?"

Then consider that the client's answer to this is a noise that you've
likely heard before.  It's called "The Hemmenhaugh", and it goes
something like, "Well... of *course*.  By which I mean yes, er -- you
know, to that whole porting business.  That is obviously what we need.
And that hosting change part.  Oh my, certainly yes; that is a critical
requirement.  And actually now that you mention it in fact, I do have a
list of minor changes right here as well, somewhere.  Small potatoes
things, you know.  Well, we haven't finalized the final list of actual
changes we'd like yet, but they are all minor little things.  No big
deal -- stuff that we just might as well do, while we've got her out of
the water, so to speak.  All easy-breezy stuff.  You should be able to
knock them out in a jiffy, in your sleep, with one hand tied behind your
back... you know, if you're as good as you say you are.   By the way,
did I mention our drop-dead, must-be-done-by date?  Ok, I did.  So yes,
we need the porting and yes to the migration as well, and also, I guess
maybe to some of the feature changes as well, for which we'll get you
the list next week, but you know that we need your estimate and schedule
this Friday, right?  Because you know, we've always been thinking of
changing this feature here, and that functionality, too.  Users are
always complaining about this other thing, and ...I do seem to recall
that our business model is changing too..."  As seasoned, professional
evolters, we've learned to run screaming fast and far away from such
clients, haven't we?

I mean (of course): We don't run away from a challenge.  We manage it.
We gently reassure such clients that, "Yes, of *course* we can make your
deadline and pull off a smooth-as-ice transition, on-time and
under-budget, from both your hosting provider *and* your underlying
legacy technology choices.  We do it all the time.  In fact we guarantee
we'll do it without a hitch!  Of *course* we can and will make you a
hero, Mr. Client.  But.  If you'd *also* like us to first schedule that
pesky "specification" phase, you know, the phase during which we will
attempt to gather all those feature requests from all your users, pry
all those final decisions out of your many committees, manage your
managers, and negotiate the feature negotiations between your multiple
stakeholders, well.  That is going to have an affect on the schedule.
How much of an effect, you ask?   Well, we have to schedule the
specification phase first!  And only at the end of *that* phase, will we
be able to answer that one niggling question about when the work will
all be *done*, you know, not until after we've completed the spec phase,
where we define what work is to *be* done.  You understand, don't you?
It's obvious that we have to gather feature requirements and put
together a functional specification before we can presume to tell you
how long implementing the functionality will take, isn't it?  Anything
less would be a guess.  And we never hand-wave or guess.  That's how
we're able to always be on time and under budget!  You need us to be on
time, right?

Oh yes.  We *have* to meet the deadline mentioned.  It's set in stone.

Oh.  Well in that case, I have great news for you!  We can skip right
past the specification phase right here.  We can put all those messy,
feature-creepy spec questions behind us, right now, and go straight
into the development tomorrow.  All we have to do is make just one
decision here today: that the current system, as it currently works,
*is* the functional spec!  That means all functional changes, feature
request, even bug fixes are scheduled to start *after* the goals of
this porting and migration project have been met.  Wasn't that fun?

This is a powerful approach to time-limited "migration" projects because
if, right now, *today*, the developers already can have the currently
working system be their single, definitive point of reference for what
their deliverable should look like, and behave like, to define exactly
how it should function, and exactly what features it does (and does
not!) provide, then we are halfway there, aren't we!  We avoid all of
the time-consuming debates, guess work, and proof-of-concept
miniprojects.  Days and weeks can be saved by simply separating clearly
defined goals from muddy, ill-defined ones that are subject to debate
disagreement, discussion and experimentation.  Yet clients always seem
to feel the need to lump lots of small, ill-defined feature-changing
projects into a larger, easily understood one, such as a migration like
this.  But they do understand one thing: the importance of meeting
deadlines.  You can move right from RFP to development in an afternoon,
if you can limit the scope of a migration or relaunch like this.  A
thorough spec can easily take a third to half (or more!) of the time on
a large or complex project.  So you can take them half way there with a
single simple management decision!  Your clients with scary deadlines
will always find such timely progress very reassuring.

:-)

But wait!  What if I told you that there's more!  With all the time we
just saved finishing up the spec right here, and limiting the scope to
something sane, we can add to the deliverables!  How about a few
incremental improvements, not to the app, but to the development process
of improving the system in the future?  Like bringing everything under
best practices like version control, release management and
configuration management?  What if now, for free, we can deliver the
system sooner, and in the process factor out those niggling hard-coded
configuration values and other design bottlenecks that have made it
difficult or impossible to easily setup multiple "sandbox" development
environments?  Then we can prototype, add, test, and debug each of those
new features they need in ~parallel~, so that they can be tackled by
multiple developers, isolated, tested and completed separately, so
that delays of one don't hold up the others in an all-or-nothing way,
and in the end completed even *more* quickly, right away in fact, after
we complete the migration?  ~Then~ would you approve deferring the
functional changes until after the immediate deadline?

You clever evolters know what I'm describing is just scope limitation
and expectation management, sugar-coated perhaps, and with a dose of
pre-planning for some ongoing maintenance work, easing the client into
the subsequent add-on sales represented by their next feature request,
and the next, and the next... :-)

But I do think, Martin, that your first question (Preferred Licensing
Philosophy) and the third (Buy vs. Build) must come *after* the
gathering (and more importantly, limiting) of the functional requirement
goals.  I don't know myself what the Evolt article submission, revision,
and approval process looks like, behind the scenes.  I read the Content
list and have some vague notion, just that there *is* a process really,
and that there is some sort of user management with role-based
permission system.  I'm sure the more I used them, or the more code I
saw, the more I'd ~want~ to do a complete rewrite from the ground up.
But that's just me.  I want to rewrite the world :-)

Without having ever seen them though, I submit that they are serviceable
for the time being, by virtue of the fact that articles are currently
successfully submitted, do get reviewed, revised and either approved and
published or rejected all the time on the existing WEO, complete with
whatever warts it may have.  So whatever clever and compelling
improvements may have been conceived, after having used the system now
to do lots of real work, it currently does work.  Whatever bugs and
unnecessary inefficiencies may exist in process, they are apparently not
without workarounds an are not impossibly difficult to live with for at
least a *little while longer.  And however ~important~ we think it might
be to get started implementing these improvements, they can only really
delay the achievement (on time, and under budget) of the mort ~urgent~
goal, that being relocating the whole kit and caboodle to a new box at
a hosting provider far, far away, running on a completely different
operating system, and to do so in such a way that we don't lose anything
that we currently have, or suffer any significant downtime.  After that
move is done, I think, is when we should start adding features and
rejiggering the underlying functional models and workflows.

I do tend to rant, don't I?  I wish I was as long-winded a coder as I am
a commentator :-)

-dave, Ruthless Self-Appointed "Scope Czar"