The book The Project Success Method tackles the subject of project management.

The following contains a transcript of a two-part  interview with Clint Padgett, author of The Project Success Method.

Q: Your book, The Project Success Method provides a framework for organizations to follow to make sure projects are well-managed. Why do you organizations need this method?

A: All organizations perform highly strategic projects to build and maintain competitive advantage in their industry. They develop and introduce new products and services. They develop and/or implement new processes, technologies, and systems. They build, maintain, renovate, and relocate facilities. They design and launch new marketing initiatives. They conduct special events. They acquire and merge with other organizations. The list of strategic projects goes on and on.

Unfortunately, a very large percentage of strategic projects fail. That is, they do not achieve their business objectives, they are finished late, and/or they significantly overrun their budgets. The penalty for a single failed strategic project can be huge in terms of lost competitive advantage, lost sales and customers, and excess costs. The problem is that most organizations fail to recognize the special challenges of managing strategic projects, so they do not implement and consistently apply a proven methodology for managing projects successfully. They simply “muddle through.”

The Project Success Method is a set of highly structured and integrated management processes that has proven effective and efficient on all the types of strategic projects mentioned above as well as others. Simply put, organizations cannot afford to fail on their strategic projects. Many of my clients think of The Project Success Method as an insurance policy that protects them from the disaster of project failure.


Q: What is the most common project management problem faced by organizations today?

A: The list of common problems is very long, but in my opinion, the most common (and perhaps the most deadly) problem is the tendency of organizations to start projects without a clear and concise statement of project requirements. They wade into projects believing that members of the project team and other project stakeholders understand and agree on the scope, objectives, constraints, risks, and other key attributes of the project definition. They get well into the project - having expended lots of time, effort, money, and other resources – only to discover that there is no common understanding and agreement among the stakeholders as to the project requirements. This situation typically leads to delays, rework, excess costs, quality issues, loss of morale/commitment, potential conflict among the stakeholders, and ultimately project failure.

To prevent this common and often devastating problem, one of the first steps in The Project Success Method is for the project team members and other stakeholders to develop a project charter to define the project requirements. This clear and concise document, which is formally approved (signed) by the project stakeholders, becomes the basis for planning the project. In my book, I explain and illustrate the contents of a project charter and describe the process for developing the charter. If changes to the project requirements occur later, the charter is formally revised and re-approved, and this process re-opens negotiations regarding the project deadline, resource allocations, etc.

I have found two other advantages to developing project charters. First, the charter development process forces the project stakeholders to define the project requirements earlier than they otherwise might. As a result, the project can be launched earlier and the team will have as much time as possible to complete the project. Second, the charter is the best protection that the team can have against uncontrolled changes to project scope, also known as scope creep.


Q: You encourage organizations to “remember that projects are inherently cross-functional, so breaking the project down into one of the two dimensions of scope maintains a cross-functional perspective.” How do you recommend organizations achieve this perspective in practice?

A: First, it is essential that the project team include at least one representative from every functional area involved in the project. Of course, this approach results in a very diverse team. Imagine a team with representatives from product engineering, process engineering, production operations, marketing, information technology, procurement, human resources, and legal counsel. These individuals have different educational and experiential backgrounds. They possess very different professional knowledge and skills. They use different jargon, and they have vastly different perspectives on the project. Ultimately, they may use different approaches to problem-solving and decision-making.

Many people find that working in a cross-functional, highly diverse team is uncomfortable. They would prefer to retreat to their functional “silos” and work only with people who are very much like themselves. Consequently, there is a natural tendency for the team to break the project down into functional areas for planning purposes, which significantly reduces the cross-functional perspective on the project. For example, imagine that the information technology representatives on the project team say something like, “We will take care of the IT requirements of this project.” Then they extract themselves from the team to work independently in the IT functional silo and avoid interacting with people from the other functional areas involved in the project (who, by the way, have happily retreated into their respective functional silos as well).

I have learned the hard way that a functional approach to cross-functional projects virtually always leads to big problems. In addition to forming a cross-functional team, I insist that the team actually work in a cross-functional manner.

We break the project down for planning purposes along one of the two dimensions of scope, rather than breaking it down into functional areas. As explained in my book, one dimension of scope is the major deliverables/components (such as the building, equipment, personnel, and materials required to open a new production facility). The other dimension of scope is the major phases (such as system design, code development, testing/debugging, and user training to develop and implement a new IT application). The planning and execution of the tasks associated with each major deliverable/component or each major phase typically involves team members from several of the functional areas represented on the team ensuring the cross-functional approach to the project is maintained.


Q: What do you mean when you talk about special case activities that can fall through the cracks during the planning process?

A: I am referring to activities that have either or both of the following characteristics:

•       From the perspective of project team members, the activity involves waiting for something rather than doing anything. Examples include (a) waiting for the delivery of materials that have been ordered from an outside source or (b) waiting for a natural process, such as concrete curing, to occur.

•       The activity has no obvious completion point. Examples include (a) developing the theme for a new advertising campaign or (b) debugging complex new computer code. It is never obvious when such activities are finished.

Activities with either or both of the above characteristics may not be recognized as activities, so they are left out of the project plan. No member of the project team is assigned to manage them; no resources are allocated to them; most importantly, they do not show up in the project schedule. Obviously, such oversights lead to incomplete and unworkable project plans.


Q: You also mention that organizations can include too little or too much detail when planning. How do you suggest organizations find the ideal level of detail?

A: I wish there were a simple answer to this question. I am not even sure there is an “ideal level of detail” for a given project. The best I can do is to provide some guidelines that should lead to a reasonable level of detail:

•       Resist the temptation to micro-manage the work. Every activity in the project plan should create a significant deliverable or result (such as obtaining an approval). In general, it is not necessary to identify all the procedural steps necessary to create the deliverable or to obtain the desired result. Trust the responsible team member to know how to perform the activity.

•       Every activity should be managed by one member of the project team and in general should require one set of resources from beginning to end. For example, if the beginning portion of a given work package should be managed by one team member, and the remainder should be managed by another team member, then that work package should be divided into two activities.

•       Remember that every activity will be tracked in the control process. The level of detail in planning should be consistent with the desired level of detail in tracking the project. Too much detail in planning the project can result in far too many activities to track in the control process.

•       Find ways to sub-divide activities whose scheduled durations would be longer than one month. (For short-duration projects, the maximum activity duration may be less than a month.) The problem with long-duration activities is that the activity may get too far behind schedule before it becomes obvious in the control process.

•       Include activities necessary to assure quality, such as activities to check quality (tests, approvals, etc.) and activities to fix quality problems (revise, debug, rework, etc.). You achieve quality results on projects by performing the activities necessary to ensure quality.

I should address one more complexity that occurs on long-duration projects. Imagine a project with a duration of two years. It may be possible to identify the activities at the appropriate level of detail for the first six months of the project, but beyond that point, the activities are not identifiable at the same level of detail. In fact, the more distant activities may depend on the outcome of the work over the first six months. In such cases, I suggest that the project team go ahead and indentify the near-term activities in detail and use higher level activities as place-holders for the more distant work. Then the team should break the project into more detailed activities as they progress through the project and the more distant work becomes clear and better defined. It’s the same way one drives a car. He or she can’t see all the way to the destination, but knows the general route they plan to follow, and at any given point, can see far enough ahead to keep moving forward.


Q: Identifying project managers and activity managers is a critical piece of the puzzle, what two common mistakes do you think occur during this selection process?

A: In selecting the project manager, I would say that the two most common mistakes are:

•       Selecting a project manager who will not be an actual member of the team – most typically, an individual who stands above the project team at a higher organizational level than the team members. In general, I want the project manager to be a peer of the other team members. I want the project manager to be prepared to devote considerable time and attention to the details of managing the project. In most cases, the project manager will be directly involved in managing and/or actually performing some of the activities in the project.

•       Selecting a project manager who may be an expert on the technical aspects of the project, but who lacks project management skills and personal leadership qualities.

In selecting project team members, I believe the two most common mistakes are:

•       Selecting team members who do not understand the structured processes being used to manage the project. I have found, for example, that when team members have not been trained in The Project Success Method, they tend to fight the process until they begin to understand how and why it works.

•       Selecting team members who resist making personal commitments and who avoid accountability. The Project Success Method is based on a culture in which the project team develops and commits to their plan for their project and then holds themselves accountable for executing the plan to achieve success.


Q: Many companies use project management software. Why do you recommend that companies do not use this type of software?

A: Please allow me to clarify this if I could. I actually do recommend that companies use project management software. In fact, any company that will use The Project Success Method will definitely need to use such software.

However, I offer several cautions regarding project management software:

•       Project management software is only a tool that is used to support the project planning and control processes. Giving a project management software tool to someone who has not been trained in those planning and control processes and expecting them to manage a project successfully is like giving someone a piano who has never been trained in music and expecting them to play a concerto.

•       Many of the most popular project management software tools do some things in ways that I would never recommend. For example, some tools require the user to use “percent complete” to measure the status of project activities. For reasons that I explain in my book, I believe that percent complete is one of the most dangerous and destructive concepts that has ever crept into the practice of project management, and I would never recommend using it. My firm has developed software utilities for some of the most popular project management software tools that integrate into those tools and cause them to work as I think they should.

•       People who have a general familiarity with a project management software tool tend to over-estimate their project management ability. Managing a project successfully requires far more knowledge and skill than just the ability to manipulate a software tool.

•       Some organizations get hung up in the process of selecting their project management software; it can become a highly politicized debate. What the organization should be focusing on is the development of their project planning and control processes. Then based on those processes and the characteristics of the projects being managed, the software tool can be selected.

About Clint Padgett
Clint Padgett is the President and CEO of PSI. Since joining the firm in 1994, he has provided consulting, training, and account management to clients in a wide range of industries, such as: manufacturing, food/beverage, electric utility, and technology. His project experience covers many traditional and special applications, including: product development, equipment installation/startup, facility construction/moves, marketing, software/hardware system implementation, and international sporting events. Immediately prior to joining PSI, Mr. Padgett was an engineer for a Fortune 100 company. In that capacity, he assisted in the development, field-testing, and rollout of new equipment, as well as managing and improving quality assurance for several of his company’s major suppliers. He is a graduate of The Georgia Institute of Technology with a Bachelor of Electrical Engineering. He also holds a masters degree in Business Administration from Duke University. His professional associations include the Project Management Institute, the Institute of Electrical and Electronic Engineers and the Product Development & Management Association, among others. Additionally, Clint is a published author and frequently speaks at conferences on the subject of project management.