Early Background of Project Management
Before describing program management, it is worth looking
at the history of the development of project management that has led to the need
for effective program management. Project management as an idea has been around
a long time – after all, they were building pyramids a few millennia before Christ
– but it is a recent management science. First used by the military as a management
discipline during the Second World War, it progressed into the civil sector during
the late 50's and early 60's of the last century. At that time, its focus was
on various approaches to the Critical Path method, including PERT, Precedence,
and activity-on-arrow diagrams, as well as various others. Indeed, I understand
that the UKÍs Electricity Operator had a team developing the "line of irreducible
time for projects" method at about the same era. Perhaps its lack of a catchy
title was its downfall!
If project management as a management science discipline can
be tracked to a start in the 50's and 60's, then the 70's was the period when
the focus moved from the time span of the project and its reduction, to project
control. This was achieved by developing integrated, computer-based, management
systems capable of integrating time, cost and quality, or at least in theory.
Many were sold, but few truly integrated the project, and worse still, few integrated
all projects in the owner/client's organization. By the early 1980's the market
place was full of companies who had bought their integrated management system,
but were still failing to deliver successful projects to time, cost and quality.
So, by the early 1980's companies were again seeking help
with their projects, mainly from owner/clients rather than contractors and suppliers.
They recognized that their project managers were trying to lead and control projects
when they had little "given" authority over those they were managing,
often managing in a "matrix" organization. As we now know, matrix management
is the hardest form of project organization for the project manager to lead and
manage in, and requires real discipline in the roles and responsibilities of
the PM and the line manager.
The PM should focus on "what", "when",
and "how much"; whilst the line manager should focus on "how",
"how well" and "who". Clearly the PM has some say over the
"who", because s/he is responsible for leading and building the project
team and needs a group who can be "formed" into a team. What the owner/clients
were now looking for were PMs who had lots of personal authority and could manage
in the matrix with the minimum of "given" authority. This led to them
seeking training courses to improve the "interpersonal" or "softer"
skills of the PM, including characteristics such as leadership, conflict management,
motivation, perseverance, team-building, and more.
At that time, I was teaching project management at Cranfield,
and this was the most common request from the market place. We developed courses
that integrated the hard and soft skills of project management, as well as providing
an overview of projects and where they fitted into the business. These were taught
both in the classroom and using the outdoors, where the dramatic backcloth and
realism of the short project exercises enhanced the participants' development
of their softer management skills.
By the end of the 1980's and into the 1990's the key word
in the discipline, along with other disciplines, was "competencies".
The UK Association for Project Management developed its Body of Knowledge, which
listed around 40 competencies required by a good project manager. It is this
and other similar initiatives in Europe and the US that has informed most of
those who run training programs in project management.
At about the same time, two things also became clear. Firstly,
the project manager alone was not enough to deliver successful projects. What
you also need is a good project sponsor, to be accountable for the investment
in the project and to engage the PM to undertake the delivery of the project
and its deliverables or assets. Secondly, you need a user/operator to put the
asset or deliverables to work and make the agreed return for the business or
organization.
|
Abstract
