Complexity in mega IT projects

“Everyone thinks they are the big boss,” says Laura Aziz. “Everyone thinks they are managing the others.” It’s one of the complexities that Laura is managing as part of putting the IT systems into a massive 7-star hospital in the Middle East: complete with wifi, electronic mediccal records and video conferencing. It’s a multi-year, multi-phase project with a multi-layer matrix structure providing the chain of command. The technology is complicated, but the people side of things also takes some managing. “Technology alone is not enough,” she adds. “Hopefully the combination of technology and peole will carry us through. It’s something we work with every day.”

Laura puts a definition of complexity on the screen:

“Complexity is often tied to the concept of a system – a set of elements which have relationships among them. Complexity expresses a condition of numerous elements in a system and numerous forms of relationships among these elements.”

She defines a complex project as having:

  • A number of complicated inter-relationships
  • Interdependencies
  • A number of unknowns
  • A degree of uncertainty

Laura’s Microsoft Project plan has 7000 lines and a duration of 5 years – and that’s just the IT stuff. Nothing on there (or in that timeline) relates to the actual building of the hospital. In order to even get a handle on what that meant she had to set up an IT project management office. They have had to build an approach to risk, quality and set up operating models where there were previously none. However, she’s “still not satisifed” with the tools that the PMO has in hand. They use Microsoft Project for scheduling and Outlook. “They are not helping us necessarily cut down on complexity but at least it is helping us keep things under control.”

The IT PMO is now 12 people, and Laura talks about the difficulty of getting the right knowledge and expertise. “You need to think about staff motivation if you want your team to stay with you for four or five years, until you go live” she says. She hopes that some of the technical team will stay on after go live as well.

Staff motivation doesn’t seem to be a problem: there is a whole host of new and exciting technologies to play with. The IT inventory at the hospital-to-be stretches to 250 applications. The hardware includes all the usual network and infrastructure stuff, plus some more modern gadgets: hand-held devices, RFID, bar coding, and a full suite of patient entertainment systems. Then there is all the clinical equipment.

Clinical workflow is also a consideration. The hospital needs processes to handle inpatients, outpatients and clinical order forms. There’s a double loop feedback system in place to ensure that the requirements are fit for purpose. All the IT systems are going through two cycles of integration testing because a clear data flow is so important for patient safety.

It all sounds really modern and exciting, but the hospital opening is several years off and medical technology evolves at a rapid pace. Laura says that she understands what is currently cutting edge will be two years out of date before the hospital goes live. The suppliers are all under contract to provide the latest versions of software and clinical equipment, so she is effectively working without knowing the full extent of the future IT estate. The unknowns in the IT space are also adding to the complexity of her project.

Unusually for an IT project, the schedule has a full year after systems go live before the project structure closes down. The hospital is due to open at the end of 2012, but the IT effort carries on for another 12 months. It’s a period of bedding in, stabilisation, maintenance and evaluation. I think this is a valuable lesson for other projects: you can’t close down a 4 year piece of development in a couple of weeks. Given the scale and complexity of the IT systems going into the hospital, another year after go live to manage the handover to operations seems very sensible.

Even if you aren’t managing a super-complex mega IT project, there are lessons here that can be scaled down to your IT implementation, especially around team motivation and effective handover processes. Laura’s hospital is going to be amazing when it’s finished, and I’m sure her team will leave it behind with a huge sense of achievement – and a whole lot of learning about how to cope on a project where the IT is shifting all the time.

Laura was speaking at the PMI Global Congress North America. Her presentation was titled “Building a Cathedral: Managing Complexity in Mega Projects.”


  1. The world of projects is broad and deep. A “typical” program (project) in our domain has a MSFT project file(s) of 20K to 30K activities. Not all are active at one time of course. Rolling waves are used. But the Planning Packages collect the future work’s cost and top level duration.

    Managing 20K to 30K activities requires care and discipline. MSFT Project is not the best tool, but it is a popular tool.

    Other programs we work have 5K to 10K activities, but are embedded in larger master schedules.

    The critical success factor for our domain is to have an Integrated Master Plan (IMP) that drives the Integrated Master Schedule. Here’s a top level guide for this paradigm:

    [link no longer live, removed 8 May 2015]

    The key is to measure “increasing maturity” not the passage of time or consumption of resources.

Leave a Reply

Your email address will not be published. Required fields are marked *