Definition of Project Success

I have recently read an article from CIO about project management, I strongly agreed to Tom Klein's comment: "Projects don't fail, the expectations do". Yes, unless something is purely digital (only "1" or "0"), otherwise, most of our measurements are "relative" basis and "the expectation" does play an important role of defining "success" or "failure".

So how do we define a project success?
I used to work in a company when it ran with a series of death-march network infrastructure projects (high risk, under resources, tight timelines.....). All of them were finally completed (actually, there was no chance for even a failure because of the nature of the projects were related to the fundamental IT system infrastructure of the company affecting the entire business operation [the bread & butter]). But I would not say those projects were successful indeed.

The hidden failure in a project success
Because the "death-march" project nature, those projects had to be executed using the "dotcom mode" (the mode of business development/operation during the dotcom era around 1996-2000) where everything proceeded in ad-hoc and agile basis without thorough planning, well-defined process, completed documentation, sufficient testing, and etc.
Eventually, those projects were completed, but affiliated with lots of negative side results: several production incidences during the project implementation stage affecting the business operations, demolishing the company's well established project management process,  damaging staff morale, high HR turnover and dismantled trust among teams (conflicts and politics in resources/priorities arrangement against other well planned projects).

In theory, the successful criteria of a project should be measured by its deliverable against original project objective in terms of time, scope, quality and realized business benefits. However, within a business entity, a project's success should also be measured in a holistic (program management) view where the indirect, intangible benefits (or loss) from the project should also be counted.

True Lies - Project Estimation

According to the latest results of the famous study by The Standish Group about the failures of projects (Chaos Report), "44% of projects were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used".

True Lies, copyright by 20th Century Fox Universal Pictures

But based on my wild guess (a very personal view), there are other "intended" reasons for the challenges/failures and I called these as "True Lies":

1. The project manger do knows the actual cost (at least, he/she knows the reliable estimate) of the project. But just because if he/she provides the actual estimate, he/she will never get the project approved (or he/she will be out of the job immediately). The only way is, therefore, provides an "acceptable" estimate (acceptable means the figures closed to the management expectation, no matter it is reasonable or not).
2. No matter what kind of project planning methodologies such as COCOMO, Function Points Analysis, Delphi techniques, and etc, all such methods are ballpark figures only (similar to sales forecast). The larger and the more complex the project, the higher the uncertainty (i.e. the degree of deviation). An estimate can only be accurate when the project is completed (or if there is same past project portfolios for reference). In reality, the project manager has only very limited resources to conduct proper planning (in terms of sufficient time, adequate resources and relevant past project portfolio reference). As a result, the degree of deviation (the error rate) should be inevitably higher.
3. For service providers, if they (salespersons, of course) quote the "true and realistic" estimates of project such as "half-year project timeline vs. the customer expectation of two months" for a tender, they won't have a chance to get the contract. In this case, other than the "budget" part (which affect the sales bonus/commission), the salesperson would only provide the "true lies" estimates (scope, quality, schedule and etc.) according to the customer's expectation, no matter they are achievable or not. The goal is to "get it first, fix it later", a kind of undesirable but inevitable ideology generated by the so-called "open market".

So when a project is kicked-off based on "true lies" estimates, it is another topic (or another big topic for a textbook) of the way of handling/managing it.

Euro Walk, Feb 2010

It was my first time visiting Europe (Rothenburg, Germany) in winter this Feb. Though, the weather was indeed freezing with snow, the place was so beautiful and peaceful (only a few tourists in the low season) and it was an enjoyable experience.

 

  

  

  

 

Besides, it was also my first time using digital heavy gear (my Lumix G1) for the travel shooting. The performance was good (using both the native Lumix 14-45mm zoom lens and the old Nikon AIs lens). But since there are so much more functions/features in digital photography compared with my analog day (especially when I am using full manual FM2), further practicing would be required (such as auto focus feature/constraint, WB characteristics, usage combination of ISO, shutter speed & aperture, etc.) in order to maximize the camera's capability for make good shots (actually, not to make lousy shots).

  

 

Digitization

After years of staying in the "analog" age, I have finally stepped into the "digital" era recently.

For my coming travel journey, my FM2 has a new company: Lumix G1, my first digital SLR camera (not including DC, of course).

Though G1 is not the best DSLR camera (actually, it is not DSLR, but micro 4/3 format), I found it suitable for my transformation (from analog to digital) where I can use my old Nikon lenses with it (kind of resource fully utilization for environmental protection) with image quality comparable to DSLR.

Let see how it performs! (My FM2 will definitely be with me in the journey)