Do you know about the two types of engineering projects?

Or project manager vs  task master?

When you think about engineering projects, they often look neat on paper. There are tasks to complete, resources to allocate, milestones to hit, and a path that seems clear from start to finish. The sort of thing they teach you about in your degree and in things like the project body of knowledge. This is one kind of project. It is the idealised project where the uncertainty is limited, the risks can be calculated, and the outcomes can be predicted with reasonable confidence. Build a standard bridge over a short span, design a stationary gearbox to transmit a set amount of power, or create an electrical filter to cut out unwanted frequencies. These kinds of projects are about precision, planning, and execution. Tools like Gantt charts and resource allocation models work perfectly here. A well run project of this kind moves like a finely tuned machine, and can finish on time and under budget.

The other kind of project is very different. This is where uncertainty dominates, not just in terms of probability but also in terms of what the risks even are. You cannot easily predict the path because the terrain ahead is unknown. Think about developing a new type of bridge to cover a much larger span before you even know what kind of foundations the soil can handle. Or designing a gearbox that needs to be lightweight but still work with a motor and duty cycle that have yet to be defined. Or an electrical filter circuit that must limit radiation exposure to other circuits that are themselves still evolving. In these projects the list of tasks changes as quickly as your understanding of the challenge. Engineers in these projects often complain that documenting takes time away from the work itself, because doing the work is how they discover what needs to be done next. This is coevolution, where your grasp of the problem grows alongside your grasp of the solution. Sometimes all you can do is have a list of tasks - as I mentioned in my book The Global Engineer.

In truth, most projects sit somewhere between these two extremes. Which is why, if you are managing a project, one of the first things you should do is place it along this spectrum. Is it closer to the predictable side where documentation and resource planning make sense, or is it closer to the exploratory side where constant adaptation is needed? If you get this wrong, you risk either over-controlling work that requires flexibility or under-managing work that needs tight coordination. You might even find that different aspects of the one project sit in different points on the spectrum, and need different approaches.

For the global engineer this becomes even more important. What seems routine in one place can be uncertain in another. An engineering team that has solved a problem many times before might treat it as predictable, while in a different environment the same problem requires exploration and discovery. Your role is to see where the project really sits, not just from your perspective but from the perspective of the team you are working with. Only then can you match the way you manage to the kind of project you actually face.

What techniques have you learned when managing projects; have you ever felt let down by the standard tools of project management and not known why?