This paper is the third of a four-part series in which an attempt has been made to capture the collective wisdom of the leading participants in an extended LinkedIn discussion over the first six months of 2014. The actual original texts have been edited for grammar and spelling to make for easier reading online. The observations quoted are the opinions and property of the contributors as noted.

Published here October 2014.

PART 2 | Introduction | Max Wideman's Thoughts for Further Discussion
Larry Moore | Max Wideman Intervenes with Other Suggestions
Larry Moore | Vince McGevna | Brian Phillips
Mounir Ajam - Cliona O'Hanrahan | David Hatch | PART 4

Larry Moore Points to How a Project is Defined

Whether a project is considered to be successful or a failure depends ultimately on how the project is defined. The definition of the project should include the definition of project success. If this is not included in the project definition, there is bound to be confusion and/or differences of opinions regarding the project's success or failure.

For all of my projects, the Project Charter includes a section called "Project Success Factors and Measures." This section includes a description of the critical factors that determine the success or failure of the project and the measures used to determine them. Once this description is accepted and agreed to by the project stakeholders, including the Project Sponsor, determining the success or failure of a project is simple and straightforward. If, upon completion of the project, all of the critical success factors have been met, the project is successful; there is no quibbling about this and the matter is settled. Whatever happens after this has no bearing on the project's success or failure.

Of course, after the project is completed, there might be issues with the PRODUCT of the project. It doesn't matter whether there are issues with the PRODUCT or not; if the entire project's documented success factors have been met by the project, it is by definition successful.

I fully understand that once a project is completed successfully, there still may be problems resulting from the project. However, it is not advisable to allow those problems to redefine a project from successful to failure after it is completed because of those problems.

From the project manager 's perspective, allowing the success-or-failure determination to happen well after the project has been completed is a very bad idea. Failure to include explicit success factors in the project charter and/or plan is also a bad idea. Basing the determination of success or failure of a project solely on the satisfaction of all stakeholders is also a very bad idea. In my experience, almost all IT projects lead to someone being dissatisfied or unhappy in some way. The big mistake is allowing projects to be defined and/or redefined without including specific and measurable success factors that are agreed upon throughout the project.

Of course, the product/results of a successful project might not meet every one of the organization's goals and objectives for the product, but that does not mean the project itself was a failure. Failure to meet all objectives happens frequently with IT projects and products; that doesn't mean that the project failed. If the follow-on success of the PRODUCT of a project is critical, include that in the scope of the project or have a separate follow-on project to provide for this.

Max Wideman Intervenes with Other Suggestions  Max Wideman Intervenes with Other Suggestions

Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page