Please login or join to subscribe to this thread
In the field of systems architecture, one of the first steps is to define the desired qualities of the system to be developed that differentiate success from failure. These are often referred to as the "ilities"
Examples: Affordability, Producability, Reliability, Maintainability, etc.
Well, time, cost and scope are project objectives (or should be). There can be more like quality. Even if often omitted as objective, the overarching objective is satisfaction of the key stakeholders. If those are happy, you can forget the rest. That's why stakeholder management is so important.
As for the value, it is mostly achieved after the project has delivered its output. So it would be unfair to ask the project manager to ensure that the value is delivered (though it is done sometimes, in the need of someone to blame).
Project objectives are the same of project success factors. The problem, something I debate lot of times with the PMI groups, is most of the people assign product success factors as project success factors which is totally wrong due to all related of product is outside the project except for the activities to create it as defined, in the time needed and with all the characteristics needed. Then, the only thing a project manager can manage is time, scope, quality and cost (not budged). Let me give an example. I saw lot of times "the project will help us to grow 5% in market share in the current year". Totally wrong. The organization will growth with the product the project will create so the only thing "the project" can do is to assure that the defined product will be created in the needed time, with the needed quality, using the assigned cost as expected. No more than that. By the way, all related to product definition as a key component of the solution is on hands of business analysis.
While project measures don't apply at the product or system level, they do apply at the architecture level, which includes the environment. It could never be an effective product if it can't fit the market needs in terms of timeliness and affordability. While they're not TPMs, they're still KPAs.
I think that can be reversed and we can say that product success is a necessary attribute of project success as whatever defines product success are the qualities valued by the customer. On time and within budget is no good unless it produced the expected value.
Time, scope and cost are the project objectives/success factors but value creation is equally important. A project will not lead to the business outcome as is but it will position the organisation to achieve the desired results over-time by creating the product or service for which it was originally initiated. I have been on teams where a project was a super success in terms of time and cost but it was termed a failure because it could not achieve the desired business outcome and vision. This could vary with organisation though. Some times projects fail due to lack of effective change management from stakeholder perspective.
Thanks to all of you for sharing valuable points.
Alok, there is also a difference between objectives and critical success factors.
wikipedia: "Critical success factors are those few things that must go well to ensure success for a manager or an organization and, therefore, they represent those managerial or enterprise areas that must be given special and continual attention to bring about high performance. CSFs include issues vital to an organization's current operating activities and to its future success."
CSFs for a project are the prerequisites to make achievement of the particular objectives (scope, time, cost etc) more probable. They are different per project situation, but could be just modeled after the 10 PMBoK knowledge areas. As to many surveys why projects go wrong, I would suggest that key CSFs are attacking these key reasons for project failures:
- stakeholder analysis and engagement
- scope management
Please login or join to reply