Dear Bob ... I feel that IT projects are different in kind and degree from non IT projects and while they benefit from standard project management techniques (PMBOK, etc), that is not sufficient to increase the probability of success more than a few percent. Do you feel there are any significant diffences in IT projects? and what are they (if any)? - Old timer Dear Timer ... It depends entirely on how you define Dear Bob …I feel that IT projects are different in kind and degree from non IT projects and while they benefit from standard project management techniques (PMBOK, etc), that is not sufficient to increase the probability of success more than a few percent. Do you feel there are any significant diffences in IT projects? and what are they (if any)?– Old timer Dear Timer …It depends entirely on how you define success.If, by success, you mean creation of all defined deliverables within specifications, budget, and schedule, then I’d have to disagree with you. Software development projects aren’t all that different from any other kind of project. It’s rarely that simple, though, and that’s where I think you’re going with your question. There’s a difference between typical software projects and other kinds of project on each end of the timeline. For comparison, let’s take a new building.A construction project generally starts with the groundbreaking ceremony, and is considered successful when the building is ready for occupancy. Whether the building is profitable is someone else’s problem. A software project, in contrast, typically starts with the feasibility study and isn’t considered successful until the software is in productive business use.Which is to say, the software project has to include the equivalent of the architect’s initial sketches, construction of the scale model, drafting of all blueprints, and approval to build. It also has to include the whole process of moving in. No wonder software project completion rates are so dismal: IT is expected to estimate the cost of the building before drawing the blueprints. The solution, by the way, isn’t very difficult: Don’t do that. Make each phase a separate project. Among the deliverables of each phase are the statement of work and estimate for the next phase. That keeps IT from having to estimate something that hasn’t yet been scoped out.Then there’s the back-end: Building construction is successful when it’s ready for occupancy; the IT project isn’t done until the business has “moved in.” There’s really nothing to solve, here. What is needed is for everyone involved in the project – business sponsor; project team, and end-users – to understand they’re in a collaboration that doesn’t dissolve until after testing is complete, a pilot implementation is done, additional fine-tuning of the software has been performed, everyone has been trained, and the software is in full production.But from a project management perspective, all of those are little more than additional project tasks. I’m not sure if this answers your question, but it’s the best answer I have.– Bob ——– Technology Industry