Project Management, a painful journey

When the engineering and construction world needed to manage their risk and delivery better in the early part of the 1900's they organized work in a structured manner and created what we know today as project management. There is nothing magic about project management, and it mostly is plain common sense put together in a formally recognized manner. However when it started to move into highly complex environments with cross disciplines the wheels started coming off.

picture taken by author in Lesotho

Now I am not saying the building and construction industry gets it right all the time, or even most of the time. I have built a few homes where a building project manager was involved, and man, I have never been so close of ending a person as in these little ventures. Generally the building industry is highly standardized. You start off with a clear floor plan, have a reasonable handle on scope and based on local knowledge should have reasonable control over your three key variables, labor, suppliers and of course, weather. Delivering ICT projects in the corporate space however, is a different kettle of fish all together.

During the 1950's one of man’s most ambitious ventures ever was in full swing ... Put a man in orbit. And to do this NASA had to take the greatly informal discipline of project management and make it more robust by creating a standardized and process driven platform that could be used by multiple project managers in such a way that you can have more predictable and easily understood results. They gave us PERT, essentially a model to plan, cost and control work. A vast move forward and still used in evolved forms today. Except, applying it to ICT implementations that is more art than science is a sure road to failure.

Image from nasa.gov library

During the late 70's and 80's the computerization of the corporate environment led to a need to start managing the change in process and structure, driven by technology, better. Enter project management into the commercial space. Initially, driven by large organizations such as IBM, the discipline did not evolve much, mainly using PERT, GANT charts. As far as business was concerned, IT was saving them, giving them an edge, and any way IT seem to understand what can be done by when. Through the 80's, a period that most executives that now run companies cut their teeth, this was what constituted a project. We let IT go into their little hole and bring us something. Systems where mostly slow evolving solutions, that was delivered into a slowly evolving commercial space, and mostly using the techniques from the construction and engineering industry from the early 1900's worked.

The reason this worked in the 80's and early 90's is that business change was mainly driven by finance and technical management, people that could understand the structured thinking needed to deliver in a project. Further, the problems Being solved where mainly silo based low complexity and virgin territory. Even though project failure rates were climbing, things where still mostly OK. That ball changed dramatically in the 1990's with the internet and the start of globalization. All of a sudden these solutions started becoming business critical, and everyone needed more integration, bringing greater complexity. All of this needed change in the way we run projects, and the modern day waterfall project methodology was born. These became highly formal and processised, and try dealing with the increasing pressure and complexity by adding more red tape and trying to involve business more in formal structures such as project boards and testing.

All of this however deliver poorly, with project success rates (using time and budget only) globally sitting around the 30-40% mark.

Agile has been introduced in the last decade or two, with mixed success, and new approaches to organizational project maturity and more formal delivery structures have been introduced, but still most organizations have massive problems around delivery of projects, often experiencing massive over runs in time and budget, leading to losses of profits and often people burning out, and either leaving the organisation or being fired.

Is it poor staff, either at the project management or technical side? IS it the prong project processes? IS it the wrong project?

Truth be told it could be all these and more, but often we only solve these issues, and refuse to look further. In my further blogs on this topic, I will share MY thoughts on where many of the problems lie.