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"