Discussion
Core Concepts Generally
Issue #1: Do we really need "Core Concepts of Project Management"?
Most people seem to have managed very well without recognizing them, that is, until the trouble starts. Most projects take place in a corporate environment but the approach to corporate management and to project management are very different. Indeed, the reality is that many managements place obstacles in the way of project progress, perhaps unwittingly because of management's classic functional heritage.
Marie Scotto has provided a compelling list of differences in approach between general management and project management.[11] Perhaps the most significant is that "The business community believes in understaffing which it can prove is generally good business most of the time." In contrast, projects are especially risky by their nature and need a margin of surplus if for no other reason than to take care of contingencies and risks. For a project to be under-resourced is a recipe for failure. Consequently, a set of credible Core Concepts is not only needed to provide a robust underpinning for project management learning, but also for making a convincing case to corporate management for providing the necessary support.
Issue #2: Management of the Project versus the Technology
Can we really separate project management from technology management? This is an issue for most people who suggest that it cannot be done, even though they may agree that there are differences. The reason is that in practice, decisions made in the technology management domain and decisions made in the business domain shape decisions made in the project management domain due to contextual dependencies. Similarly, project management decisions also shape decisions in the other two domains.
But consider the analogy of the human body. The human body cannot function without, say, the brain or the heart. Conversely, the brain or heart has no use without the rest of the body that they serve. All bodily components must be fully integrated for a properly functional unit. Nevertheless, that does not stop us from studying the brain and heart organs in great detail as distinct functions and, in particular, comparing them across a variety of types of people!
Issue #3: What should be included as a Core Concept and what excluded?
The key criterion is taken to be whether or not the principle is universally fundamental to project success as defined. For example, without some form of commitment there can be no project and hence no possibility of success. On the other hand, there are many major tools and techniques the application of which might be considered as essential to success.
For example, a formal work breakdown structure, schedule network, earned value analysis, change control process and so on might be included. However, projects in many application areas are run successfully without applying these tools. So, while they may be considered good practice, they are not necessarily essential. Each such tool undoubtedly relies on its own set of concepts that may be considered as secondary to the Core Concepts.
Success Concepts:
Issue #4: It has been suggested that the issue of success is so obvious as to be unworthy of a core concept.
However obvious and sensible the setting of project success criteria at the beginning of a project may seem, regretfully, it is not always a common practice. Without defining these success criteria, how can agreement be reached on a particular project's priorities, trade-offs, the significance of changes, and the overall effectiveness and efficiency of the project's management? For this reason, a lot of conclusions drawn from surveys and similar experiential material could be very questionable.
Contrary to conventional wisdom, there have been many projects that have been "On time and within budget" but the product has not been successful, and similarly many that have not been "On time and within budget" yet by other measures the product has been very successful. Motorola's Iridium is a classic example of the former while the movie Titanic is a good example of the latter.
We believe that project success is much more than just "Doing what you set out to do". It is also about whether what you are doing is in fact the right thing to do. We believe that the ultimate goal of a project, and therefore its measure of success, should be the extent to which the product is capable of producing the intended benefits within reasonable time and cost constraints and hence the general satisfaction amongst the parties including the "customer". As noted earlier, the assumption is that the customer is clearly identified.
As Gerald Neal points out, the reality of life on many projects is that everyone on or associated with it does not have the same aspirations and goals.[12] As a result "the project gets pulled in many different directions ... [by] ... status, pride, power, greed ... ". In most cases, this may be a little exaggerated, but even at the most elementary level, the project owner will be interested in benefiting from the product while the workers on the project will be interested in benefiting from the process. This makes the definition of a project's success even more important — to provide a reference baseline for the correction of divergent progress.
So, success for a project and how it will be measured after completion does need to be defined at the beginning of the project. The most important reason is to provide an on-going basis for management decision-making during the course of the project even though the understanding of that success may mature during its course. Hence the need for continuously ensuring alignment with the project's Business Case, and the project's Business Case with corporate objectives.
Commitment Concept:
Issue #5: It has been suggested that there should be a "Business Principle".
That is, a principle that states that the project must be in alignment with the sponsoring organization's goals. This is a valid comment, but this connection is in fact embedded in the Project System concept requiring that a robust and up-to-date Business Case is established and maintained to drive appropriate decision making throughout the project life cycle. It is corporate management's responsibility to determine the relevance and soundness of the Business Case before giving project approval to proceed to the next phase.
Issue #6: Similar to Issue #5, it has been suggested that there should be a separate "Technical Principle".
The issue here is that the project leader and team members must be knowledgeable in the technology of the product. This is certainly true, but this is covered by the Commitment concept in that an Equitable Commitment is not possible without a sufficient understanding of the project, its technology, and especially the major risks involved.
Issue #7: It must be recognized that every project "evolves" through its life cycle and the commitment and tradeoffs will similarly evolve.
On most projects the players will also change, as it moves through its life cycle, simply to meet the changing level of effort and different skills required in each phase. Nevertheless, an equitable commitment can and should exist for every phase of the project if the project is to remain viable.
Once again, in the real world, many projects are not set up this way. Resources are short changed or reprioritized and unattainable deadlines are set, often for the reasons described by Marie Scotto (see Issue #1 above.) Thus, the absence of consistent definitions of success and commitments simply means that the probability of success is greatly diminished — if not impossible.
The five-point inherent trade-off concept:
Issue #8: It is a sad reflection on general management that more time seems to be spent on budget numbers that, after all are just estimates with some manipulation for risk and contingencies. More time, that is, than that focused on the direct linkage between actual work on the project and the resulting cost and schedule recorded.
It need hardly be added that the phenomenon of "scope creep" and consequent time and cost overruns are direct consequences of a lack of understanding and attention to this linkage. There is a feeling that "just a little bit will not be noticed." It always is.
To clarify, there are four separate but interrelated variables involved: scope, quality, time and cost.[13] Thus, quality,[14] the most enduring variable of the four when it comes to project success, is given new prominence. It should be stressed here that quality means Quality Grade, i.e. the measure of level or class (utility to world-class) as distinct from Quality Conformance, i.e. "conformance to specified requirements".
There is, however, another variable that impacts the relationship between the project work and the time and cost of record, and that is the skills and experience and hence efficiency of those doing the work on the project. The more "expertise" the team has, the higher their situational awareness and the faster their "learn-rate". In addition they can typically perform tasks faster because of their prior learning. These capabilities allow teams of experts to achieve more with less.
This ability expands what can be achieved and hence affects the relationship between work and consequent cost and schedule. This point is often lost on managers who see human resources as little more than being fully interchangeable and homogeneous. It seems difficult to get across the idea that, when appropriate, the adoption of more experienced, and consequently more expensive, staff can produce better results faster, and at lower overall cost.
11. Scotto, Marie, Project Resource Planning, in Project Management Handbook, Jossey-Bass, 1998, Chapter 13.
12. Contributed by Gerald Neal by Email dated 9/23/99.
13. Note here, the distinction from the old and tired view of "Triple Constraint" (time, cost and performance only.)
14. That is, quality as specified in the project's original requirements.
|
Proposed Core Concepts of Project Management - Part 2
