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
download.

Project Management
Best Practices

by Geoff Keston

Docid: 00011206

Publication Date: 2012

Report Type: TUTORIAL

Preview

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.

Executive Summary

[return to top of this
report]

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.

Related Faulkner Reports

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
end-users
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.

Description

[return to top of this
report]

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
them.

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 include: 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 timeframe. 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.¹

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
categories:

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.

Trends

[return to top of this
report]

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.²
The field is growing increasingly data-driven, using Big Data and
artificial intelligence to analyze projects and to make decisions.³
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.⁴

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 failure. 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 productivity.
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 management. 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.

Recommendations

[return to top of this
report]

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
quality.

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.

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.

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.

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.

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.

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.

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.

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.

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
  (objectives).

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

An attribute (cost, time, number of defects).
A metric (US dollars, weeks).
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
below.

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.

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.

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
affected.

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.

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).

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
  results.
- Delivering quality.

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.

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
levels.

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.

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.

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
projects.

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
parties.

References

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

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

³ Ibid.

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

Web Links

[return to top of this
report]

Agile Development: http://www.agilealliance.com/
Extreme Programming: http://www.extremeprogramming.org/
Project Management Institute (PMI): http://www.pmi.org/
Rational Unified Process: http://www-01.ibm.com/software/rational/

About the Author

[return to top of this
report]

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
report]