Societal Damnation 52: Project Management

I’m sure you’re asking — what’s damning about project management? Isn’t good project management the key to success? After all, without good management, the chances of a project over-running its resource allocation (of time, people, and money), if not failing, increase significantly. Well, yes, it is. Provided you can manage the project.

One has to remember that project management has evolved over the last six decades or so to manage traditional types of projects that produce structures and goods against well-understood designs and project plans, starting with the need to effectively manage complex engineering projects in areas that include construction, defence, aviation, and shipbuilding.

When project management was being defined, the ENIAC was still in operation, Procurement was placing an order against a printed catalogue, and a company imported a small number of commodities in which they had contacts and expertise. There were no complex software projects, no complex Just-in-Time supply chain projects, and no automated factory mega-projects (which resulted in some of the biggest supply chain failures in history).

And, more importantly, projects were focussed on the production, or acquisition, of a single structure, product, or report. They had a defined beginning, a defined end, used well understood resources, required people with well-understood skill-sets, could be scheduled with reasonable certainty, and required a comprehensible amount of money.

Where software development is concerned, there is a rough definition of what is desired, but the beginning and end is a best estimate that is no more accurate than a wild guess in some cases, the resources required (while defined as software architect, developer, network specialist, etc.) are not well understood (as a non-skilled software architect cannot define what makes, or identifies, a good software architect), and the amount of money required is relatively unknown (due to uncertain work effort requirements, unknown support requirements, etc.).

And that’s just software. When it comes to supply chain, the difficulty is intensified. There’s the management of the sourcing, the management of the negotiation and contracting cycle, and the management of the procurement. But before that, there’s identifying the right supplier, which requires detailed understanding of the product technical requirements and the supplier production capabilities. There’s identifying the expected costs, based upon understanding material costs, labour costs, energy costs, tariffs, and overhead. There’s managing the supplier relationship. There’s dealing with disruptions and disasters. And taking corrective actions.

In other words, supply chain projects don’t have well-defined beginnings. Don’t have well-defined endings. Don’t have well-defined workflows. Aren’t limited to a fix set of resources. Don’t always have a well-defined team. And don’t always have a well-known cost (even if there is a target one).

Project Management hasn’t kept up. Sourcerors are often making it up as they go. And they’re damned every step of the way.