Dear Bob ... With respect to "How to rescue a project," I don't consider the lack of a project plan to necessarily indicate some kind of bad disease related to the project. It could be that the project is being run in a particularly "agile" fashion -- after all, what's the point of trying to figure out when the project will be complete, if it won't be delivered (= declared done) "until it's ready" and the first Dear Bob …With respect to “How to rescue a project,” I don’t consider the lack of a project plan to necessarily indicate some kind of bad disease related to the project. It could be that the project is being run in a particularly “agile” fashion — after all, what’s the point of trying to figure out when the project will be complete, if it won’t be delivered (= declared done) “until it’s ready” and the first N deliverables are planned to be “first steps” toward the eventual goal?I would think that an “agile project” would normally be able to point someone to a list of goals and customer participants, and the set of items in the next scheduled deliverable. There’s nothing that indicates that the writer looked for any information like that; he seems to think that any inquiry would be unwelcome. In any case, that would probably not, however, give the writer the information he wants. But why should someone whose job is “infrastructure” need to be involved at that level? Perhaps the resulting system will not be “rolled out” to a significant number of people for quite a long time — not until perhaps 10 or or even 20 2-week iterations have been completed — and thus the requirements for any significant change to infrastructure (even if eventually needed) won’t gel until nearly a year has gone by. I admit that the people who are running such a project would do well — for the comfort of others not directly involved — to have at least _some_ information available to others who are being asked to participate (even if only peripherally). However, one idea behind running projects in such an agile fashion is to avoid wasting time preparing a lot of “obsolete next week” documents that don’t add any value for the team that’s actually doing (or requesting) the work.I haven’t read a lot of your Advice Line columns, so I don’t know what (if anything) you’ve said about agile methods. My attempts to find any of your columns (using the Google search of InfoWorld.com) with either the word “agile” or “agility” have not succeeded. Can you point me to something?– Agile guy Dear Agile …I haven’t written a lot about agile methodologies because I don’t have enough first-hand or once-removed experience to be comfortable that I’m neither contributing to meaningless hype nor just crabbily objecting to something because it isn’t something I’ve done.Having said that, what I know about agile application development methodologies puts them squarely in line with a lot of what I have written about (you’ll be more successful if you look in the KJR archives on www.issurvivor.com than in Advice Line). A lot of the fundamentals have been around a long time, and have been ignored by the mainstream for nearly as long: That every big system that works started out as a small system that worked, for example, and the desirability of extensive, close, informal communication between developers and business users. I’m less comfortable throwing out traditional project management disciplines, and I draw a strong distinction between application methdologies and project methodologies. If a project team doesn’t understand what it’s supposed to produce and when it’s supposed to produce it, I’m skeptical that the result will be timely and useful. That requires a schedule, resource plan, scope, and defined goals and deliverables.Not long ago I helped out a client with a project. When I arrived on the scene the project manager told me, “We’re running too fast to have a defined methodology or project plan.” It was a correct statement, only the track they were running on was circular and very small – they were chasing their own tail. By the time I’d persuaded them to define a process and project plan the project had arrived at its original due date with effectively no progress made. After creating the process and plan, the project took the originally planned time to complete.As for when to involve infrastructure, I’ve seen too many cases of, “This won’t have any impact on our infrastructure,” followed by various forms of disaster. Capacity planning is only one reason to involve infrastructure from the beginning. There are quite a few others – from the need to establish an appropriate testing environment to ensuring the new application doesn’t make incorrect assumptions about system availabilities. As I say – I’m not sufficiently expert in the subject of agile methodologies to be sure my opinion is valid. But I’m pretty sure …– Bob ——– Technology Industry