Firstly let’s define what it is:
Project Management is the collection of skills and processes required to define, plan, manage and deliver a project on time and within budget. Project managers must also be acutely aware 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 liberally today, often in ways that do not fit the original definition (e.g. more to everyday or on-going work). Genuine projects are one-time efforts to develop something new, like a new software system, new bridge, a new product or process, or a major engineering facility. Today, many ‘softer’ activities inside businesses are also often referred to loosely as projects (such as change or business improvement programmes).
So what does it cover or include?
In truth it is a very broad subject and the term covers a wide range of skills, disciplines, and processes, which collectively cover the definition, planning, leading and managing 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 fundamentally. Most ‘methods’ only emphasize processes or phases, but we prefer the above definition, as it conveys all of the most important elements together (i.e. process and key skills).
As a subject, it is still being developed. There will never and can never be one single method that can be universally applied (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, and there are significant differences from one environment to another. Industries too have different priorities and needs, leading to variation in what they will and will not need to focus on. Many organisations, including established large-scale businesses, still have a long way to go to be fully satisfied with the way they are managed, or the outcomes they produce.
So let’s look at each of these in more detail
Whether you are talking about Agile, or traditional methods, all projects benefit from the following, regardless of how it is achieved and the terminology being used. It is also fair and accurate to say, that too much of what is described in the following section, still does not always exist (certainly to a good enough standard) far too often.
Definition and Strategy:
before detailed planning is done, the following should be agreed and captured, even if to some people, much of the following appears to be obvious: why it 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 definition, the delivery strategy should be reviewed, and again major decisions around this should be properly captured. Too often this stage is not done formally enough, resulting in major risks going un-noticed.
is potentially a large-scale activity in itself, driven by the nature of the business. Again, regardless of method and terminology used (including Agile), all must plan and use the outputs of this phase as a central tool to manage. This includes: agreeing and capturing the scope of work, timescales or schedule, estimating and allocation of resources, and any other key activities that will need to be conducted (e.g. quality assurance and user or customer acceptance etc.). The collective output of the planning phase is sometimes referred to as the baseline plan (i.e. the delivery plan that is agreed to and formalised with the customer). The outputs of the planning phase 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 product or subsystem (e.g. Sprint). For all others, (using more or a Waterfall type approach), planning is more of a discrete activity in itself, towards the front end of the life-cycle.
all but the simplest of projects will require or 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 it requires both in many circumstances. Lack of leadership ‘presence’ is a common cause of why some fail.
due to their very nature (and the way most businesses manage them) they 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 completely. 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 required. Much of this is often referred to as ‘control‘. Increasingly today as well, 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 embedded in most modern-day PM approaches originated from work on industrial projects in the USA between the 1940s to 1960s, following 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 very commonly used today. It is probably the single biggest PM tool in use today; and Henri Fayol, who 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 progams), 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-contract 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 and still underpins today some of the best practices and far outstrips common practices across entire industries in 2014. 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 ground breaking 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, as 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), 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), but the much discussed original ‘criteria’ that were also published (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 co-ordinate.
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, he/she 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 almost 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 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. Entire 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 at the very least.
Evidence suggests that they work best when responsibility for managing them and for decision-making is embedded directly in the core team, and is available to them at all times. 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, and, this typically results in a cumbersome and very slow decision-making process (often coinciding with a major de-scoping of certain types of projects).
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:
1970s – The Advent of Professional Bodies and Associations
In the US the PM Institute (PMI) originated from a meeting of a just a few people in 1969, and through the 1970’s 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.
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 ground breaking 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 in a much more formal way.
1990s – The rise of Corporate Methodologies
During this decade, many organisations (and especially those who were new to the topic) started to develop formalised 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 them 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 Certification
2002 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 idea needs 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 mention 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: it is not management is not a binary science. It requires lots of things 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 as well – what is clearly the only correct thing to do in one industry, may be exactly the wrong thing to do in another. Reflecting and recognising this in certification exams can be very challenging. The other main question, is that testing aspects like the organisational skills of Kelly Johnson above is very hard in the most common type of 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 business where projects can succeed. They will always be challenging, and sometimes in business, we ourselves make them much harder than they need to be.
Example of best practices
The following is a sample of best PM practices – we have chosen the following because of their broad application:
- 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.
- 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 can be outstanding. 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.
- Single integrated teams: this has been given many names and is central to many important PM initiatives in the last 20 years (Agile more recently and Integrated Product teams to name just two). The principle that potentially translates into practices, behaviors and clear benefits is that the project operates as one team, where 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.
- 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 productivity. The most common example is Daily Stand-ups (which Agile did not invent but many Agile methods use) where all key parties, including those with decision-making authority, participate in this process.
- Moving back from deterministic to more realistic planning: 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 productive example of the reversal of this poor practice.
- 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 where there is real evidence of attention to this topic, typically have far more success, and suffer far fewer (often avoidable) surprises, the impacts of which are usually measured in cost and schedule terms.
PM Lessons learned:
- 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 ways-of-working, and often delivered projects very successfully.
- Many businesses that spent considerable time and money on developing corporate PM methodologies, in practice never used much of what those methodologies contained, and many of those same organisations also failed to embed PM practices into their businesses. These businesses usually struggle to deliver projects successfully.
- And this is still valid today, too many project managers don’t fully understand and execute the fundamentals of effective project management – and many of their efforts suffer great variation in results.