The reason we can't continue using Samba

[Joe Rhett]

> > And you have over and over stated that a timeline isn't possible. Since
> > that effective means you could quite happily deliver in Q4 2002 we can't
> > possibly count upon having Samba function in any realistic part of our
> > organization.
> 
> 	Would you rather crappy Microsoft-esque code be released this month, or
> professional quality code be released "when its ready".
 
I'm only going to justify my statements ONCE to someone who clearly hasn't
had to write a project plan, or meet deliverables within timeframes. 
(Otherwise you wouldn't ask the question)

If you choose a bad vendor and implementation problems result, at the very
least you have a know reason for failure. If you have a known timeline for
delivery of X, you can't keep standing around hoping that some dependant
resource Y will become available. For this purpose a schedule that isn't
met is actually BETTER than no schedule at all! With a known schedule that
slips, you can easily adjust your timeline based on the vendor's slip.
Without any timeline at all, you can't possibly write your own timeline.

Anyone who has even maintained a project plan based on Microsoft product
release schedules knows quite well how to plan around them. They are
scarily consistent in their product release slipage, their product
instability period, etc. It's quite easy to write a project plan based
around a Microsoft release date.

NOW      -- Review final features list, verify that it meets needs
01/01/01 -- Projected release
**/**/** -- Redesign infrastructure for implementation
09/01/01 -- Estimated actual release
**/**/** -- Play with product in test lab, verify required features
12/01/01 -- Estimated stability date
**/**/** -- Move to a small subset of test users
03/01/02 -- Rollout to general population


YES, I'M ESTATIC THAT WE DON'T HAVE TO DO THIS SAMBA CODE. However, the
samba implementation plan looks like this:

NOW      -- Wait
**/**/** -- Alpha release 1
**/**/** -- Verify functionality -- e-mail to find out that some is still coming
**/**/** -- Alpha release X...
**/**/** -- Verify functionality -- more e-mail to find out that more is coming
[loop last 2]
**/**/** -- Beta release 1
         -- Verify functionality, implement in test lab
         -- Write up design plan for infrastructure changes

**/**/** -- Production release
	+ 1 day -- Verify functionality, implement in test lab
	+ 30 days -- Rollout to a small user set in isolated environment
	+ 60 days -- Start infrasture redesign....


Do you see the problem with this? No dates to work on anything with, and we
rarely get a full confirmation of the intended feature set before the beta
release. THAT is the problem.

-- 
Joe Rhett                                         Chief Technology Officer
JRhett at ISite.Net                                      ISite Services, Inc.

PGP keys and contact information:          http://www.noc.isite.net/Staff/