This is a fascinating paper. How large projects are viewed. And when we talk large, I am talking very large, heading into the hundreds of millions to billions of dollars of revenues and/or costs. How you look back at them is fascinating. But the abstract first
Looking at historical projects has much to offer our understanding of project management, for both research and practice. However, there are important challenges in how alternative narratives about such projects are reconstructed and related to each other. To explore these challenges, this paper uses the example of the Thames Tunnel project, completed under the direction of Marc Brunel in 1843, and reputed to be the first tunnel to be built under a major river. In telling the story of the project, we focus on five alternative discourses: technico-rational; practice; networks of people, things, and ideas; politics; and society. The common response to such variety is either to attempt to construct an overarching meta-narrative, or to explore the differences as a way of highlighting the localized and contingent nature of knowledge about projects, or adopt some intermediate position somewhere on the spectrum between these two extremes. Instead we seek a different route grounded in a sociology of knowledge that
acknowledges simultaneous, provisional, and contested processes of division and stabilization in the ways that epistemic communities constitute knowledge through their own narratives and practices. These have implications for the stories that are told about project management and,
crucially, the activities and interests that both shape and are shaped by such narratives.
when one is leading these, the narrative is very important, one has to have control over the narrative. the impact of these projects live very long on and if they go belly up, then the organisation will rarely do any more of these.
This article talks about one of my hero’s, Isambard Brunel and his father and how they used the first tunnel excavation machine to build the Thames tunnel. I wont go too much into this, but some lessons learnt for me. Keep an iron grip on the overall architecture of the project, without the methodology in place, the project dribbles away and dies. The methodology is what keeps the business benefits on stream, these come on board much after the project has been completed. People will forget the project manager but the benefits keep on accruing long after, but if the architecture is wrong, then it will go wrong very quickly.
Second is that shit happens. Very frequently as Brunel found out. And one has to balance these frankly minor blowups against the overall architecture. If conceptually the architecture is fine and its just a minor blowup then one goes ahead…people will drop off, resources will be reduced or increased, stuff keeps on happening..
fun times but one has to be insanely confident to keep driving this, keep the big picture in one’s head and keep driving..