History of Project Management
History of Project Management
History of Project Management
Project management has been practiced since early civilization. Until 1900 civil engineering
projects were generally managed by creative architects and engineers themselves, among those
for example Vitruvius (1st century BC), Christopher Wren (1632–1723), Thomas Telford (1757–
1834) and Isambard Kingdom Brunel (1806–1859).It was in the 1950s that organizations started
to systematically apply project management tools and techniques to complex engineering
projects.
As a discipline, Project Management developed from several fields of application including civil
construction, engineering, and heavy defense activity. Two forefathers of project management
are Henry Gantt, called the father of planning and control techniques, which are famous for his
use of the Gantt chart as a project management tool; and Henri Fayol for his creation of the 5
management functions which form the foundation of the body of knowledge associated with
project and program management. Both Gantt and Fayol were students of Frederick Winslow
Taylor's theories of scientific management. His work is the forerunner to modern project
management tools including work breakdown structure (WBS) and resource allocation.
The 1950s marked the beginning of the modern Project Management era where core engineering
fields come together working as one. Project management became recognized as a distinct
discipline arising from the management discipline with engineering model. In the United States,
prior to the 1950s, projects were managed on an ad hoc basis using mostly Gantt Charts, and
informal techniques and tools. At that time, two mathematical project-scheduling models were
developed. The "Critical Path Method" (CPM) was developed as a joint venture between DuPont
Corporation and Remington Rand Corporation for managing plant maintenance projects. And the
"Program Evaluation and Review Technique" or PERT, was developed by Booz Allen Hamilton
as part of the United States Navy's (in conjunction with the Lockheed Corporation) Polaris
missile submarine program; these mathematical techniques quickly spread into many private
enterprises.
Gantt Chart
A Gantt chart is a type of bar chart that illustrates a project schedule. Gantt charts illustrate the
start and finish dates of the terminal elements and summary elements of a project. Terminal
elements and summary elements comprise the work breakdown structure of the project. Some
Gantt charts also show the dependency (i.e., precedence network) relationships between
activities. Gantt charts can be used to show current schedule status using percent-complete
shadings and a vertical "TODAY" line.
Although now regarded as a common charting technique, Gantt charts were considered
revolutionary when they were introduced. In recognition of Henry Gantt's contributions, the
Henry Laurence Gantt Medal is awarded for distinguished achievement in management and in
community service. This chart is used also in Information Technology to represent data that have
been collected.
Henri Fayol
Henri Fayol (Istanbul, 29 July 1841–Paris, 19 November 1925) was a French mining engineer
and director of mines who developed a general theory of business administration. He and his
colleagues developed this theory independently of scientific management but roughly
contemporaneously. He was one of the most influential contributors to modern concepts of
management.
Fayolism
Fayol's work was one of the first comprehensive statements of a general theory of management.
He proposed that there were six primary functions of management and 14 principles of
management
Functions of management
1. forecasting
2. planning
3. organizing
4. commanding
5. coordinating
6. monitoring /control - in the sense that a manager must receive feedback about a process
in order to make necessary adjustments
Principles of Management
1. Division of work. This principle is the same as Adam Smith's 'division of labour'.
Specialisation increases output by making employees more efficient.
2. Authority. Managers must be able to give orders. Authority gives them this right. Note
that responsibility arises wherever authority is exercised.
3. Discipline. Employees must obey and respect the rules that govern the organisation.
Good discipline is the result of effective leadership, a clear understanding between
management and workers regarding the organisation's rules, and the judicious use of
penalties for infractions of the rules.
4. Unity of command. Every employee should receive orders from only one superior.
5. Unity of direction. Each group of organisational activities that have the same objective
should be directed by one manager using one plan.
6. Subordination of individual interests to the general interest. The interests of any one
employee or group of employees should not take precedence over the interests of the
organisation as a whole.
9. Scalar chain. The line of authority from top management to the lowest ranks represents
the scalar chain. Communications should follow this chain. However, if following the
chain creates delays, cross-communications can be allowed if agreed to by all parties and
superiors are kept informed.
10. Order. People and materials should be in the right place at the right time.
13. Initiative. Employees who are allowed to originate and carry out plans will exert high
levels of effort.
14. Esprit de corps. Promoting team spirit will build harmony and unity within the
organisation.
Fayol's work has stood the test of time and has been shown to be relevant and appropriate to
contemporary management. Many of today’s management texts including Daft have reduced the
six functions to four: planning; organizing; leading; and controlling.
Frederick Winslow Taylor (March 20, 1856 – March 21, 1915) was an American mechanical
engineer who sought to improve industrial efficiency. He is regarded as the father of scientific
management and was one of the first management consultants. Taylor was one of the intellectual
leaders of the Efficiency Movement and his ideas, broadly conceived, were highly influential in
the Progressive Era.
Taylor was a mechanical engineer who sought to improve industrial efficiency. Taylor is
regarded as the father of scientific management, and was one of the first management consultants
and director of a famous firm. In Peter Drucker's description,
Frederick W. Taylor was the first man in recorded history who deemed work deserving of
systematic observation and study. On Taylor's 'scientific management' rests, above all, the
tremendous surge of affluence in the last seventy-five years which has lifted the working masses
in the developed countries well above any level recorded before, even for the well-to-do. Taylor,
though the Isaac Newton (or perhaps the Archimedes) of the science of work, laid only first
foundations, however. Not much has been added to them since – even though he has been dead
all of sixty years.
Future U.S. Supreme Court justice Louis Brandeis coined the term scientific management in the
course of his argument for the Eastern Rate Case before the Interstate Commerce Commission in
1910. Brandeis debated that railroads, when governed according to the principles of Taylor, did
not need to raise rates to increase wages. Taylor used Brandeis's term in the title of his
monograph The Principles of Scientific Management, published in 1911. The Eastern Rate Case
propelled Taylor's ideas to the forefront of the management agenda. Taylor wrote to Brandeis "I
have rarely seen a new movement started with such great momentum as you have given this
one." Taylor's approach is also often referred to as Taylor's Principles, or frequently
disparagingly, as Taylorism. Taylor's scientific management consisted of four principles:
1. Replace rule-of-thumb work methods with methods based on a scientific study of the
tasks.
2. Scientifically select, train, and develop each employee rather than passively leaving them
to train themselves.
3. Provide "Detailed instruction and supervision of each worker in the performance of that
worker's discrete task"
4. Divide work nearly equally between managers and workers, so that the managers apply
scientific management principles to planning the work and the workers actually perform
the tasks.
Taylor had very precise ideas about how to introduce his system:
It is only through enforced standardization of methods, enforced adoption of the best implements
and working conditions, and enforced cooperation that this faster work can be assured. And the
duty of enforcing the adoption of standards and enforcing this cooperation rests with
management alone.
Workers were supposed to be incapable of understanding what they were doing. According to
Taylor this was true even for rather simple tasks.
'I can say, without the slightest hesitation,' Taylor told a congressional committee, 'that the
science of handling pig-iron is so great that the man who is ... physically able to handle pig-iron
and is sufficiently phlegmatic and stupid to choose this for his occupation is rarely able to
comprehend the science of handling pig-iron.
The introduction of his system was often resented by workers and provoked numerous strikes.
The strike at Watertown Arsenal led to the congressional investigation in 1912. Taylor believed
the labourer was worthy of his hire, and pay was linked to productivity. His workers were able to
earn substantially more than those under conventional management, and this earned him enemies
among the owners of factories where scientific management was not in use.
With the triumph of scientific management, unions would have nothing left to do, and they
would have been cleansed of their most evil feature: the restriction of output. To underscore this
idea, Taylor fashioned the myth that 'there has never been a strike of men working under
scientific management', trying to give it credibility by constant repetition. In similar fashion he
incessantly linked his proposals to shorter hours of work, without bothering to produce evidence
of "Taylorized" firms that reduced working hours, and he revised his famous tale of Schmidt
carrying pig iron at Bethlehem Steel at least three times, obscuring some aspects of his study and
stressing others, so that each successive version made Schmidt's exertions more impressive, more
voluntary and more rewarding to him than the last. Unlike [Harrington] Emerson, Taylor was not
a charlatan, but his ideological message required the suppression of all evidence of worker's
dissent, of coercion, or of any human motives or aspirations other than those his vision of
progress could encompass.
PRINCE2
This article needs references that appear in reliable third-party publications. Primary sources or
sources affiliated with the subject are generally not sufficient for a Wikipedia article. Please add
more appropriate citations from reliable sources.
This article's lead section may not adequately summarize its contents. Please consider expanding
the lead to provide an accessible overview of the article's key points.
PRojects IN Controlled Environments (PRINCE) is a project management method. It covers the
management, control and organisation of a project. "PRINCE2" refers to the second major
version of this method and is a registered trademark of the Office of Government Commerce
(OGC), an independent office of HM Treasury of the United Kingdom.
The most current revision was released in 2009 as part of the Prince2:2009 refresh project by the
Office of Government Commerce.
History of PRINCE2
PRINCE2 is derived from an earlier method called PROMPTII, and from PRINCE project
management method, which was initially developed in 1989 by the Central Computer and
Telecommunications Agency (CCTA) as a UK Government standard for information systems
(IT) project management; however, it soon became regularly applied outside the purely IT
environment. PRINCE2 was released in 1996 as a generic project management method.
PRINCE2 has become increasingly popular and is now a de facto standard for project
management in the UK. Its use has spread beyond the UK to more than 50 other countries.
Since 2006, the method has been revised and launched as "PRINCE2:2009 Refresh" in 2009.
The name "PRINCE2" (instead of "PRINCE3" or similar) is kept to indicate that the method
remains faithful to its principles. Nevertheless, it is a fundamental revision of the method from
1996 to adapt it to the changed business environment, to make the method simpler and "lighter",
to address current weaknesses or misunderstandings, and to better integrate it with other OGC
methods (ITIL, P3O, P3M3, MSP, M_o_R etc.).
The main difference between the 2009 version and earlier versions is that there will be two
manuals: 'Managing Successful Projects with PRINCE2 - 2009 Edition' and 'Directing
Successful Projects with PRINCE2 - 2009 Edition'. Both the Foundation and Practitioner
Examinations will be based on the new 'Managing Projects' manual and will not include material
from the new 'Directing Successful Projects' book.
Starting up a project
In this process the project team is appointed and a project brief (describing, in outline, what the
project is attempting to achieve and the business justification for doing so) is prepared. In
addition the overall approach to be taken is decided and the next stage of the project is planned.
Once this work is done, the project board is asked to authorize the next stage, that of initiating
the project.
Key activities include: appointing an executive and a project manager; designing and appointing
a project management team; preparing a project brief; defining the project approach; and
planning the next stage (initiation).
Initiating a project
This process builds on the work of the start up process, and the project brief is augmented to
form a Business case. The approach taken to ensure quality on the project is agreed together with
the overall approach to controlling the project itself (project controls). Project files are also
created as is an overall plan for the project. A plan for the next stage of the project is also
created. The resultant information can be put before the project board for them to authorize the
project itself.
Key activities include: planning quality; planning a project; refining the business case and risks;
setting up project controls; setting up project files; and assembling a Project Initiation Document.
Directing a project
This process dictates how the Project Board (which comprises such roles as the executive
sponsor or project sponsor) should control the overall project. As mentioned above, the project
board can authorise an initiation stage and can also authorize a project. Directing a Project also
dictates how the project board should authorize a stage plan, including any stage plan that
replaces an existing stage plan due to slippage or other unforeseen circumstances. Also covered
is the way in which the board can give ad hoc direction to a project and the way in which a
project should be closed down.
Controlling a stage
PRINCE2 suggests that projects should be broken down into stages and these sub-processes
dictate how each individual stage should be controlled. Most fundamentally this includes the way
in which work packages are authorised and received. It also specifies the way in which progress
should be monitored and how the highlights of the progress should be reported to the project
board. A means for capturing and assessing project issues is suggested together with the way in
which corrective action should be taken. It also lays down the method by which certain project
issues should be escalated to the project board.
Key activities include: authorising work package; assessing progress; capturing and examining
project issues; reviewing stage status; reporting highlights; taking corrective action; escalating
project issues; and receiving a completed work package.
Key activities include: planning a stage; updating a project plan; updating a project business
case; updating the risk log; reporting stage end; and producing an exception plan.
The Managing product delivery process has the purpose of controlling the link between the
Project Manager and the Team Manager(s) by placing formal requirements on accepting,
executing and delivering project work.
a. To ensure that work on products allocated to the team is authorised and agreed,
The key activities are: Accept a work package, execute a work package and deliver a work
package.
Closing a project
This covers the things that should be done at the end of a project. The project should be formally
de-commissioned (and resources freed up for allocation to other activities), follow on actions
should be identified and the project itself be formally evaluated.
Key activities include: decommissioning a project; identifying follow-on actions; and project
evaluation review.
The PRINCE2 method works with most project management techniques but specifically
describes the following:
Scalability
Project management is a complex discipline and it would be wrong to assume that blind
application of PRINCE2 will result in a successful project. By the same token, it would be wrong
to assume that every aspect of PRINCE2 will be applicable to every project. For this reason
every process has a note on scalability. This provides guidance to the project manager (and
others involved in the project) as to how much of the process to apply. The positive aspect of this
is that PRINCE2 can be tailored to the needs of a particular project. The negative aspect is that
many of the essential elements of PRINCE2 can be omitted sometimes resulting in a PINO
project – Prince in Name Only. In order to counter this, APM Group have defined the concept of
a PRINCE2 Maturity Model.
Adoption
Divided into manageable stages, the method enables an efficient control of resources. On the
basis of close monitoring the project can be carried out in a controlled and organised way. Being
a structured method widely recognised and understood[citation needed], PRINCE2 provides a
common language for all participants in the project. The various management roles and
responsibilities involved in a project are fully described and are adaptable to suit the complexity
of the project and skills of the organisation.
PRINCE2 is sometimes considered inappropriate for small projects or where requirements are
expected to change, due to the work required in creating and maintaining documents, logs and
lists. However,the OGC claim that the methodology is scalable and can be tailored to suit the
specific requirements and constraints of the project and the environment.
Approaches
There are a number of approaches to managing project activities including agile, interactive,
incremental, and phased approaches.
Regardless of the methodology employed, careful consideration must be given to the overall
project objectives, timeline, and cost, as well as the roles and responsibilities of all participants
and stakeholders.
5. Project completion.
Not all the projects will visit every stage as projects can be terminated before they reach
completion. Some projects do not follow a structured planning and/or monitoring stages. Some
projects will go through steps 2, 3 and 4 multiple times.
Many industries use variations on these project stages. For example, when working on a brick
and mortar design and construction, projects will typically progress through stages like Pre-
Planning, Conceptual Design, Schematic Design, Design Development, Construction Drawings
(or Contract Documents), and Construction Administration. In software development, this
approach is often known as the waterfall model, i.e., one series of tasks after another in linear
sequence. In software development many organizations have adapted the Rational Unified
Process (RUP) to fit this methodology, although RUP does not require or explicitly recommend
this practice. Waterfall development works well for small, well defined projects, but often fails
in larger projects of undefined and ambiguous nature. The Cone of Uncertainty explains some of
this as the planning made on the initial phase of the project suffers from a high degree of
uncertainty. This becomes especially true as software development is often the realization of a
new or novel product. In projects where requirements have not been finalized and can change,
requirements management is used to develop an accurate and complete definition of the behavior
of software that can serve as the basis for software development. While the terms may differ
from industry to industry, the actual stages typically follow common steps to problem solving —
"defining the problem, weighing options, choosing a path, implementation and evaluation."
Regardless of project type, the project plan should undergo Resource Leveling, and the longest
sequence of resource-constrained tasks should be identified as the critical chain. In multi-project
environments, resource leveling should be performed across projects. However, it is often
enough to identify (or simply select) a single "drum" resource—a resource that acts as a
constraint across projects—and stagger projects based on the availability of that single resource.
Planning and feedback loops in Extreme Programming (XP) with the time frames of the multiple
loops.
In critical studies of Project Management, it has been noted that several of these fundamentally
PERT-based models are not well suited for the multi-project company environment of today.
[citation needed] Most of them are aimed at very large-scale, one-time, non-routine projects, and
nowadays all kinds of management are expressed in terms of projects.
Using complex models for "projects" (or rather "tasks") spanning a few weeks has been proven
to cause unnecessary costs and low maneuverability in several cases. Instead, project
management experts try to identify different "lightweight" models, such as Agile Project
Management methods including Extreme Programming for software development and Scrum
techniques.
Event chain methodology is another method that complements critical path method and critical
chain project management methodologies.
Event chain methodology is an uncertainty modeling and schedule network analysis technique
that is focused on identifying and managing events and event chains that affect project schedules.
Event chain methodology helps to mitigate the negative impact of psychological heuristics and
biases, as well as to allow for easy modeling of uncertainties in the project schedules. Event
chain methodology is based on the following principles:
1. Probabilistic moment of risk: An activity (task) in most real life processes is not a
continuous uniform process. Tasks are affected by external events, which can occur at
some point in the middle of the task.
2. Event chains: Events can cause other events, which will create event chains. These event
chains can significantly affect the course of the project. Quantitative analysis is used to
determine a cumulative effect of these event chains on the project schedule.
3. Critical events or event chains: The single events or the event chains that have the most
potential to affect the projects are the “critical events” or “critical chains of events.” They
can be determined by the analysis.
4. Project tracking with events: Even if a project is partially completed and data about the
project duration, cost, and events occurred is available, it is still possible to refine
information about future potential events and helps to forecast future project
performance.
5. Event chain visualization: Events and event chains can be visualized using event chain
diagrams on a Gantt chart.
Process-based management
Also furthering the concept of project control is the incorporation of process-based management.
This area has been driven by the use of Maturity models such as the CMMI (Capability Maturity
Model Integration) and ISO/IEC15504 (SPICE - Software Process Improvement and Capability
Estimation).
Agile Project Management approaches based on the principles of human interaction management
are founded on a process view of human collaboration. This contrasts sharply with the traditional
approach. In the agile software development or flexible product development approach, the
project is seen as a series of relatively small tasks conceived and executed as the situation
demands in an adaptive manner, rather than as a completely pre-planned process.
Processes
Traditionally, project management includes a number of elements: four to five process groups,
and a control system. Regardless of the methodology or terminology used, the same basic project
management processes will be used.
Monitoring and controlling consists of those processes performed to observe project execution so
that potential problems can be identified in a timely manner and corrective action can be taken,
when necessary, to control the execution of the project. The key benefit is that project
performance is observed and measured regularly to identify variances from the project
management plan.
2. Monitoring the project variables (cost, effort, scope, etc.) against the project management
plan and the project performance baseline (where we should be);
3. Identify corrective actions to address issues and risks properly (How can we get on track
again);
4. Influencing the factors that could circumvent integrated change control so only approved
changes are implemented
Closing Process
Closing includes the formal acceptance of the project and the ending thereof. Administrative
activities include the archiving of the files and documenting lessons learned.
1. Project close: Finalize all activities across all of the process groups to formally close the
project or a project phase
2. Contract closure: Complete and settle each contract (including the resolution of any open
items) and close each contract applicable to the project or project phase.
Project control is that element of a project that keeps it on-track, on-time and within budget.
Project control begins early in the project with planning and ends late in the project with post-
implementation review, having a thorough involvement of each step in the process. Each project
should be assessed for the appropriate level of control needed: too much control is too time
consuming, too little control is very risky. If project control is not implemented correctly, the
cost to the business should be clarified in terms of errors, fixes, and additional audit fees.
Control systems are needed for cost, risk, quality, communication, time, change, procurement,
and human resources. In addition, auditors should consider how important the projects are to the
financial statements, how reliant the stakeholders are on controls, and how many controls exist.
Auditors should review the development process and procedures for how they are implemented.
The process of development and the quality of the final product may also be assessed if needed
or requested. A business may want the auditing firm to be involved throughout the process to
catch problems earlier on so that they can be fixed more easily. An auditor can serve as a
controls consultant as part of the development team or as an independent auditor as part of an
audit.
Businesses sometimes use formal systems development processes. These help assure that
systems are developed successfully. A formal process is more effective in creating strong
controls, and auditors should review this process to confirm that it is well designed and is
followed in practice. A good formal systems development plan outlines:
Project managers
A project manager is a professional in the field of project management. Project managers can
have the responsibility of the planning, execution, and closing of any project, typically relating to
construction industry, engineering, architecture, computing, or telecommunications. Many other
fields in the production engineering and design engineering and heavy industrial also have
project managers.
A project manager is the person accountable for accomplishing the stated project objectives. Key
project management responsibilities include creating clear and attainable project objectives,
building the project requirements, and managing the triple constraint for projects, which is cost,
time, and scope.
A project manager is often a client representative and has to determine and implement the exact
needs of the client, based on knowledge of the firm they are representing. The ability to adapt to
the various internal procedures of the contracting party, and to form close links with the
nominated representatives, is essential in ensuring that the key issues of cost, time, quality and
above all, client satisfaction, can be realized.
Like any human undertaking, projects need to be performed and delivered under certain
constraints. Traditionally, these constraints have been listed as "scope," "time," and "cost".These
are also referred to as the "project management triangle", where each side represents a constraint.
One side of the triangle cannot be changed without affecting the others. A further refinement of
the constraints separates product "quality" or "performance" from scope, and turns quality into a
fourth constraint.
The time constraint refers to the amount of time available to complete a project. The cost
constraint refers to the budgeted amount available for the project. The scope constraint refers to
what must be done to produce the project's end result. These three constraints are often
competing constraints: increased scope typically means increased time and increased cost, a tight
time constraint could mean increased costs and reduced scope, and a tight budget could mean
increased time and reduced scope.
The discipline of project management is about providing the tools and techniques that enable the
project team (not just the project manager) to organize their work to meet these constraints.