My Project is Harder than Your Project

Over the years that I’ve been attending project management events, I’ve heard project managers from various backgrounds comparing their projects in an effort to see whose project was harder to manage.  Typically, these PMs are men – perhaps it is part of the genetic makeup of men that many feel the need to compete with each other to establish some type of social hierarchy.

What I’ve noticed is that there are two typical results of these comparisons:  either both projects are in similar industries and are therefore somewhat comparable, establishing one as clearly larger or more complex than the other; or the two projects are of a completely different nature, with little that can be directly compared.  I most commonly see this latter occurrence when one is an engineering or construction project, while the other is an IT project.

When two projects are of a similar nature, we often use budget or team size as a means of comparison.  This falls apart when comparing projects of different types; for example, a $10 million software development project is a rather large, complex project of its type but a $10 million expansion to a chemical plant would be a fairly small engineering/construction project.  So when an IT project manager brags that he’s managing a $10 million project, the engineering/construction project manager chuckles thinking that the IT project manager must just be a beginner to brag about a project of such a small size. We look at team size in a similar way: an IT project with 70 people on the team and four vendors would likely be a fairly-complex project; however, even fairly straight forward construction projects could easily have hundreds of people working on them with dozens of vendors.

This does not mean that construction projects are generally harder to manage than IT projects.  We need to look at other factors, since budget and team size seem to be calibrated differently in the two project types.  If we look at what is really driving the project management complexity in the different project types, we find that the complexity in managing IT projects comes from the lack of clarity in requirements/scope, while engineering/construction projects are challenged by large numbers of vendors, each with their own unique contract to establish and manage, and the complexities of coordinating the work of so many independent project participants, each worried about meeting the terms of their own contract, not necessarily the needs of the project as a whole.

Requirements and scope in engineering/construction projects tend to be simpler elements to manage.  Building codes and other government regulations largely reduce the misinterpretation of requirements by restricting the range of possible options allowed.  Also, scope completion is easy to verify (e.g. “Is the foundation done, or not?”).  On IT projects, however, scope is typically more challenging to define.  The output of a software development project is intangible and many people have a hard time describing the vision of what they want, leading to requirements misunderstandings.  Construction projects resolve this issue by using modeling techniques such as sketching elevations (“artists’ concepts”) and creating 3-D models in a CAD package for simulated virtual walk-throughs of the design prior to construction. The modeling techniques used by IT projects tend to create complex diagrams that require special training in UML to be able to understand.  Certainly, some of the common IT models will work for you but many of them will just confuse the uninitiated.  As a result, an IT project manager will spend a large portion of their management time explaining the project scope to various team members and stakeholders

Vendor and contract management are critical on engineering/construction projects.  Even when running a project to design/build a single family home, the project manager will have many, many separate contractors to manage.  Continuing our single family home example, the foundation could involve over many contractors: one to survey the site, one to dig the foundation, another to haul away the dirt, a carpenter to frame up the forms for the footings, another to bring in ready-mix concrete to pour into the footings, a company to set up and later strip the forms, another to pour the foundation wall concrete, a building inspection, probably a progress inspection/assessment for the construction finance company.  Each of these contractors would have their own unique contract with a scope of work, terms and conditions, and a schedule that would need to be coordinated.  One of the main roles of a construction PM is the coordination of these schedules and the coordination of the scope statements to ensure that nothing gets missed or “falls between the cracks.”  IT project managers may have vendors on their projects, but typically it is one or two firms even for fairly large, complex projects, so the contract management aspect on IT projects is much diminished.

So, the real underlying argument that should be made to compare two projects of different types should be the comparison of the level of scope clarity with stakeholders versus the number of vendor contracts to manage. This is a more difficult comparison – it is like comparing apples and oranges – and usually leads to a stalemate. While I usually see no winner in these debates, it does lead to some very interesting discussions.

I think we each have a lot to learn from project managers from other industries who face very different challenges from what we typically find on our own projects.  Few project managers have experience across project types and the ones who do are usually highly valued by their employers. 

Talk to your peers from other industries and learn from them what you can about what makes their own projects complex.  I am sure that by doing so you’ll mature in your understanding of project management and perhaps you can take away a few tips to try on your own projects.