Infrastructure (physical) projects versus IT projects, The widening gap?

In the case of the Website, although it's cheaper than building a house, still it will not just a matter of refactoring the code, depending on what type of website is it? is it a knowledge work project, for which sector/industry are you creating this website and so on and so forth... and schedule is also one of the deciding factor.

Dear Andrew,

You could also look at this as the upside of the construction industry that it does not lend itself naturally to change in a project.

It is up to the project manager to get everything right first time around which can make project manager less susceptible to being sloppy, complacent and risk tolerant as in other sectors there is scope and room for mistakes and errors to be tolerated and be called additions and project change.

Change management should be the exception not the norm and I would be a proponent of striving to spending the time in the planning stage to avoid unnecessary time being spent on vaguely draft project documentation.

Daire

There is also AWP - Advanced Work Packaging and use of Data - both are driving more Agility in Traditional Projects

A great point David.

My experience is there is also a finished state with an IT project - though its shape may be moulded as part of the Agile process.

In the same way an infrastructure project may need to adapt in an agile way where novel technology is being used or there is complexity in the project or unknowns arise.

I agree the traditional 'waterfall' approach to projects is becoming more 'agile' - with more technology challenges to deal with (including IT) and more complexity to deal with. I am developing thinking about the Agile Waterfall and a presentation to my colleagues at the London PMI Toastmasters - so thank you for your thoughts.

What you wrote is what I faced from years. Mainly when you worked in companies which are selling services then the sales people make all the proposal and after it is signed then go to you saying "hello, here is what you are in charge to deliver". I have adopted several strategies including it in one hugh, very hugh organization I have the opportunity to change this behavor pushing that everything must be signed by three key roles: finance, professional services, sales. if not, it can not moving forward. But, at the end, perhaps the strategy you can follow is detecting the associated risks, the impacts, and assigned them to the people that have created the risks because they created the situation. Remember that all estimations are dynamic because the information you have at any time will impact on the estimation.

I don't believe it is cost-effective to develop a project management plan before the project charter. I've written business cases that never became projects. If I had written the project management plan then, that would have been additional sunk costs.

I agree that when you are 'handed' or 'inherit' a project the first action is to undertake an honest risk assessment for two main reasons: 1) let those in power know what the project is facing; and 2) identify mitigating measures to minimize risk impacts and maximize benefits. I prefer this to waiting for project derailing and providing reasons which may be interpreted as excuses.

However it would be much more effective if the initial project plan actually fit the project.

It is understandable for an organization that is not project oriented (one-off) to start on the wrong foot but for an organization that earns a living on delivering projects, the corporate risk management plan should identify the need to have a project management expert participate from the onset. As a client I have often asked that a high-level project risk management plan be included in proposal submissions. Some say that by requiring a proponent to consider risks the initial proposal cost can only go up. That may be but in the long run project delivery will be more effective and have a higher probability of achieving the cost, time and quality objectives.

I feel your pain! I once worked for a company that delivered products that directly impacted major construction projects. Sales would promise delivery dates, customization of the product, and other things without consulting with the project management group. Then they would make the PM responsible for delivery on time. Furthermore, the PM was not allowed to talk directly to the design team that affected the customization or to the vendors that delivered the necessary components to deliver the end product. Pretty much it was a loose loose situation.