The distinction between programs and projects is clear in this example. Preparing a business case for work costing over $1billion and multiple years duration is going to be full of risks. This is a great example of how programs can be multi-year, and contain many projects, all with the same end goal. The vision of the program here would be to have a single digital patient record, but it may take 10 or more succinct projects to get there. Having discrete projects with clear outputs makes them easier to scope and cost, and also more likely to succeed. Managing the dependencies between them is a key element of program management. This layer of governance above the project ensures all roads lead to the overall program vision.
Of course hiring one contractor to do all of this in one go gives you a small pool of options, and can lead to gold plating of the pricing. It makes the tendering process almost pointless when very few can compete for work of that scale.
Complexity is inevitable when integrating data from multiple sources and working with legacy systems. The risk of scope creep is very high, and as such, budget and timelines will also blow out.
Reduce the risk of cost over-runs by treating this as a program rather than a project.
