Herding cats in an accidental profession: A personal view of project management

I wrote the following article for the Mensa Business Special Interest Group (SiG) and it seemed to be fairly well received so I thought I’d open it out to a wider audience in the hope that some may also find it of interest.

What is, and when did, project management become a profession?

At its most simplistic project management can perhaps be thought of as simply taking a set of instructions and ensuring that they are performed, and at its most complex it can put a man on the moon; with pretty much anything and everything in between.

As a profession there’s no universally acknowledged start date, it’s generally accepted that the building of the pyramids is perhaps the first example of the existence project management as a profession, although some cite even earlier examples of construction. It’s probably fair to say that we’ll never actually discover the first example of project management in action; if for no other reason that a good project manager would never take any credit for the project’s success ;); and despite never being formally acknowledged as a profession or discipline ‘stuff’ got built and progress was made.

Various business tools now associated with the profession were created as time passed but it was perhaps the creation of the Gantt chart in 1917 that provides us with project management’s perhaps most recognisable artefact. During the late 1950’s and early 1960’s the critical path method (CPM), program evaluation review technique (PERT) and the work breakdown structure (WBS) provide the impetus to recognise project management as distinct profession of its own; and during the mid-1960’s the first project management associations were formed.

Coming up to date we now have a plethora of project management methodologies such as PMI, Prince2, Scrum, XP, Agile etc that can be broadly broken down into two genres; waterfall and agile.

Waterfall is the classic sequential model that follows a general Requirements > Design > Build > Test methodology. It aims to provide an end to end view of the project to be delivered up front and as such aims to provide an holistic view of costs and timeline to a fixed scope.

Agile by comparison uses an incremental iterative methodology that breaks the delivery down into a series of ‘sprints’ of any duration, but usually around 20 to 30 days. The aim is that each sprint end will deliver a working product, this product is then built upon during successive sprints until a fully functional product is developed. Its aim is to avoid setting fixed specifications up front by agreeing to deliver functionality within a set time-frame which is then subject to review and enhanced based on this output; leading to a much more focussed product at project completion.

Perhaps somewhat unsurprisingly there is a seemingly endless discussion as to which methodology is the best which; and whether some methodologies such as XP, Scrum should really be classed as project management methods at all. But to my mind at least, these are somewhat unanswerable questions.

In my opinion the best methodology is the one that suits the projects environment at that time; in terms of deliverable, organisation, customer and team member ‘fit’. So often we see organisations chasing the ‘guaranteed success’ of the latest favourite model only to suffer disastrous results because it was not suited to the development of a certain product or an organisations culture.

History is interesting but what of the present?

To answer this I think we perhaps need to separate the project manager from the project.

In terms of projects, within my particular area of IT and Telecommunications at least, we are seeing ever increasing amounts of complexity, interconnectedness and data capture and analysis. Customers are implementing systems from a variety of vendors and expect them to ‘talk’ to each other and exchange information in a secure and stable manner. Their customers expect to be able manage their services whenever and from wherever they feel and using a plethora of differing devices and communication methods. This type of stuff doesn’t just happen on its own, it takes teams of highly skilled and knowledgeable developers and engineers working together to make the reality fit the theory.

And this situation is expanding at an ever increasing rate as competitors race to outdo each other with the latest services and offerings. Only a few years ago it was common for project managers to run several small and medium sized projects that had varying degrees of interconnect between each other. A lot of project managers I meet these days are running multiple work streams inside of large programmes of work; the level of interconnectedness has become so great it is often easier for a single project manager to manage these multiple work streams; thereby reducing the risk of disconnect as the number of handover points is reduced.

With the Internet of Things (IOT) now breaking out into mainstream devices this effectively bridges the worlds of IT and Telecommunications to engineering in all its many forms. Clearly these worlds have had degrees of cross over for many years but with IoT we now see IT and engineering projects directly impacting each other. In the last two years 90% of the worlds data has been created; 2.5 quintillion bytes of data is now being created each day, enough to fill 10 million Blu-Ray discs; every day.

So I think it’s fair to say that project managers will be managing far more complex and disparate technology projects that will ultimately form cohesive new or enhanced services or solutions for organisations and society. By doing so they will move closer to the strategic heart of the organisation and will likely be seen as less as a person that delivers a point in time product and more of someone that is fundamentally central to the organisations ability to outperform the competition.

In terms of project management it seems to me that once you strip away the technology specifics what you will essentially be doing is managing teams of high skilled, intelligent and capable people, and actually I think managing is the wrong word to use here; project managers of the future will I believe need to err more on leadership than management. Yes they’ll still be the financial, governance and status reporting to deal with but in terms of actually making progress they’ll need to be leaders and collaborators to their delivery teams, be seen as guardians to the solution and more than ever provide the bridge between the technology and the business.