The Project Management Institute (PMI) formally defines project management as follows: “The application of knowledge, skills, tools, and techniques to project activities to meet the project requirements.”1
Even though that definition is open to broad interpretation I have no problem with it because I prefer to keep things simple and intuitive and that is what PMI has done. For our purposes here I'm going to add a little more content than the PMI definition offers. The definition that I offer shortly in this chapter is designed to be a working definition.
Project management is a set of tools, templates, and processes designed to answer the following six questions:
Let's quickly look at the answers to these questions.
The business situation is either a problem that needs a solution or an untapped opportunity. If it is a problem, the solution may be clearly defined and the delivery of that solution will be rather straightforward. If the solution is not completely known, then the project-management approach must iteratively embrace the learning and discovery of that solution. Obviously, these will be higher-risk projects simply because the deliverables are not clearly defined and may not be discovered despite the best efforts of the client and the project team.
Keep in mind that your project is usually competing for resources with other projects that are addressing the same business situation but from a completely different perspective. For example, your project may be attacking one part of the problem while another project is considering a different part of the problem. It would be good if you knew this, because integrating the two projects into a single program may be cost beneficial and more likely to come to a successful conclusion. At least you would have more points of view to consider. The importance to senior managers of finding that solution or taking advantage of that untapped opportunity will also compete with the importance of other project proposals.
The obvious answer is to solve the problem or take advantage of the untapped opportunity. That's all well and good; but given the business circumstances under which the project will be undertaken, it may not be possible. Even in those rare cases where the solution is clearly known, you might not have the skilled resources to do the project; and if you do have them, they may not be available when you need them. When the solution is not known or only partially known, you might not be successful in finding that heretofore-unknown solution. In any case, you need to document what needs to be done. If the solution is known, that document will be easy to develop. If that solution is unknown or only partially known what you need to do will emerge over time rather than being developed at the outset.
The answer to this question will be framed in your project goal and objectives statements. Maybe you and others will propose partial solutions to the problem or ways to take advantage of the untapped opportunity. In any case, your goal and objective statements given as part of a Project Overview Statement (POS) will clearly state your intentions.
This answer will document your approach to the project and your detailed plan for meeting the goal and objective statements discussed in the POS. That approach might be fully documented at the outset or only developed iteratively but it will be developed.
Your solution to the problem or approach to the untapped opportunity will deliver some business value to the organization. That is your success criteria. It will have been used as the basis for approving your doing the project in the first place. That success criterion may be expressed in the form of Increased Revenue or Avoided Costs or Improved Services. IRACIS is the acronym that represents these three areas of business value. Whatever form that success criteria takes, it must be expressed in quantitative terms so that there is no argument as to whether or not you achieved the expected business results. As part of the post-implementation audit, you will compare the actual business value realized to the estimated business value stated in the project plan that justified doing the project in the first place.
The answer to this question can be determined by the answers to the following four questions:
How well did your deliverables meet the stated success criteria? The project was sold to management based on the incremental business value that would be returned to the organization if the project were successful. Did the project deliver those results and to what extent?
How well did the project team perform? The project team was following some project management life cycle (PMLC) model. There should be some assessment of how well they followed that model.
How well did the project-management approach work for this project? In addition to doing things right the team needed to do the right thing. Given that several approaches could have been used, the team should have used the best fit model.
What lessons were learned that can be applied to future projects? This question is answered through the post-implementation audit.
The answers to these six questions discussed in the preceding sections reduce project management to nothing more than organized common sense. In my world to be “organized” means that the process(es) used are continuously adapted to the meet the changing needs of the project. To be “common sense” means the management process did not require that non-value added work be done. If it weren't organized common sense, you need to question why you are doing it at all. So a good test of whether or not your project-management approach makes sense lies in how you answered the preceding six questions. With all of that as background our working definition of project management can be succinctly stated as follows:
Project management is an organized common-sense approach that utilizes the appropriate client involvement in order to deliver client requirements that meet expected incremental business value.
This definition is a marked change from any you may have seen before. First, it is the only definition that I know of that explicitly refers to business value. Business value is the responsibility of the client through their requirements statements. The project manager is responsible for meeting those requirements. Meeting requirements is the cause and incremental business value is the effect. What this boils down to is the meaningful involvement of the client in the project. In effect the client plays the role of another team member. Oftentimes their role will be as co-project manager. I'll have more to say on that throughout the book.
Second, and equally important in the definition through the common-sense term is that effective project management is not a “one size fits all” approach. Because it is a “common sense approach” it must adapt to the changing project conditions. What I will develop in this book are the rules of the engagement for effectively managing projects. The definition of the PMLC models given in the section “Introducing Project Management Life Cycles” is the beginning of your journey to become a complex project manager. You will learn in this book that the effective complex project manager is a leader who at the same time is creative, adaptive, and courageous. In effect I will define the contents of the pantry from which you will build the recipes you will need for managing your projects. It will be up to you to be the chef.
Third, you need to clearly understand requirements. Requirements and their documentation will establish the project characteristics and be your guide to choosing and adapting the project management approach you will use. I am going to take a rather unconventional approach based on my own definition of requirements.
13.59.114.228