Infrastructure (physical) projects versus IT projects, The widening gap?
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
In reading the various comments I see that there is a significant difference in perception and process between the management of building (physical infrastructure ) projects and IT (software) development. The traditional project implementation approach is essentially linear for building projects - define needs, concept development, preliminary design, detailed design, construction, commissioning, closeout and finally startup - although there can be fast-tracking with some concurrent tasks. The consequence of changing or adjusting the deliverable (product) on the fly in many cases is cost prohibitive once construction has started. You can't change concrete to steel half way though or add a floor, etc.
One cannot rely on the concept of "if something isn't working, we'll fix/adjust it later"
I am not sufficiently familiar with the delivery of a IT project to analyze in detail but it seems to me that going back and changing some coding is less onerous than taking a wall down, changing a building foot print or moving a bridge. IT project delivery can take more risks as consequences are less expensive to mitigate.
What I'm getting at here is that building projects require more planning, greater effort at the front end.
One project management process or methodology does not apply equally in all cases. Saving Changes...
Tim PodestaDirector of PM/PMO| Former BP- now IndependentPenn, Bucks, United Kingdom
Mar 06, 2020 11:42 PM
Replying to Sajeev Kumar Menon
...
A lot of change has taken place in infrastructure projects too with prefab and modular construction leading to shorter timelines. There may be a difference in product in different domains but there are also similarities in the different phases and lessons learnt
There is also AWP - Advanced Work Packaging and use of Data - both are driving more Agility in Traditional Projects Saving Changes...
I am not saying that a project has to be bogged down in process and procedure. What I am proposing is that we make choices based on a proper assessment at the start of a project. The only process that is necessary is a comprehensive risk/benefit assessment, every thing else follows from that. If the risk is such that it warrants mitigation measures so be it. If not, again so be it. If Lean is the most effective management model to deliver, adopt it. If the projects lends itself to a more traditional approach - that's the way to go.
The idea is to let the project dictate the delivery model rather than the delivery model dictate the project.
"let the project dictate the delivery model"
Hi Peter,
The problem with having a "project specific" delivery strategy is that in most cases IT "projects" don't actually matter very much. Software products tend to continue evolving and have a life independent of projects. If your delivery approach is tied to a project then what will you do when the project ends? Often what's more important is having a sustainable delivery strategy so that you can continue delivering business value indefinitely even though different projects may come and go. If your product development teams have a sufficiently robust and productive operating model then altering your delivery strategy to suit the limited-term needs of a particular project seems (to use the English idiom) a bit like the tail wagging the dog rather than the dog wagging the tail.
Under the Scrum framework, it's said that each sprint can be considered a separate project in its own right. If you have that mindset then projects disappear into the backlog and products are what you are left with.
...
1 reply by Peter Rapin
Mar 16, 2020 5:14 PM
Peter Rapin
...
I suppose I'm struggling a bit with the definition of a project. In my traditionalist world a project has a beginning and an end with delivery of a specific solution to address a stated need usually with specified constraints (time and costs). Once the need has been fulfilled the project is closed. There may be situations where a project is extended to address more or new related needs but my preference is to recognize such as a new project. Typically with physical infrastructure (bridge, road, building, power station) one does not continue applying effort once the initial requirement is delivered. Expansions are the subject of new projects.
I see that IT project delivery can be an ongoing effort with intermediate deliveries but no specific end. I can see that different management models can, and most likely, should be applied.
Saving Changes...
Tim PodestaDirector of PM/PMO| Former BP- now IndependentPenn, Bucks, United Kingdom
Mar 07, 2020 10:50 AM
Replying to David Portas
...
One important difference with a software product is that there's typically no strong reason to reach or aim for a "finished" state. Technology usually keeps evolving until the time when you finally stop using it at all. For that reason, the emphasis when working on software tends to be on products rather than projects. Arguably a software "project" is a bit of an anti-pattern because it means that at some point you expect to stop delivering improvements to the product.
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. Saving Changes...
Peter RapinSubject Matter Expect; Project Delivery| Independent ConsultantOntario, Canada
Mar 13, 2020 2:51 PM
Replying to David Portas
...
"let the project dictate the delivery model"
Hi Peter,
The problem with having a "project specific" delivery strategy is that in most cases IT "projects" don't actually matter very much. Software products tend to continue evolving and have a life independent of projects. If your delivery approach is tied to a project then what will you do when the project ends? Often what's more important is having a sustainable delivery strategy so that you can continue delivering business value indefinitely even though different projects may come and go. If your product development teams have a sufficiently robust and productive operating model then altering your delivery strategy to suit the limited-term needs of a particular project seems (to use the English idiom) a bit like the tail wagging the dog rather than the dog wagging the tail.
Under the Scrum framework, it's said that each sprint can be considered a separate project in its own right. If you have that mindset then projects disappear into the backlog and products are what you are left with.
I suppose I'm struggling a bit with the definition of a project. In my traditionalist world a project has a beginning and an end with delivery of a specific solution to address a stated need usually with specified constraints (time and costs). Once the need has been fulfilled the project is closed. There may be situations where a project is extended to address more or new related needs but my preference is to recognize such as a new project. Typically with physical infrastructure (bridge, road, building, power station) one does not continue applying effort once the initial requirement is delivered. Expansions are the subject of new projects.
I see that IT project delivery can be an ongoing effort with intermediate deliveries but no specific end. I can see that different management models can, and most likely, should be applied.
...
2 replies by David Portas and Vladimir Liberzon
Mar 19, 2020 3:11 AM
David Portas
...
Hi Peter, You are right about projects. That is the root of the "widening gap" being discussed here. Projects have an end, which in the case of physical infrastructure is understandable. But in the case of software it's not so significant, firstly because improvements can be delivered a small piece at a time and secondly because the opportunities are effectively boundless, so why would you ever want to stop making improvements?
If someone wants a new feature in a system then the best response is generally "what's the business's priority?" not "we need a new project".
Mar 20, 2020 4:06 AM
Vladimir Liberzon
...
Hi Peter, you are right.
I usually tell to my "students" that initial development of the first release of new software is classical project that must be managed using "waterfall" (I don't like this wrong term) but future improvements can use "agile".
It makes sense to divide projects and improvements as activities that require different approaches.
I suppose I'm struggling a bit with the definition of a project. In my traditionalist world a project has a beginning and an end with delivery of a specific solution to address a stated need usually with specified constraints (time and costs). Once the need has been fulfilled the project is closed. There may be situations where a project is extended to address more or new related needs but my preference is to recognize such as a new project. Typically with physical infrastructure (bridge, road, building, power station) one does not continue applying effort once the initial requirement is delivered. Expansions are the subject of new projects.
I see that IT project delivery can be an ongoing effort with intermediate deliveries but no specific end. I can see that different management models can, and most likely, should be applied.
Hi Peter, You are right about projects. That is the root of the "widening gap" being discussed here. Projects have an end, which in the case of physical infrastructure is understandable. But in the case of software it's not so significant, firstly because improvements can be delivered a small piece at a time and secondly because the opportunities are effectively boundless, so why would you ever want to stop making improvements?
If someone wants a new feature in a system then the best response is generally "what's the business's priority?" not "we need a new project". Saving Changes...
Vladimir LiberzonR&D Director| Spider Project TeamMoscow, Russian Federation
Mar 16, 2020 5:14 PM
Replying to Peter Rapin
...
I suppose I'm struggling a bit with the definition of a project. In my traditionalist world a project has a beginning and an end with delivery of a specific solution to address a stated need usually with specified constraints (time and costs). Once the need has been fulfilled the project is closed. There may be situations where a project is extended to address more or new related needs but my preference is to recognize such as a new project. Typically with physical infrastructure (bridge, road, building, power station) one does not continue applying effort once the initial requirement is delivered. Expansions are the subject of new projects.
I see that IT project delivery can be an ongoing effort with intermediate deliveries but no specific end. I can see that different management models can, and most likely, should be applied.
Hi Peter, you are right.
I usually tell to my "students" that initial development of the first release of new software is classical project that must be managed using "waterfall" (I don't like this wrong term) but future improvements can use "agile".
It makes sense to divide projects and improvements as activities that require different approaches.
...
1 reply by David Portas
Mar 21, 2020 9:22 AM
David Portas
...
Hi Vladimir,
Many people do successfully use an agile approach to develop entirely new software. Developing new software products was the original motivation behind the agile frameworks like Scrum and XP and is still probably the aspect of agile software development that gets most attention. Other approaches can work as well of course but an agile approach is often preferred because it is particularly well suited to a "greenfield" situation: early and continuous delivery, empiricism and close collaboration all being great ways to mitigate delivery risk, deal with the unexpected and maximise the chances of being on time, on budget.
I mention this only because I wouldn't want my previous answer to be misunderstood as advocating agile methods only for product maintenance/improvement.
Hi Peter, you are right.
I usually tell to my "students" that initial development of the first release of new software is classical project that must be managed using "waterfall" (I don't like this wrong term) but future improvements can use "agile".
It makes sense to divide projects and improvements as activities that require different approaches.
Hi Vladimir,
Many people do successfully use an agile approach to develop entirely new software. Developing new software products was the original motivation behind the agile frameworks like Scrum and XP and is still probably the aspect of agile software development that gets most attention. Other approaches can work as well of course but an agile approach is often preferred because it is particularly well suited to a "greenfield" situation: early and continuous delivery, empiricism and close collaboration all being great ways to mitigate delivery risk, deal with the unexpected and maximise the chances of being on time, on budget.
I mention this only because I wouldn't want my previous answer to be misunderstood as advocating agile methods only for product maintenance/improvement. Saving Changes...
Vladimir LiberzonR&D Director| Spider Project TeamMoscow, Russian Federation
Hi David,
by my experience initial development requires a lot of architectural work that shall take into account potential future needs. As in any project it is necessary to pass many gates and if initial development did not take into account any requirements that will become urgent later it will lead for redesigning and rewriting everything.
It is necessary to take into account not some of backlog stories but everything that exists and can appear in the future if the software is intended for the long life.
So gates yes, but agile no. The initial development shall be planned traditional way - collect the requirements, determine project scope and MVP, develop MVP and then add new and new features using agile or other ways of continuous iterations.
We are developing the same software for more than 25 years because reserved a lot creating the first version. New versions of our software appear almost each week since 1993. It was not called agile in 90-s. Saving Changes...
