In fact, most of the “methodologies” in use are actually project management processes, which attempt to encapsulate and standardize the project management lifecycle. Typically, a “methodology” is at a much higher level, a more “strategic” definition of project management. The project management process or lifecycle is a “tactical” view of the project management work – it defines not only “what” is to do; but also “how” you will accomplish the work.

Typically, a project management process follows a flow similar to the “Plan-Do-Check-Act” cycle, defined by Shewhart and modified by Deming (from the ASQ Handbook, pages 13-14, 1999). Simply, the phases or steps of the PDCA cycle are linked together by results – the result of one step becomes the input to another.

A successful project management process must address the various phases of the project lifecycle. In some cases the work phases are arbitrary, based on organizational project practices. In all cases, the phases are well defined and the transition from one work phase to another typically involves the transfer of some sort of deliverable (a document, piece of software, invoice, bill of materials, report, etc.)

Alignment between project management processes and the project lifecycle is driven by project work, deliverables, and milestones. Although project lifecycle phases appear to be sequential, involving the exchange and approval of deliverables, the vast majority of all projects are actually highly iterative. Work phases of a project are defined by specific schedule milestones and deliverables, or Work Product.

Project management steps or phases of the project lifecycle are similar to those of most project management processes.

The project management process defines the following
what work needs to be accomplished in each project phase
Who performs the work in each project phase
When the deliverables are produced and delivered in each project phase
Who is responsible for review and approval of each deliverable
How the delivery, review and approval of each deliverable, as well as the work of each project phase, is monitored and controlled

The criteria which determines the conclusion of the project phase and the initiation of the next phase
What is the deliverable acceptance criteria
Which group is responsible for the deliverable requirements, review, and acceptance

Typically, the project management process includes the following project characteristics:

Stakeholders have much more ability to influence the project (cost, deliverables, resources, and schedule) earlier in the project rather than later

Project costs and resource levels begin low, peak during the middle phases (the Project Execution steps), and drop-off as the project nears closure

Project risk and uncertainty are highest early in the project and will typically reduce as the project progresses – assuming it is on-schedule and on-budget

The project management process defined by the PMBOK®, from PMI, mirrors the typical project lifecycle phases. Remember that all organizations apply the phases of the project lifecycle differently; and even differently for different projects. For example, one company may apply a single design phase while another might apply 2 or more design phases during a single project.

Throughout the pages of this website, I will assist you in bringing the application of the project management process to a tactical level. I will also work with you to align the project management process phases to the project lifecycle phases within your organization.

Project Management Statistics and Performance

Poorly planned, mismanaged, undisciplined and poorly executed projects are doomed to failure... So what else is new, right? Read on...

Some statistics I gathered look like this:

if a project is in trouble within 15% into the project, the project will never recover and stay in trouble through completion (from a DOD study of over 700 projects).

it almost always takes twice as long to complete a task as what we originally thought it would take (more a “true-ism” than a statistic).

70% of projects fail to deliver the benefits anticipated at the outset.

a government study (GAO) showed that major projects were overrunning budgets by 75% on average and that the huge projects ($1B and over) were 14% over budget. Seven years later, these overruns were measured at 140% and 189% respectively.

using the "80/20 Rule", we will typically accomplish 80% of our results using 20% of our resources. While the other 20% of additional results comes from using about 80% of our resources. (Again probably more of a truism.)

over 90% of project failures are due to poor planning.

A 1998 Information Technology project survey (seems old, but is still quoted) of 203 participants indicated the following reasons for failure:

75% deadlines missed,

55% budget exceeded,

40% poor communications,

37% unmet project requirements.

The same survey indicated the following as project success factors:

51% meet milestone objectives,

32% maintain quality levels,

31% meet budget objectives.

According to most studies in this area, poor software implementation is due to bad or poorly articulated requirements. Many experts agree that 40-60 percent of software defects and failures are attributed to bad requirements.

Most who quote project management failure statistics are quoting, usually out of context, from a 1994 report by The Standish Group, called the CHAOS Report.

The Standish Group has been producing and updating its research report since 1994. Their report on project performance, called The CHAOS Report of 1994 documented sobering statistics: 31.1 percent of projects cancelled, 52.7 percent "challenged" (completed over budget and/or behind schedule), and just 16.2 percent successful. An updated report, 2003 CHAOS Chronicles, shows a 50 percent improvement in project success rates.

Even though statistics may look gloomy, they are continually improving due to:

Increasing discipline among company leaders, focused on projects as implementing change and ensuring that project meet ROI thresholds

All of these reasons, along with your search for the best information, tools, and coaching (by using this web site) means that project success rates will continue to increase – and we will all win.

PMBOK® -- Project Management Body of Knowledge

The Project Management discipline mentioned above is embodied in the various, proven project management processes, such as PMI's PMBOK® (Project Management Body of Knowledge) and the OGC's PRINCE2®. Although these are often called “methodologies”, they play a dual role. They provide the tactical tools and guidance for you as a Project Manager and for your Project Team Members to effectively and successfully manage projects to conclusion.

Although I have worked projects in the UK (in England) which used PRINCE® and PRINCE2®, I am most familiar with PMI’s PMBOK®. Although less a project management process than PRINCE2, PMBOK® provides high-level structure through its project lifecycle, called Project Process Groups.

PMBOK® further defines the Inputs and Outputs for each individual project management process within each of the 5 Process Groups. There is enough detail within all of the 44 project management process, grouped under the 5 process groups, to provide specific tactical project management steps, tools and templates.

As stated in the PMBOK® Guide (3rd Edition), for your project to be successful, you must work with your team to:

”… all of the activities of the performing organization that determine quality policies, objectives, and responsibilities so that the project will satisfy the needs for which it was undertaken. It implements the quality management system through the policy, procedures, and processes of quality planning, quality assurance, and quality control, with continuous process improvement activities conducted throughout, as appropriate.”

As you can see from the definition, the PMBOK® provides a somewhat “basic” and “general” approach to project quality management. According to the PMBOK® Guide, this is done on purpose to allow for compatibility with the various approaches to quality, as might be implemented within your organization or your client’s organization. The PMBOK® approach is compatible with ISO, TQM, Six Sigma, Cost of Quality (COQ), Continuous Improvement and others. It also is compatible with approaches espoused by Deming, Juran, Crosby, and others in this field.

PRINCE2® is an “open” method, meaning no license fees. It is sponsored by the UK government's Office of Government Commerce (OGC) and recognized as best practice project management process. A basic difference, among others, is that PMBOK® is customer requirements driven, such as in delivering customized software, while PRINCE2® is business case driven, such as in building a software product.

The layout of PRINCE2® is comparable to PMBOK® and the two are in close alignment in many areas. One of these is Project Quality Management, with the difference that PRINCE2® provides a more tactical, process-based approach than PMBOK®. PRINCE2’s approach to project quality management consists of:

The basis of solid Project Quality Management is the discipline of your project management process and the rigor with which you apply it, as the Project Manager. Next, you as the PM must comply with your organization’s (or your customer’s) quality policies and procedures.

(Does your organization have an enterprise-wide quality initiative?)

Finally, you must be rigorous and consistent in your application of your Project Quality Management Plan (which is an important component of your overall Project Management Plan.

(I will address the above topics in more detail throughout this web site, as we continue to define project management.)