Preface

Sometimes, things just fall into place.

In project management, we see many practices that have been developed, each of which has specific strengths and weaknesses. For some of them, we do not even know who invented them and when, such as the bar chart or the Work Breakdown Structure (WBS). Others have been published with the names of their inventors, such as the Critical Path Method (CPM) or Scrum, and some of them even have some kind of copyright protection. Some practices have been developed as work-arounds to others, and a project manager in a later generation may no longer perceive them as makeshifts, but rather as the way things need to be done.

Some practices are just technical. Others are highly political. Discussions among promoters of these practices are often conducted with an incredible zeal to prove that their own method is the best, under all circumstances, thereby placing political positions over project management behaviors, methods, or tools. Project management practices are often linked with a person’s business. As an expert on method XYZ, one can make a living as a trainer, consultant, book author, or, of course, as a project manager. The fanaticism that these promoters of practices communicate may be a fire burning inside of them. Sometimes, it is an attempt to increase the business value of their own knowledge and skills that the customer or employer is prepared to pay for and to remain competitive against other experts with their distinct methods.

Project management practices are often inexpensive excuses:

• “No, we will not accept the change request. It may bring benefits, but it is not in the plan or the strategy.”

• “No, we do not have a plan and we will not waste time documenting the project. We are going Agile.”

Many practitioners in project management observe these discussions with irritation. Practices are often promoted in a way that taking sides with one of them requires the fundamental rejection of another one. Project managers are sometimes unsettled by this and wonder what they are going to lose with such a step. And they are right. The moment may come when this other behavior, method, or tool is more favorable in a specific project situation. It is helpful, therefore, to have a basic concept—what it is that makes a practice favorable or detrimental to a given situation and how this practice should be implemented. This is the concept that allows things to fall into place. This concept has a name: “Situational Project Management” or, in short, SitPM.

SitPM is not another practice for project management. It is rather an exploration into various project situations and practices. Each of the practices has been developed to respond to specific requirements and ignores others. Many were created while someone actually carried out a project; others were developed by experts with a certain type of project in mind. Most of these new practices are then promoted to be applicable to “all kinds of projects”, and no limitations of its applicability are communicated and discussed. While the requirements placed on the project manager and the team are frequently changing¸ so are the practices that match the situation. It is then advisable to know various practices and have a guideline available to use in a specific project or project situation.

Looking at the many methods, tools, and behaviors that we can apply, there are definitively more project management practices than what a single person can master. As a project manager, one must be selective in the practices that one learns and applies. Some practices are required in a given industry or organization more often than others. Over time, however, one can add more practices to his or her portfolio of skills and will then be able to respond to challenges in a more situational fashion. It will then be interesting to see things fall into place. One may also be able to build teams with colleagues and friends who have mastered practices other than his or her own, and the combination of such competences and strengths can be a powerful approach to project management.

In this book, I hope to provide project managers with as much guidance as possible to develop this adaptive approach to their projects. To make the best use of this book, I recommend doing some analyses from time to time on the project:

1. To what type does the project belong?

2. What degree of dependence and independence will the project manager have?

3. What is the planning horizon that project (a) requires and (b) allows for in the two dimensions of time and granularity?

4. To what leadership behaviors (“Achieving Styles”) will the project respond most positively?

5. How much direction does the team need and value? How much self-organization can it conduct and will it appreciate?

6. Based on which assumptions have project decisions been made so far, and what happens if they prove wrong?

7. How much nonproductive time is left for the project manager to do organizational tasks?

8. How will the project implement its change request management process not only to allow it to engineer benefits and add value but also to protect the project from catastrophe?

9. What software should the project manager use?

This book addresses these very basic questions and offers advice on adjustments to common situations. I recommend not considering this as a definitive description of Situational Project Management. It is rather the “Open Sesame!” from 1001 Arabian Nights, which will lead you into the cave of the thieves, where a treasure awaits the open-minded explorer, but also where new challenges and threats may occur.

Note: The author produced many pieces of art in this book using Corel Draw 6.0 and some of its clip-art components, with licenses to the author from Corel.