This paper is the second 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 September 2014.

PART 1 | Introduction | Stan Krupinski - Andrzej Wardaszka | Richard Stubbs
Brian Phillips | Max Wideman Introduces KPIs and KSIs | David Willcox | David Hatch
Larry Moore - Cliona O'Hanrahan | Mounir Ajam | PART 3

Stan Krupinski[4] Quotes Wikipedia, Andrzej Wardaszka[5] Compares Delivery with Business Case

Stan Krupinski

In Part 1 of this series, Stan quoted Wikipedia as describing the objectives of Project Management, in part, as follows:

"Project objectives define target status at the end of the project, the reaching of which is considered necessary for the achievement of planned benefits. They can be formulated as SMART: Specific, Measurable (or at least evaluable) achievement, Achievable (recently Agreed-to or Acceptable are used regularly as well), Realistic (given the current state of organizational resources) and Time terminated (bounded). The evaluation (measurement) occurs at the project closure."

Project success is based on whether or not the project delivered a value added product or service to the sponsoring organization. It is not based on whether or not the Project Manager successfully followed the PMBOK user manual. Meeting all the PMBOK requirements, and then delivering something useless is silly.

Andrzej Wardaszka

Because all projects have an end date, one should be able to declare success or failure at that point in time. Obviously, all you can do is compare actual results to baseline triple constraints.[6] In theory, if the team has met or exceeded the baselines, you should be allowed to declare the project a success at project close. However, I would now like to agree with Max earlier that this success can change or be re-evaluated later.

The investment decision to go ahead with a particular project relied on a business case. Over the years and months that follow, when the PM and project team have all moved on to bigger and better things, someone (hopefully) will track whether the return on investment meets what was promised in the business case. Based on that analysis, another assessment of whether the project was a 'success' will be performed.

This now really becomes a question of whether the project was a good business investment (and the sponsor should be solely accountable here). However, perception is reality. If there is a lingering feeling that the project was not a good decision, in time that will translate into the project being a failure. A project that was once initially viewed as a success, can later be viewed as a failure.

Introduction  Introduction

4. Stan Krupinski: Project Manager
5. Andrzej Wardaszka: Watson Solutions Project Manager at IBM
6. "Triple constraints" here means scope, quality, time and cost.
Home | Issacons | PM Glossary | Papers & Books | Max's Musings
Guest Articles | Contact Info | Search My Site | Site Map | Top of Page