What is Project Management?

What you will find in this post:

This post describes all the core elements of project management. It then describes the origins of PM concepts and techniques. Finally, it describes best practices in recent years.

Firstly let’s define project management:

Project Management is the combined skills and processes required to define, plan, manage and deliver a project on time and within budget.  Project managers must also be acutely aware of what the planned outcomes and benefits are. However, separate processes (and responsibilities) cover the core definition and achievement of these.

(London 2012 Olympic Stadium – built especially for the games.)

The origins of modern-day Project Management

The term ‘project’ is used often today, including in ways that do not fit the original definition (e.g. more to everyday or ongoing work).  Real projects are one-time efforts to develop something new, like a software system, a bridge, a product or a process. Today, many ‘softer’ activities inside businesses are also often loosely called projects (such as change or business improvement programmes).

So what does project management cover or include?

In truth, it is a very broad subject. It covers a wide range of skills, disciplines, and processes, which collectively cover the definition, planning, leading, and management of projects.

There are many approaches or ‘methods’ for doing this. Many share common concepts or principles and in truth differ more in terminology, rather than approach.  Most ‘methods’ only emphasize PM processes or concepts. However, we prefer the above definition, as it contains all the important elements together (i.e. process and key skills).

As a subject, it is still being developed. There will never be one single method that can be universally applied to all projects (unless it is so high level to be of little practical use). This is because, in business, projects span the entire spectrum of human activity. There are significant differences from one environment to another. Industries have different needs around their projects, leading to differences in what they will and won’t do.

Many organisations, including established large-scale businesses, still have a long way to go to be fully satisfied with the way their projects are managed or the outcomes they produce.

So let’s look at each of these in more detail

Whether you’re using Agile, or traditional methods, all projects benefit from the following, regardless of how it is done and the terminology used. It is also fair to say, that too much of what we describe in this post still does not happen (well enough) far too often. The following is a brief summary of what needs to be done on all projects.

Project Definition and Delivery Strategy:

before detailed planning is done, the following should be agreed and captured, even if some of the following appears to be obvious:

• why the project is necessary or is being done (it’s amazing how many times this is not clear to all);
• its goal, specific objectives, target outcomes, planned benefits; and
• major expectations or needs of key stakeholders around the deliverables.

Sometimes, much of this might be captured in a Business Case, especially when it requires major change, procurement, or capital investment.

Following project definition, the delivery strategy should be agreed upon. All major decisions around this should be fully analysed from the perspective of risk. Too often this whole stage is not done properly, resulting in major risks going unnoticed.

It should never be assumed that one single PM method can/must be used for all projects.  The delivery strategy must reflect the circumstances of the project. This must especially include the way the project is organised and how planning can/will happen.

Planning:

is potentially a large-scale activity in itself, driven by the nature of the project.  Again, regardless of the method and terminology used (including Agile), all projects must plan and use the plan as a central tool to manage.

Planning includes:

• agreeing and capturing the scope of work,
• clarifying timescales and developing schedules,
• estimating and allocating resources and budgets,

and any other key activities that will need to be done (e.g. quality assurance and user or customer acceptance etc.).

The output of the planning phase is sometimes referred to as the baseline plan (i.e. the delivery plan that is agreed upon with the customer/sponsor).  The outputs of planning will provide many of the inputs to the ‘control’ processes used during the delivery phase, regardless of whether we use “burn down charts” in Agile, or Earned Value metrics on a construction or Aerospace type project.

In Agile, planning is a recurring activity around every iteration of a product or Sprint.  For all others, (using more or a Waterfall type approach), planning is usually more of a one-time activity, towards the front end of the project.  Re-planning can also be needed too as projects often experience issues and surprises.

Project Leadership:

all but the simplest of projects will benefit from leadership driving it forward, setting the vision, its goals and literally leading the team from the front.  In some industries, this would definitely be the project manager; in other industries, he/she has less of a high-profile role.  It was debated in many circles for some time, whether this role is a leadership or management role.  The truth is that both are needed in many circumstances.  Lack of leadership ‘presence’ is a common cause of why some projects fail.

Project Control:

due to their very nature (and the way most businesses manage them) projects rarely (if ever) go smoothly to plan.  There are surprises, disappointments and issues, that must be managed so that their impact is minimised or mitigated. On top of this, it is the responsibility of the PM function (note not just the project manager), to ensure that it is progressing according to plan, that risks and issues are being managed, and that timely corrective action is taken when needed. Much of this is often referred to as ‘control‘.

Increasingly today, the role of the project management function is to develop an environment where teams can be productive and successful.  This is also the most important challenge (or task) on many (if not all) projects in business today.

Origins of Modern-Day Methods:

The main concepts that are in most modern-day PM methods came from work on industrial projects in the USA between the 1940s to 1960s This followed the development of earlier management concepts, principles and tools.

For example, Henry Gantt (1861-1919) is often quoted as one of the fathers of PM and is said to have created the Bar Chart, which is still commonly used today.  It is probably the single biggest PM tool in use today. Henri Fayol, a French Mining engineer, developed the origins of what is now known as ‘plan-do-check’.

Kelly Johnson was an innovative and gifted aeronautical engineer who ran the ‘Advanced Development Programs’ division of Lockheed Martin (known as the Skunkworks ®) from 1943-1975.  He was known as an ‘organisational genius’ –  a useful and still today far too underrated skill in being an effective project manager.  Early in this period, he introduced 14 Rules of Management (for development programs), which included:

• “The Skunk Works (project) manager must be delegated practically complete control of his program in all aspects.
• There must be a monthly cost review covering not only what has been spent and committed but also forecast costs to the conclusion of the program.
• The contractor must be delegated and must assume more than normal responsibility to get good vendor bids for sub-contracts on the project.
• There must be mutual trust between the military (customer) organization and the contractor, and very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum.”

Bearing in mind when the above was introduced and what typically prevailed at the time, it was unique and hugely far-reaching. It still underpins some of the best practices and far outstrips common practices across entire industries still today.  In terms of impact and delivery performance, in 1943 the XP-80 aircraft (the USA’s first jet fighter) was delivered (by a team managed personally by Johnson) in only 143 days, seven less than planned.

The Polaris program of the 1950’s is often quoted for its use of the PERT technique, which was again groundbreaking and significant.  PERT (Program Evaluation and Review Technique) addressed the modelling of timescales (especially where significant uncertainty exists). PERT was and still is an excellent technique, but ultimately proved too complex for most organisations to adopt and was superseded (in take-up terms) by the more simple critical path method, (CPM).  CPM was developed originally by a joint venture between DuPont and Remington Rand Corporation for managing major plant maintenance efforts.

Going back to Polaris, perhaps far more significant though, was the aim of “Organisational autonomy” and the awareness of the need to manage the conflicting agendas and requirements even among the prime customer itself.  Again, a challenge that is not always dealt with effectively and sometimes not faced up to (openly) at all today, at the right stage of the life-cycle.

1967 saw the US Department of Defence introduce the origins of C/SCSC (now called Earned Value management – EVM), and our reason for including this is not so much the technique itself (even though it is still a best practice for certain industries today).  It is that in 1967 EVM introduced the much-discussed original ’35 criteria’ (which are just as valid today) which define many best practices in establishing management control systems in large-scale projects. Today these are referred to in EVM standards (such as ANSI 748) as EVM guidelines.

Finally, it was French Engineer and management Scientist Henri Fayol (1841-1925) who developed the foundation of what still stands today as the core behind the structures of the Bodies of Knowledge in the most prominent professional associations around the globe, including PMI from the USA and APM from the UK, being to plan, organise, control and coordinate.

The Role of the Project Manager:

Earlier we hinted that on larger projects, not all of the management process will always be done by the project manager themselves.  However, they must always be responsible for ensuring it is well planned and managed, and that these processes are being carried out to a good standard.

The full role of the project manager is not greatly understood in many businesses still today. It is also true that too many (even in high-profile businesses) are appointed with almost zero science behind their selection, and most are given very little or even close to nil formal preparation for this challenging role.

It is assumed by far too many businesses that anyone of a certain grade can be a successful project manager.  This is a very poor assumption to make, and can on its own be a major challenge or source of major issues in any business.

One of the key concepts that PM introduced decades ago, was single-point responsibility in one person, who is of course the project manager.  This is something that still gives organisations a major challenge, today.  Whole industries have yet to get to grips with this concept, because of their structures, cultures and the ‘political’ challenge that must be overcome for this to become a reality. There may be someone given the title, but many other people and even bodies make all the key decisions.  This falls far from the original intent and typically results in delays (sometimes severe) at the very least.

Evidence suggests that projects work best when responsibility for managing them and for decision-making is embedded directly in the core team.  Approaches such as Agile always look to achieve this.   If a project manager has to constantly refer out to committees on all issues and key decisions, there is a danger they can become little more than a co-ordinator. This often results in cumbersome and very slow decision-making (often coinciding with a major de-scoping of projects in certain environments).

Great project managers are worth their weight in gold in business, but in truth, they are few and far between.

PM Trends through recent decades:

The 1970s – The Advent of Professional Bodies and Associations

In the US the PM Institute (PMI) originated from a meeting of just a few people in 1969, and through the 1970s developed into a formal Professional Association.  In the UK, the Association for PM (APM) was founded in 1972.  One of the most landmark milestones for both Associations was the development and publication of a Body of Knowledge (BoK), defining their interpretation of the discipline (as it is now known) of project management.  Both Associations maintain and continue to update their BoKs to reflect the development of current practices and to ensure they are more reflective of the broad range of industries and other types of organisations that wish to embrace the ‘discipline’ today.

The 1980s – The advent of PM systems and software

During the 1980s, driven by the advent of mini and personal computers, many more businesses started building their own software applications for key business functions including PM.  There was a culture in most corporations of building as opposed to buying applications at this time, supported by a desire by most businesses wanting to build a project management system that matched their specific needs and requirements.  During this period, it was very common to do this, as leading PM software systems at that time, were in truth 3GL language systems, together with the core algorithms that separate PM systems from all other database applications (i.e. critical path analysis and resource scheduling).  The new graphics capability that they introduced transformed the ability to summarise and present key aspects of PM data graphically, change the data and instantly see the results again, graphically.  We all take this for granted today but at this time, it was a groundbreaking change in capability and speed (of data analysis and presentation).  Capabilities were introduced that became quite commonplace, many of which have declined, driven in part by a big swing towards low-end project management software products, commonly in use now for many years. During this period, formal project management disciplines were only recognised and carried out in a small number of industries, usually with large-scale traditional projects, such as Petrochemical, Aerospace and Defence, and pockets of other industries.  Towards the back end of this decade, the method started to spread into many other industries.

The 1990s – The rise of PM Methodologies

During this decade, many organisations (and especially those who were new to the topic) started to develop formal PM methodologies for their own business.  Probably the biggest single lesson should stem from this work. For every organisation that spent considerable amounts of time and money trying to define in some detail exactly how projects should run, very few ever managed to make projects ‘run’ as defined in their ‘methodologies’.  The reasons behind this are arguable, but undoubtedly include lack of Governance (still an issue today in many businesses) and also perhaps the most significant is the lack of awareness and skills by too many people in the business to manage them in the way their organisations expected. It is also true that you cannot define a series of steps that will always be right for every project, regardless of how attractive that idea may appear. In essence, most methodologies became ‘shelfware’, only to be aired (often embarrassingly) at times like audits and inspections.

2000 and beyond: The advent of Agile and PM Certification

2001 saw the birth of the origins of Agile, but it was not until the end of this decade that Agile started to gain real momentum in both take up and maturity of understanding of both what Agile does and does not mean.  Agile contains some great ideas – but like all great ideas that centre around a management concept, the ideas need to be properly understood and implemented. Those who think that the advent of Agile means the end of planning for example are mistaken, and often do not see the corresponding benefits in improved delivery performance that Agile promises. In Agile we still plan, and we still need information on progress (e.g. Burndown charts etc.) as a core part of managing the delivery process.  They just (hopefully) do it with the minimum of bureaucracy, simple tools and processes.  To be successful, they also still require a lot more than is typically defined around Sprints and SCRUM. Introducing Sprints alone does not mean you are using an Agile development process.

Lastly, we could not do a piece like this without mentioning PM Certification. Certification abounds today. Some might say too far.  Why would an organisation that should benefit from Certification business-wise say this?

In principle, PM Certification is a good thing.  Having qualified people cannot be bad, assuming the qualification process is totally fit for purpose.  PM Certification is relatively new, and some display their lack of maturity.  For example: project management is not a binary science.  It requires skills like judgement and it can be very hard to compose multiple choice questions (in large numbers) that carry true academic rigour and have only one very clear correct answer.  Any reader who has recently sat such an exam may well recognise this.   Industry variation matters too. What is clearly the only correct thing to do in one industry, can be exactly the wrong thing to do in another.  Reflecting this in certification exams is very challenging. The other main question is that testing aspects like the organisational skills of Kelly Johnson is very hard in the certification exams that predominate today. At its very best, project management is an organisational discipline.

Having qualified people can be a very good thing, but on its own does not necessarily provide an environment in a business where projects will always succeed.  They will always be challenging, and sometimes in business, we ourselves make them much harder than they need to be.

Some example of  best practices

The following is a small sample of best PM practices. We have chosen these because of their broad application:

1. Focus on outcomes and benefits. In the past decade, there has been a real focus on the outcomes and benefits that certain types of projects are intended to achieve.  This is a major shift in thinking for lots of people, and not something that happens very often today or by itself.
2. Co-location: for at least key parts of the life-cycle or more. It’s not always possible, but when teams do this, the results usually speak for themselves.  In essence, communication lines are shortened and two-way communication can become the norm.  This is always going to deliver far better results and a far more productive development environment.
3. Single integrated teams: this has been given many names and is central to many important PM initiatives in the last 20 or more years (Agile more recently and Integrated Product teams to name just two).  The principle that potentially translates into practices, behaviours and clear benefits is that the project operates as one team. For example, users and developers work together constantly to define requirements and make key decisions in a collaborative way throughout the development phase. The acid test (which is beyond the appetite of many businesses) is: one plan and one version of the truth every day across the whole team.
4. Bringing PM into the day-to-day: moving away from mainly relying on monthly (or even weekly) meetings or processes to something where there is daily communication around progress and issues, can on its own make a huge difference in performance.  The most common example is Daily Stand-ups (which Agile did not invent but many Agile methods use) where all team members, including those with decision-making authority, participate in this process.
5. Moving back from deterministic to more realistic planning. This is a little ‘techy’ but very important.  Too many projects in the recent past have been planned using deterministic (single point) values, relating to time and cost, as if the plan speaks with absolute certainty at the outset.  Some businesses may feel some form of comfort factor by adopting this approach. In reality, it typically fosters the wrong attitude towards the whole nature of projects and what’s required to manage them successfully. Recently, the re-introduction and adoption of 3-point estimates is one positive example of the reversal of this poor practice.
6. The development of project risk management since the 1990s.  In 1996 the British Standards Institute published its first standard on PM: BS 6079.  A couple of years later, they published a substantial addendum, entitled the “Management of Project Related Risk“.  Speaks volumes about the general level of understanding and application of this important topic at the time.  Organisations that pay far more attention to this topic, typically have far more success. They suffer far fewer (often avoidable) surprises, the impacts of which are usually measured in cost and schedule terms.

PM Lessons learned:

1. Many businesses which had been using PM practices heavily as part of the day-to-day business of delivering projects quietly and very successfully, never felt the need to write a PM methodology, and never did.  They had PM practices embedded into their culture and day-to-day working practices and often delivered projects very successfully.
2. Many businesses that spent considerable time and money on developing corporate PM methodologies, in practice never used much of what those methodologies contained, Also, many of those same organisations failed to embed PM practices into their businesses.  These businesses usually struggle to deliver projects successfully.
3. And this is still valid today. Too many project managers don’t fully understand and execute the fundamentals of effective project management. Many of their efforts suffer great variation in results.