How managing large projects differs from the projects that are spun up in general in IT companies. There are 5 angles that need to be considered when talking about different project sizes and we are going to dive in each of them. I will gladly share the challenges I've met while leading a large project for the first time. The project I refer to is a migration of 300 components to a new platform, which spans over 16 months, which involves 30+ development teams, and which costs >9 M.
Projects that deliver new product features, new Datacenters or new tools in a company are usually either small or medium. However, when we talk about a new end-to-end product, a new Hardware platform or the migration of services on a new infrastructure, it is very likely that we deal with a large initiative. The PM management particularities and processes need to adapt in this cases in order to increase success chances.
Finding a standard to evaluate the project size turned out to be a difficult task as there isn't a standard, generally-accepted measuring system. Companies tend to size their projects in a very subjective way. However, multiple organizations classify the size of a project by the below criteria:
According to PMI statistics, 1 out of 6 IT projects has an average cost overrun of 200% and a schedule overrun of 70%. Therefore, the failure of a large project can put the whole organization at jeopardy. It is really important to be aware, from the beginning, of these implications and adapt your PM style and processes accordingly.
After managing Infrastructure and Software delivery projects for several years, I got my chance in leading a company strategic technical project, migrating the majority of the product applications to a new platform. There are a little over 300 applications that require to be migrated in 16 months, relying on more than 30 delivery teams. The overall cost estimate is around 9M.
10 months into the project I consider that the below areas need to be highlighted as critical when dealing with such a project.
Having a clear objective and definition of done for the project requirements is important in order to avoid scope creep. This statement is valid for small, medium, large projects. However, additional challenges face the latter project, due to the high number of requirements and the multiple ways the DoD for a requirement can be interpreted.
Making sure that the delivery function understands what it has to deliver is a must. Working with just 1 or 2 delivery teams on a scope document can be difficult enough if the requirements can have multiple interpretations, but having 30 teams in different locations working on the same project is madness. A lot of effort needs to be involved in order to align them. Having just a scope document is not merely enough. Multiple workshops and face-2-face time is required to validate their understanding and finite work.
Another challenge with projects that span over long periods of time is locking down the scope. This is essentially impossible and could also impact business objectives. Working in such a rapidly evolving industry like IT is crazy to even consider not changing scope for more than 12 months. The migration project I lead originally started with ~170 components in scope, but due to business requirements for creating new applications to support client needs and some architectural decisions for better resilience, the scope nearly doubled. What is really important in this case is to assess the impact/benefit of each change and go with a request to the SteerCo, so that an informed decision can be taken.
Similar to not locking down the scope, the definition of done for requirements needs to be flexible enough to fold on technical possibilities and ensure a good effort/business value ratio is maintained. The definition of done for migrating a component was a series of KPIs. However, due to the different technicalities of each application, some indicators couldn't be reached without significant effort. The cases where the effort wouldn't have brought enough business value were treated separately, removing some of the requirements with the Sponsor approval.
Imposing a strict DoD would have delayed the delivery of some components with no real business benefit. Therefore, I consider that, in a large project, due to the high number of requirements, a certain degree of flexibility needs to be granted, of course with a clear process that states how caveats can be accepted. This can only be achieved through enhanced communications and a solid change management process.
Creating the project baseline is not very different from any other project. You organize a set of workshops spend time with the team to make sure they understand the requirements, get some high level estimates and build an initial version of the timeline. Of course, as a team gets closer to delivery start and requirements are refined, the timelines are updated.
The challenges start to appear when multiple teams get engaged and start working on the project. When there are ~ 15 teams working in parallel with an average estimate of 4-5 delivery sprints, slippages are very likely to occur. Analyzing the reasons behind each one and assessing whether the slight delays are a real threat for the overall project or not is the greatest challenge due to the large number of stakeholders. For the migration project, establishing a critical path was difficult due to the decoupled nature of work between components. All the work would only tie together at the integration testing period start towards the end of the project, increasing the on-time delivery risk.
The integration period in a large project is both important and difficult to schedule due to the number of teams that need to be involved. Booking roadmap slots for teams that finished the work a couple of months earlier and getting them back in the project is difficult and needs to be planned well in advance. Re-gaining focus is a challenge that can only be surpassed by intense communication.
In a product-oriented company with internal delivery teams, the cost of a project is being tracked mainly as cost per development team X the duration of that work. Therefore, the cost is directly dependent of the number of teams and the timelines.
In a large project this cost can vary a lot depending on time slippages of some teams and the anticipated delivery of others as well. Moreover, working towards a fixed due date increases cost variations as, in order to keep timelines, additional resources could be allocated to fast track the project. Change management and approval processes are key to manage these situations. Transparency and good communication will help eliminating the noise around stakeholders.
A large project means an increased number of risks that require to be managed. It's simple mathematics - increased number of requirements, teams & dependencies translates into a greater number of risks. Therefore, the prioritization of risks becomes critical in order to focus on the right item at the right time.
There are lots of dependencies to be dealt with into a migration project, from infrastructure specific ones to inter application dependencies that require to be dealt and scheduled from time to enable the achievement of milestones.
Good periodization of risks needs to be doubled with an excellent communication with stakeholders. Providing transparency and visibility is critical for stakeholders to understand where the risk they have raised is in the priority list and what is being done to manage it. Additionally, it is very important to have good cross-team visibility as, most of the time, due to the nature of the project; a problem that a team is dealing with right now is very likely to be encountered by another one in a month's time.
Additionally in order to understand the full impact of a risk, it is important to view its probability and impact, taking into account all project areas. Therefore, communication becomes the key. Mitigation plans should be visible to all parties, as these could impact the work on other teams.
In general, my view on Project Management is that it is all about communication. Good stakeholder communication and needs understanding are key for delivering any project. When talking about large projects, the major overall challenge is communication, due to the high number of stakeholders and communication channels.
Stakeholder identification can be difficult due to the number of areas touched by such a project. However, once they are identified, classifying them based on power and project support shown will help highlighting the key persons that you need to focus on.
For a better understanding of why communication is most challenging for the Project Management area in large projects, we just need to refer to the communication channels formula:
Therefore, a small/medium project, which let's say engages 50 stakeholders, has around 1200 communication channels, while a large project, with let's say 200 stakeholders, has around 16 times more channels (20K).
With this great increase in communication channels, the noise around the project is fantastic and it's the PM's job to put a communication plan in place to eliminate it, trying to align the project stakeholders from dev teams to commercial and business functions. Offering transparency on progress, risks and issues will help gain stakeholder confidence and cut down misunderstandings and false alarms as well as bring focus on real issues.
Even though it may appear that the simplest way to keep everyone in sync seems to have large sessions with all representative stakeholders and expect them to disseminate the information down their line, what I've observed is that does not work as expected and it usually brings gaps in understanding.
Therefore, the best empirical approach is Divide and Conquer. Dividing the stakehoders down and grouping functional areas together will help to have more focused discussions and ensure the relevant message is passed further down the line. Moreover, having individual interviews with the main stakeholders of the project will help ensuring their specific needs are managed and keeping up the level of interest.
Large group communications are helpful to provide a good overview of the project, but they need to be very specific and KPI-focused in order to be easy to read.
Managing a large project without professional work management tools is impossible due to the vast number of requirements and parallel work involved. Therefore, in order to communicate in a concise manner, charts and numbers are an absolute must. Additionally, regular catch-ups between technical functions are very important for knowledge sharing and alignment around technical implementation approaches.
It is said that a PM should communicate around 90% of the time. In my view, the larger the project is, the larger the need of communication. All the challenges presented above, from scope, timelines to risk management can be solved via good communication. Provide transparency to your stakeholders and make sure everyone is aligned.
Chat, write, call, shout - Communicate! It's the key!
by Robert Mălai
