TPM is firmly rooted in the 1950s and has been around longer than any other approach to project management. In fact, I don't recall it even being called project management in those early days. Process Control System (PCS) was the label I recall. I think the name came from an old IBM program by the same name. In its most elementary form, PCS was nothing other than a sequence of phases such as define, plan, execute, and close with tasks identified within each phase. PCS depended heavily on crude programs that generated Gantt charts based on dependency relationships among tasks that the project manager defines from a functional specification, an earlier form of what we now call a requirements document. Estimates of duration allowed a schedule to be calculated and the critical path identified. These Linear approaches date back to the decades of the 1950s and 1960s. Until the early 1980s, this was the overwhelming choice of software developers. There were few alternatives at that time. Because of its longevity, it has become habit with many developers. Even though there are a number of alternatives today, developers don't give second thoughts to changing. They would rather force-fit the old when the new would be the better choice. Old habits die hard! That is unfortunate, because all of the developer's attempts to modify the Linear approach to accommodate software development projects that don't fit the conditions ultimately lead to failure or sadly disappointed clients.
Since the 1980s, the project management landscape has been radically changing. The introduction of the PC in 1981 ushered in the start of a wave of software applications to support the project manager. By the year 2000, there were more than 125 PC project management software applications on the commercial market and at least 25 mainframe packages. There is now a long list of Agile Project Management (APM) approaches and the software, documentation, and training to support them.
For the purposes of this book, I have classified the project management approaches into Traditional, Agile, and Extreme. In this chapter, I present my ideas on what constitutes TPM and how to adapt it for maximum benefit. In Chapters 11 and 12, I explore the same topics for APM and xPM.
3.137.223.255