Project Management Best Practices

PDF version of this report
You must have Adobe Acrobat reader to view, save, or print PDF files. The
reader is available for free

Project Management
Best Practices

by Geoff Keston

Docid: 00011206

Publication Date: 2012

Report Type: TUTORIAL


Project management best practices can greatly improve the success
rate for undertakings in an enterprise. When using such traditional
measurements as coming in on time, within budget, and with
all specified functionality, most estimates show that well under half
of all projects are completed within the original parameters. When best
practices are properly applied, however, these estimates improve
dramatically. Many, but not all, of the same principles can be applied to
both “waterfall” and “agile” projects.

Report Contents:

Executive Summary

[return to top of this

IT projects have a reputation as being likely to fail in some significant
way, and budget overruns on technology projects are considered the rule
rather than the exception. Larger projects are significantly more likely to
fail than smaller ones.


Project Management Software Market Trends

Agile Software Development Tutorial

Most failures are due to some combination of:

  • Lack of executive sponsorship
  • Arbitrary delivery deadlines
  • Inadequately trained or inexperienced project managers
  • Application of an inappropriate project management methodology
  • Little or no day-to-day involvement by knowledgeable, dedicated
  • Vague or incomplete requirements
  • Uncontrolled change propagation (“scope creep”)
  • Inadequate written and oral communications
  • The failure to break large projects into smaller, more readily
    addressed chunks
  • Poor costing and schedule estimation

Project management best practices, when applied by a competent project
manager and championed by senior management, can mitigate or even
eliminate these issues. The most important best practice is constant and
thorough communication expedited by a trained and experienced project
manager. Other important practices include treating large projects as a
collection of smaller ones (known as a program) and using agile product
development techniques.


[return to top of this

A project is a non-repeating effort to create a unique product or
service. In other words, a project has a start, a set of procedures, and a
definable and measurable goal or outcome.

The success of a project depends on balancing what is commonly known as
the “Triple Constraint” of (a) quality and scope, (b) schedule, and (c)
cost. Taken together, these three are often described as “better, faster,
cheaper.” Although the Triple Constraint has been modified in many
presentations to include other elements, it still successfully
demonstrates the fundamental fact that a change in one important element
of a project always necessitates an alteration in one or more of the
others. For example, if the schedule is shortened, the project can often
only succeed if the quality (scope) of the project is reduced or if more
resources are added at an additional cost. Often, it will require both.
The Triple Constraint and its variations is a basic project planning
concept because it is always a factor in the continual revision of the
original plan as the project progresses.

Project plans typically take into account constraints, assumptions, and
risks regarding cost, schedule, resources, and performance requirements.
Projects measure success in terms of meeting time and cost targets
and achieving the specified functionality. Other meaningful measurements
are whether or not the project achieves the benefits expected in the
project justification, and whether or not clients actually use the
system once it is delivered.

Project management best practices attempt to manage constraints and
related factors through planning and control processes. Project management
cannot eliminate all the obstacles in the way of a successful completion,
but it can minimize those obstacles and provide mechanisms for managing

Since 1984, a central agent in project management best practices has been
the Project Management Institute (PMI), the recognized standards body for
the practice of project management, with chapters in over 200 countries. A
Guide to the Project Management Body of Knowledge
(the “PMBOK” or
“PMBOK Guide”), the standards document of the PMI, is approved by the
American National Standards Institute (ANSI), and its professional
certifications are the preeminent professional credentials for individuals
associated with project management. In 1999, PMI became the first
organization in the world to have its Certification Program attain
International Organization for Standardization (ISO) 9001 recognition.

The PMBOK methodology sets out best practices including knowledge,
skills, tools, processes, and competencies to meet the requirements of a
particular project. PMBOK defines a number of knowledge areas: Project
Integration, Scope, Time, Cost, Quality, Human Resources, Communications,
Risk, and Procurement Management, as well as five “Process Groups”:
Initiating Processes, Planning Processes, Executing Processes, Monitoring
and Controlling Processes, and Closing Processes.

PMI now publishes an edition of the PMBOK covering both “waterfall” and
“agile” methods. There are several approaches to developing software
systems in a structured fashion, but the most widely known and used are
the Waterfall Method, the Rational Unified Process (RUP), and Agile
Programming, examples of which are Extreme Programming and Scrum. None of
these is by definition a “best practice” to the exclusion of the others
and any can be used. The decision on when to use one or the other must be
determined by circumstances as outlined in Table 1 (below).

Table 1. General Approaches to Project Management
Approach Description Use When…

Waterfall Method

The Waterfall Method is the classic system development model.
It is essentially linear in design and discontinuous in the
sense that one phase must be completed before the next is begun.
Ideally in a waterfall project, all the requirements are
understood at the beginning of the project. Typical phases

  • Requirements
  • Architectural design
  • Detailed design
  • Coding and development
  • Testing and implementation

The Waterfall Method reduces planning overhead because the bulk
of the planning is done before the development steps begin and
its structure minimizes wasted effort.

On the other hand, it is relatively inflexible in its focus on
the final project deliverable. Also, retracing steps to address
mistakes or omissions can be difficult.

The Waterfall Method works well for traditionally organized
shops, for technically weak or inexperienced staff, and for
organizations that must create a complete budget in advance of
work performed. The Waterfall Method is the most familiar of
project management approaches, and a transition to other
approaches must be carefully managed.

Waterfall performs well for projects with clearly understood
requirements, but its weaknesses frequently cause difficulties
when rapid development is needed. In those cases, an RUP or
Agile approach may be more effective.

Rational Unified Process (RUP)

The RUP, created by IBM Rational, divides software
development into four phases: inception, elaboration,
construction, and transition. Some or all of the steps in the
waterfall approach are repeated one or more times for each RUP
phase. While the RUP encompasses a large number of different
activities, it is also intended to be customized, using only the
development processes appropriate to a particular software
project or development organization being utilized.

The RUP is recognized as particularly applicable to larger
software development teams working on large projects. It has the
strengths of the waterfall approach, and has the added benefit
of lending itself fairly readily to a modified agile approach.

Agile Programming

Agile Programming is more a product development methodology
than a project management methodology. It is a “lightweight”
iterative methodology, and when applied properly to the
appropriate project has proven to be an effective approach. It
emphasizes short intervals between deliverables, and depends
heavily on knowledgeable users working closely with both
developers and clients on a frequent, sometimes daily basis. The
developer builds something, reviews it with the client, and
revises it immediately based on feedback received.

Extreme programming (XP), one variety of Agile Programming, is
based on the assumption that project requirements will always
change during the course of a project. Scrum, another agile
programming approach, centers around a daily project session
called a Standup Meeting in which the work team’s assignments
are realigned in light of the previous day’s work and any
changes to the project scope that have been recently received.

All forms of agile programming are based on the immediate
development of deliverables.

Agile programming approaches are most effective when:

  • The users are active participants.
  • There is no push to deliver on a fixed budget and/or
  • Heavy duty documentation is not a major requirement.

They are least recommended when:

  • Documentation, such as a requirements document for sign-off
    by one or more project stakeholders or system documentation
    for use by maintenance staff, is a major deliverable.
  • Fixed cost and/or delivery dates must be adhered to.
  • The users have limited involvement with day-to-day
    project efforts; rather they are involved with initial
    development of requirements, perhaps are available on a
    limited basis to answer questions, and at a later date are
    involved in one or more acceptance reviews of the work.
  • The project requires delivering models and/or documentation
    to another team which will then evolve the system further.

Most Common Causes of Project Failure

The idea that many IT projects fail is a longstanding belief, but
information about failure rates and causes has been largely anecdotal, or
purported statistics tend to be repeated without their origin being clear.
But in 2020, a rigorous scholarly study of five large, fixed-price
government projects was published by Soren Lausen, a professor at the IT
University of Copenhagen.1

The study identified 37 causes of failures and suggested 22 remedies. On
a single project, there were an average of 15 causes, suggesting that
problems are typically complex. Problems can occur in any phase of the
project. Lausen divides the problems he identified into the following

  • Analysis
  • Acquisition
  • Design
  • Programming
  • Test
  • Deployment
  • Management

Lausen contends that more potential causes will likely be found as more
cases are analyzed. But performing such cases studies requires significant
time. “An investigation of this kind takes around 9 months,” he says. “You
don’t just make dozens of such investigations. You have to catch the
opportunity when it occurs.” The effort needed to analyze IT projects in
depth will deter other researchers, limiting the amount of information
available about failures.

Some of the types of problems commonly reported in the industry are
described below.

Poor Up-Front Planning. Many times
a lack of planning causes different parties to have different visions of
what the project will entail. Also, poor planning makes it difficult to
anticipate problems that may crop up. Many times determining who will
repair the problem has to be negotiated on the fly, causing further delays
and adding to costs.

Too Large a Project Scope. There is
increasing awareness in the project management world that many projects fail
simply because they are too big. This fact underlies much of the success of
Agile product development, which operates in small, incremental steps. Even
a larger, more traditionally managed project may still profitably be divided
into a group of smaller projects.

Incomplete, Vague, or Arbitrary Project Work Plan.
The work plan or schedule is the roadmap for how the project will
be completed. If the plan is developed at too high a level, is incomplete,
or is not current, problems can surface quickly – problems that may prove
fatal to the project. Arbitrary time deadlines set by management can be
particularly destructive to project success.

Weak Ongoing Project Management Discipline. It
is not enough to put together a plan, no matter how good it is. Ongoing
management is needed to maintain momentum, manage scope changes, resolve
issues, communicate with team members, and manage project risks.

Inadequate Resources. Lack of
resources results in many project failures. The lack may come from
inadequate planning, lack of management commitment, lack of skilled
personnel, lack of funding, or arbitrary deadlines that guarantee
resources will not be available at important times.

People Problems. Many
times problems involving relationships between staff members are
ignored until the project is close to failure. Problems should be handled
immediately before they escalate. Often pre-existing problems begin to
surface only after a project shows signs of trouble. It is crucial to
address these interpersonal problems while there is time.

Lifecycle Problems. Problems may
surface throughout the development lifecycle and may cascade as the
project progresses, leading to major trouble. A crucial principle in
project management best practices is to anticipate as many difficulties as
possible in advance of the actual development work. Examples of lifecycle
problems include:

  • A failure to clearly and completely define requirements,
    resulting in building the wrong features or leaving gaps in features.
  • New or state of the art technology may cause unanticipated problems.
  • A poor technical design that does not allow the solution to be easily
    modified or is not scalable.
  • Requirements that are not frozen in the later stages of the project.
  • Continued change requests which cause the project to drift; this is
    commonly referred to as “scope creep.”
  • Technological components that do not fit together as designed.
  • Poor initial testing techniques that cause repeated errors and require
    reworking in later tests.

Given the high cost of project failure, understanding the most common
causes and the best practices that mitigate or eliminate them is the most
productive approach to improving delivery in terms of the Triple
Constraint – scope (quality), time, and resources (cost).

Poor Communication. In many ways
communication is at the heart of the preceding problems. A basic
assumption behind project management best practices is that people who
know what is going on are best able to direct and control events;
conversely, an uninformed staff has no opportunity to anticipate events,
much less to control them. 

It is difficult for project management to overcommunicate. However, staff
members have their own individual communications styles and a project
manager must identify those styles and ensure that communication works in
an effective way for each individual. The project manager must communicate
horizontally and vertically (both “down” and “up”). Horizontal
communication applies to customers and stakeholders; vertically down
communication is to the staff working on the project, and vertically up
goes to senior management. In all cases, the goal is the sharing of real
time information about project status, problems, and needs.

[return to top of this

Project management is a well-established discipline. The methodologies
described in the Project Management Institute’s PMBOK, the main reference
source for the discipline, are widely practiced around the world. But
while the field is largely characterized by stability, there are
indications that it is changing or expanding in some notable ways:

  • More project managers are using multiple methodologies rather than
    just their preferred methodology.2
  • The field is growing increasingly data-driven, using Big Data and
    artificial intelligence to analyze projects and to make decisions.3
  • Practices in the field are making wider use of digital technologies,
    and a growing number of projects are focused on digital transformations
    of other business functions.4

Table 2 summarizes other trends driving today’s projects and illustrates
the need for project management best practices, whether the project is
waterfall or agile in style.

Table 2. Trends
Trend Description

Better, faster project decision-making

The pressures for project managers to meet tight deadlines
continues to increase, particularly with today’s tightening
budgets. It is difficult to say no to an arbitrary management
deadline, but often the alternative may be almost certain

Project managers need to deploy best practices when choosing
projects, knowing when to discourage prospective ventures
that won’t deliver a solid return on investment (ROI) and when
to encourage promising projects.

Codependency between project management and enterprise analysis

In active knowledge-management transfer, project managers with
greater experience levels and an interest in functions such as
risk management are taking on traditional business analyst (BA)
responsibilities, including enterprise analysis, recognizing
that the aim of project management is not its own success but
the success of the organization.

Critical thinking as a key project management competency

Technical competence alone doesn’t create success. Project
management has evolved into a robust discipline, and critical
thinking is a key soft skill that can make the difference
between success and failure. A good project manager can also
make a significant difference in the level of staff

Emerging relevance of the project management office

Project management offices (PMOs) are designed to ensure a
greater chance for organizations to reach their goals by
streamlining processes, coordinating resources between projects,
and enabling more efficiency in day-to-day project

An effective PMO is particularly important for Project
Portfolio Management (PPM), the control of a related series of
projects selected because of their high priority in meeting the
needs of the enterprise. This is particularly so when larger
projects are split into smaller ones.

Investing in project management

Keeping projects on track and on budget can help to counter ill
effects of a stressed economy. Organizations are realizing that
an unsettled economy is an opportunity to invest in project
management training and development for optimal performance.

 Selection of project management techniques

Each project management approach has its champions, who are
often fervent in their endorsement of one approach over another.
However, a “toolbox” approach is becoming increasingly popular,
in which a project manager selects from different approaches the
techniques that will work best for a specific project. 


[return to top of this

Project management best practices are those strategies, activities, and
approaches that have been proven through research and experience to be
most effective in improving project delivery time, cost, scope, and

An organization implementing or upgrading project management best
practices must emphasize to employees that it is not adding an additional
layer to an already busy work load but is acknowledging and turning into
procedures those principles that are followed by effective workers in any
situation. Project management best practices are common sense ideas
codified to add value to the enterprise by reducing costs and increasing
the quality of work.

The following are some of the most effective Project Management Best
Practices. No two projects are exactly alike. Since projects by their
nature are unique events, the following list may expand or contract for
specific projects or organizations. Some project documentation may be
revised based on issues that arise during project execution. In general,
these best practices apply in most situations.

  1. Focus the Project Carefully. A well-run project that
    accomplishes the wrong goal is no better than an inept project that
    fails to accomplish its goal. An important best practice is to revisit
    the central focus of the project on a regular basis in order to
    re-orient the team to its fundamental aims and uncover scope changes
    that may contradict or fail to contribute to the project’s main focus.

Project success or failure is largely a matter of perception rather than
of the objective fulfillment of criteria. That is to say, if the project
sponsor isn’t satisfied with the results of a project, the project will be
considered a failure even if it meets the criteria laid out by the project
sponsor. Every effort must be made to focus the project, not just on its
requirements, but on the reasons behind the requirements as well.

One study indicates that almost half of all proposed projects add little
or no value to the enterprise they are designed to help. This statistic is
a reminder that a pointless project well executed is of little benefit to
the enterprise. A frequent temptation among IT staff is to propose a
technological solution that dwarfs in size the minor difficulty it is
intended to overcome.

Projects should begin with project charters and scope statements, in
order to make the general, top-level direction of the project clear.

  1. Plan the Project Realistically. A project designed
    to meet an arbitrary date created by management faces high odds of
    failure, as does a project that is in effect “too large to manage.” A
    best practice in the project planning process is to create realistic
    estimates of the time and resources that will be needed for the project
    to succeed. “Magical thinking,” as one programmer has called it – the
    hope that a project will be successfully completed in an unrealistically
    short time period, just because management wants it to be – is the
    opposite of a best practice.
  1. Involve All Relevant Stakeholders in Project Planning.
    This simple action will improve the quality of the plan, utilize the
    planning skills of the project team members, and increase buy-in for
    delivery commitments made. The best way to perform planning is to
    involve all significant project resources (that is, people). After all,
    no one can estimate the time it will take to deliver a module better
    than the person who will code it. Similarly, no one can define desired
    functionality more effectively than the customer.

Although pointless meetings should always be avoided, certain meetings
are crucial to good project management. A “kickoff meeting” bringing
together as many participants in the project as possible can significantly
expand understanding of and commitment to the project, and subsequently
pay off in improved communication and participation throughout the life of
the project. A Work Breakdown Structure meeting, which begins the work of
identifying deliverables and tasks, assigning staff, and determining task
durations, and regular project status meetings, are also best practices.

  1. Designate an Executive Sponsor. Having an active and
    committed executive sponsor helps ensure quick and timely resolution
    when different user groups have conflicting requirements or when time,
    cost, and scope tradeoffs need to be made. A project without strong
    support from upper management is automatically at serious risk even as
    it begins.
  1. Assign a Qualified, Trained Project Manager. Too many
    projects are run by “accidental project managers,” employees with
    subject matter expertise but no formal training in project management
    techniques. Statistics show that the odds of an on time, within budget,
    fully functional deliverable increase significantly when a trained
    project manager – optimally one with PMP certification – is in
    charge of the project, allowing the subject matter experts to function
    in the ways for which they are best qualified.

A common mistake is to have several official or de facto “project
managers” for one project, often one for each department or group
involved. A “project lead” can coordinate the efforts of a particular
department or group, but one project manager must have overall
responsibility for a project. Clarify the command and reporting structure
at the beginning of a project. This is particularly important
because many project teams are “matrix” structures in which the
project manager has responsibility but not authority.

  1. Prepare Drafts of All Project Planning Documents (see
    below for further details):

    • Scope
    • Integrated Change Control Plan
    • Scheduling Baseline with estimated costs and projected resources
    • Quality Management Plan
    • Communications Plan
    • Risk Management Plan
    • Issue Management Plan

The saying that “what is written down gets accomplished” is particularly
true in project management. One major benefit of working on the documents
listed here is forcing the project manager to think through the risks,
resources, and processes of the project in a concrete way.

  1. Hold a Kickoff Meeting. The kickoff meeting is the
    time to get all the key project team members, clients, and stakeholders
    together and formally set the stage for the start of the project.

The purpose of the kickoff meeting is to ensure that everyone has the
same understanding of the project and of their roles and responsibilities;
to create buy-in; to build consensus and teamwork through collective
planning; to confirm initial estimates; to discuss how communications,
risks, issues, and change requests will be handled; and to identify open
items that require immediate follow up. The kickoff meeting is intended to
bring everyone up to speed, not to discuss every item in detail.

As a result of this meeting, some planning documents may need to be
updated, particularly the Communications Plan and the escalation
procedures for the Risk, Issue, and Integrated Change Management Plans.

  1. Carefully Define Scope, Including Objectives and Deliverables.
    The functionality baseline, along with a definition of how it will be
    measured, is the basis of scope planning. It includes:

    • A Scope Statement. This is used as the basis for
      making future decisions and for developing a common understanding of
      the scope between the builders, buyers, and potential users. It
      includes a project justification, a summary description of the end
      product, a list of summary-level deliverables (working code, user
      and technical documentation, and training), and success criteria

Each objective should include a “success metric” expressed in terms of
cost, schedule, quality, and benefit, each of which should have:

  1. An attribute (cost, time, number of defects).
  2. A metric (US dollars, weeks).
  3. A value (e.g., less than 1.5 million).

Non-quantified success criteria such as “greater customer satisfaction”
or “more external users,” although better than nothing, are
not metrics. To use (as an example) a project to improve customer
satisfaction, one would measure the level of customer satisfaction and/or
the execution speed and then set a goal based on that. For example, if
Customer Satisfaction is 4 on a 1 to 10 scale, then the goal of Customer
Satisfaction >= 6 is both meaningful and measurable. Similarly, if we
have five external paying customers and the objective is to have ten,
there isn’t any room for ambiguity in interpretation; the goal will be
missed, achieved, or exceeded. Remember that if a goal cannot be measured,
it cannot be managed or controlled.

    • A Scope Management Plan. Describes how scope
      changes will be requested and approved. See Integrated Change Control
  1. Hold a Meeting to Develop a Work Breakdown Structure (WBS).
    A WBS meeting is a brainstorming session, typically lasting several
    hours, in which subject matter experts for the project together
    create a list of project deliverables and the steps necessary to achieve
    them. The significance of holding a WBS meeting, as opposed to one
    person’s creating a WBS, is that almost always tasks are discovered in a
    WBS meeting that would otherwise be overlooked, since no one can know
    everything about a project.

A typical method for developing a WBS is to provide the group with
Post-Its and marking pens. When a project deliverable is suggested, it
becomes a top-level item, written on a Post-It and put on the wall, and
beneath it are added the tasks needed to accomplish each deliverable. When
the meeting is over, the project manager takes the Post-Its, separated by
deliverable, and enters them into the project schedule, which then
receives further development as the task list is refined and durations and
resources are added.

  1. Hold a Launch Meeting. The launch meeting is a
    kickoff meeting for developers. Depending on the complexity of the
    project, the size and general experience of the project team, and the
    level of detail covered, it can take from 2 to 8 hours.

The purpose of the launch meeting is the same as for the kickoff meeting,
including communicating relevant constraints or assumptions and planning
the sequence, dependencies, duration, and resource assignments of the work
to be performed. It is an unusual launch meeting that ends without any
follow-up required.

As a result of this meeting, some planning documents may need to be
updated, notably the work breakdown structure, activity list, sequence,
dependencies, durations, and resource assignments. As the project
continues, the project manager will continually bring the various project
documents up to date.

  1. Integrated Change Control. The formal description of
    change control as “the process of maintaining performance measurement
    baselines and coordinating changes for all cost, scope, and scheduling
    changes” does not begin to indicate the importance of this subject. It
    is the nature of waterfall projects for their scope to change as over
    time users modify – usually, increase – their requirements. If these
    changes are requested informally, the project may be significantly

It is critical to pre-define appropriate escalation criteria and approval
levels and procedures. For example, changes required to meet legal or
regulatory guidelines should be approved automatically, while “optional”
changes that adversely affect the delivery date or cost of the project
require the highest level of approval. All changes should be requested in
writing and subjected to a predefined review process.

  1. Schedule. Most project management software allows
    tracking what will be delivered when, including:
    • Major milestones and the formal process
      for handling requested changes (see Integrated Change Control).
    • Cost estimates, start and finish dates,
      resource assignments for each deliverable in the scope statement,
      procedures and guidelines for modifying cost estimates (see Integrated
      Change Control). The time-based project budget – when will what costs
      be incurred – is the performance measurement baseline for cost.
    • Cost Baseline – resource requirements *
      rates * hours + (other expenses).
  1. Quality. The most efficient way to approach quality
    management is to focus first on prevention, second on checking, and
    third on testing. The five steps that lead to high quality projects are:

    • Defining what qualities add value and
      how they will be measured.
    • Adding steps to the project process to
      control, ensure, and deliver quality.
    • Quality control – the process of
      reviewing work processes and deliverables to ensure quality and
      gather information for process improvement.
    • Quality assurance – the test procedures
      that are performed to ensure quality, as well as the auditing of the
    • Delivering quality.
  1. Communications Plan. The Communications Plan details
    how inter- and intra-project communications will occur. Recipients or
    attendees, senders or presenters, forms, media (hardcopy, email, etc.),
    and frequencies should be covered. The Communications Plan should not be
    merely a perfunctory listing of email addresses or phone numbers. For
    example, members of senior management tend to respond to different
    methods of communication. One executive may read all email and neglect
    phone messages; another may need to be approached in person. One
    approach will probably not reach all stakeholders efficiently. Best
    practice is for the project manager to find the appropriate methods, not
    method, of communication.
  1. Risk Management. Risk management includes an overview
    of the way risks will be identified and ranked, and the mitigation
    strategies for each significant risk. The objection is sometimes raised
    that if a risk were known, it would always be defended against, but this
    may not be the case. For example, there is a risk in depending on a
    subcontractor or outside vendor who may become unavailable for a period
    of time, and depending on the circumstances (for example, a single
    supplier) a company may simply have to take this risk. A risk may be
    ignored, handed off to another group or department, or mitigated as it
    occurs. Not every risk has the same importance, and the most serious
    should receive the most attention. As with Integrated Change Control, it
    is critical to pre-define appropriate escalation criteria and approval
  1. Issues Management Process. The Issues Management
    process ensures that each issue that arises is documented, prioritized,
    and resolved within appropriate time frames. An issue is defined as “any
    event that adversely affects the ability of the project to produce the
    required deliverables”. As with Integrated Change Control and Risk
    Management, it is critical to pre-define appropriate escalation criteria
    and approval levels.
  1. Project Plan. Frequently a project schedule is called
    a project plan, but unless a presentation called a “project plan” is
    being prepared as a document for a client, a project plan is really a
    collection of all project planning documents, including a project
    schedule broken down into measurable and manageable chunks of work with
    dates, dependencies, and resources; a Communications plan that includes
    reporting and meeting schedules and formats; a Quality Plan;
    and formally defined methods for identifying, escalating, and
    resolving risks, changes, and issues. A critical point is that the
    project plan is not static, and must be regularly updated with actual
    values in order to measure, manage, and control time and budget
    variations from the baseline.
  1. Break the Project into Smaller, More Manageable Sub-projects.
    Smaller projects and smaller project teams have a much higher success
    rate than enormous “big bang” projects. A project that contains too many
    dissimilar items may often be better structured as a number of separate

Continuing themes in these best practices include the skilled use of
project control documents; inclusive communication practices; and
aggressive risk management. It should be noted that all these best
practices can be at least generally applied to agile as well as to
waterfall styles of development.

In everything concerning project management, the ultimate best practice
is communication, and the most important function of the project manager
is to ensure continuing and thorough communication among all involved


1 Scott Lausen. “IT Project Failures, Causes and Cures.” IEEE
. April 2020.

2 Tim Stobierski. “Six Project Management Trends Emerging in
2021.” July 8, 2020.

3 Ibid.

4 Timo Braun, Eskil Ekstedt, Rolf A. Lundin, and Jörg Sydow.
“Digital Transformations of Traditional PBOs and Modern PNWs.”
Management Institute
. January 2020.

[return to top of this

About the Author

[return to top of this

Geoff Keston is the author of more than 250 articles
that help organizations find opportunities in business trends and
technology. He also works directly with clients to develop communications
strategies that improve processes and customer relationships. Mr. Keston
has worked as a project manager for a major technology consulting and
services company and is a Microsoft Certified Systems Engineer and a
Certified Novell Administrator.

[return to top of this