Seven first principles of project management according to Max Wideman

In the literature on project management, there is a wealth of information describing projects in all areas of application: what was achieved, how it was achieved, and how successful the results were, whether good or bad. Similarly, there is a wealth of literature providing advice on how to do project management — and presumably, do it better. Based on this experiential material, various attempts have been made to assemble “bodies of knowledge” and thereby articulate the role and content of project management. Such documents have been used in several countries for the development of individual certification and competence testing, and/or by enterprises for establishing corporate standards of practice.

But what I am interested in here is a generally agreed and testable set of elemental principles of project management that provide a testable foundation for a universal reference for a set of generally acceptable practices. It is true that much management science theory is applicable, but there is little that focuses on the specific and unique environment of project management. Yes, I know that everyone thinks that his or her projects are different. Indeed, there are some significant challenges with software development that make it unique, such as complexity, behavior of the medium, and so on. But I suggest that any research and development projects face similar challenges so that software development is not altogether unique.

Because I wish to focus on the basic or founding principles of project management, I use the term first principles. You may ask, “Do we really need a set of first principles of project management?” After all, most people seem to have managed very well without them — that is, until the trouble starts. And the trouble can start early with software development projects. The problem is, software development projects typically take place in a corporate environment that espouses the classic approach to corporate management.

Marie Scotto explained the difference very succinctly: “The business community believes in understaffing, which it can prove is generally good business most of the time.” However, management’s approach to project management should be very different. Projects, especially in advanced technologies, require generous contingency allowances to accommodate the inevitable extra work arising through uncertainty and unknowns; i.e., the practice of starving resources is a recipe for project failure. I suspect that the enthusiasm for such approaches as Agile and eXtreme have arisen because of this very conflict.

But what first principles should we include? The key appears to be whether or not the principle is universally fundamental to project success. After all, project management is an overhead, and if it is not going to make the project more successful we shouldn’t be spending money on it. But now we have another problem — what do we mean by success? On time, under budget? Not necessarily. Customer satisfaction? Maybe.

I suggest that the most compelling instance of success is a product that brings far more benefit to the organization than the effort involved in creating it. And, generally, other people determine that long after the project manager has moved on to other things! So, for the benefit of project management, we have to be content with shorter-term goals.

Seven first principles of project management

Here’s my best selection of “first principles,” which build extensively on the work of John Bing. All the principles make certain assumptions about the cultural ambience of the project’s environment, one that encourages and sustains teamwork and honesty and demonstrates, as my colleague Gerard Neal succinctly describes it, that:

• Everyone is working towards the same or similar project goals, whatever those might be.
• Everyone is clear and agrees on who the customer is.
• Appropriate levels of skill or experience are available as needed.
• Everyone wants the project to succeed.

1. The success principle

The measures of project success, in terms of both process and product, must be defined at the beginning of the project as a basis for project management decision-making and post-project evaluation.

Project success is a multi-dimensional construct that inevitably means different things to different people. It is best expressed at the beginning of a project in terms of key and measurable criteria upon which the project’s relative success or failure may be judged. For example, those that:

• Meet key objectives of the project, such as the business objectives of the sponsoring organization, owner, or user
• Elicit satisfaction with the project management process — i.e., that the deliverable is complete, up to standard, is on time and within budget
• Reflect general acceptance and satisfaction with the project’s deliverable on the part of the project’s customer and the majority of the project’s community at some time in the near future

Project success is closely linked to opportunity and risk. Projects by their nature are risky undertakings and some project hazards cannot be entirely avoided or mitigated even when identified. Since project success may be impacted by risk events, it follows that both opportunity and risk should be shared among the stakeholders. You should also note that success criteria can change with time, and just because certain objectives were not achieved, this does not necessarily mean that the project was a failure.

However obvious and sensible the setting of project success criteria at the beginning of a project may seem, regretfully, it is not currently 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 project management post-project? For this reason, I suggest that many surveys of project successes are questionable. I 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 the right thing to do.

The reality of life on many projects is that everyone on or associated with it does not have the same aspirations and goals. As a result, “the project gets pulled in many different directions … 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.

2. The commitment principle

An equitable commitment between the resource provider and the project delivery team must exist before a viable project exists.

The provider of resources (money, and/or goods and services, and general direction) is typically called the project’s owner or sponsor. The project delivery team is responsible for developing appropriate strategies, plans, and controls for applying the necessary skills and work to convert those resources into the required deliverables or product. An equitable commitment means that both parties are sufficiently knowledgeable of the undertaking, the processes involved, and their associated risks, and both willingly undertake the challenge.

The owner of the project must understand that, even with appropriate management controls in place, the risks involved must be shared. The attributes of both parties should encompass relevant skills, including those of the technology involved, experience, dedication, commitment, tenacity, and authority to ensure the project’s success.

Of course, every project evolves through its life span, and the commitment and tradeoffs will similarly evolve. Also, the players on a project usually change as it moves through its life span, simply to meet the changing level of effort and 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.

3. The tetrad trade-off principle

The core variables of the project management process — namely, product scope, quality grade, time-to-produce, and 4 total cost-at-completion — must all be mutually compatible and definitely attainable.

This principle is an extension of both the commitment principle and the success principle. The core variables of product scope, quality grade, time-to-produce, and total cost-at-completion — often loosely referred to as scope, quality, time, and cost, respectively — are measures of internal project management efficiency. If these variables prove not to be mutually compatible and definitely not attainable, the commitment is neither equitable nor are key success criteria likely to be met. The interrelationships of these four separate variables are somewhat similar to a four-sided frame with flexible joints. One side can be secured and another moved, but only by affecting the remaining two.

The merit of viewing the four as a tetrad rather than selecting only three to form a triangle is that it gives greater prominence to quality. Of the four, the quality of the product is obviously, and in fact, the most enduring.

4. The strategy principle

A strategy encompassing first planning then doing, in a focused set of sequential and progressive strategic phases, must be in place.

The genesis of the project life span process, in its most basic form, is to be found in the very term “project management” itself. A project has, by definition, a start and a finish. The essence of management is to “plan” before “doing.” Hence the most fundamental project life span process consists of four sequential periods of “start,” “plan,” “do,” and “finish.” Of course these four periods can be expanded into separate phases — each with their own interim deliverables and “executive control points” (or “gates” or “emergency exit ramps.”) These can be designed to suit the control requirements of every type of project in every area of project management application. Indeed, this sequence is, in effect, generally applicable at every level and branch of the project management structure. It is also just as relevant whether a “fast-track” strategy is adopted, or an iterative approach is necessary, such as in software development.

The importance of this life span process and its influence on the management of the project cannot be overemphasized. This relatively short-term life-to-death environment, and the consequences that flow, is probably the only thing that uniquely distinguishes projects from non-projects.

5. The management principle

Policies and procedures that are effective and efficient must be in place for the proper conduct and control of the project commitment.

This principle is an extension of the “Strategy Principle.” The Strategy Principle determines what will be done and when. The Management Principle establishes how it will be done and who will do it. The attributes of this management control encompass the project’s assumptions, its justification, and a reference baseline in each of the core variables as a basis for progress measurement, comparison, and course adjustment. The attributes of good policies and procedures encompass clear roles and responsibilities, delegation of authority, and processes for maintaining quality, time, and cost, etc., as well as managing changes in the product scope and/or scope of work.

6. The single-point responsibility principle

A single channel of communication must exist between the project sponsor and the project team leader for all decisions affecting the product scope.

This principle is an extension of the management principle and is necessary for effective and efficient administration of the project commitment. For example, the owner of the eventual product, if represented by more than one person, must nevertheless speak with one voice through a primary representative with access to the sponsor’s resources. Similarly, the project’s delivery team must always have a primary representative. However, this only applies to the decisions affecting the product scope and hence the project’s overall cost and schedule. In all other respects, free and transparent communication is indispensable for the coordination of a complex set of project activities. Therefore, this principle must not in any way inhibit the proper exchange of information through the network of project communication channels that is required to integrate all aspects of a complex project.

7. The cultural environment principle

Management must provide an informed and supportive cultural environment to ensure that the project delivery team can work to the limits of their capacity.

The ability of a project delivery team to produce results both effectively and efficiently is highly dependent upon the cultural environment. This cultural environment encompasses both internal and external project relations and values. Internally, the management style of the team leader must be suited to the type of project and its phase in the project life span. Externally, the management of the organization in which the project takes place must be supportive and the environment must be free of obstacles. Unfortunately, the reality in many organizations is that many managements do place obstacles in the way of project progress, perhaps unwittingly because of management’s functional heritage.

Conclusion

The final point above further emphasizes the need to establish a solid set of generally applicable project management first principles, such as those described in this article. I believe these will serve as a theoretical underpinning for generally accepted project management practice.

About the author

Max Wideman is a retired professional civil engineer and project manager with experience in systems, social, and environmental projects, as well as design and construction of major civil works. He is a past president and chairman and Fellow of the Project Management Institute, for whom he developed the 1987 version of the Project Management Body of Knowledge. He is also a Fellow of the Institution of Civil Engineers (UK), the Engineering Institute of Canada, and the Canadian Society of Civil Engineering. You can find comprehensive coverage of project management on his web site at www.maxwideman.com

Source: www.ibm.com/developerworks