Alıntılar

INTRODUCTION Project success is an elusive goal in every business or technical domain. Examples of project failure are easy to find. Examples of project success are not as well documented. We tend to focus on the failures rather than the successes. It is difficult to look for the root causes of project failure; instead, we tend to write about the magnitude of the failure and how things went wrong. Corrective actions are rarely discussed based on an assessment of the root causes, because the project participants have usually moved on. When we do look in greater detail, the literature shows the primary root causes of failure start with a failure to define what "done" looks like in any meaningful units of measure. Without a measurable assessment of progress toward "done," we cannot recognize "done" if or when we encounter it. In this book the word "done" has a special meaning. It means the customer is satisfied with the outcomes of the project. The customer must have specified these outcomes up front in the form of a set of capabilities the project will provide, with some unit of measure meaningful to the decision makers--the customer. This is a very specific definition and will be used throughout the book to mean "compliance with all the measures, technical and operational specifications, planned cost, and schedule." Most practices, concepts, and language of project management we see today have their origins largely in the United States aerospace agencies in the mid-1950s. They were developed primarily for use on programs such as Atlas, Polaris, Minuteman, and Apollo manned space flight vehicles as a highly urgent response to the need to develop new ballistic missile capability to counter perceived Soviet threats. After that era, these processes were expanded through the U.S. Department of Defense (DoD) initiatives that capitalized on these practices and processes through today's methods. Performance-Based Project Management [SM] is about successfully managing projects based on those early processes, but with the added concept of "capabilities," an idea derived from President John Kennedy's words of May 15, 1961: "To achieve the goal, before this decade is out, of landing a man on the moon and returning him safely to earth." This statement is the foundation of one of the Five Immutable Principles of project management: "Define what 'done' looks like in units of measure meaningful to the decision makers." Kennedy made this clear: fly to the moon, land, and return safely to earth. That statement defined success. That statement describes what "done" looks like. In the context of Kennedy's statement, a capability was the "ability" to fly to the moon, land, and return safely. For all projects, a set of "capability" statements is the starting point of describing "done." My motivation for writing this book began decades ago when I moved from a career as a software developer on radar, sonar, and embedded control systems to focus on commercial software products. Clear and concise statements of effectiveness and performance guide the development of software and hardware for things that fly, drive, or swim away, and the control systems that manage them. When I moved to the commercial domain, those types of processes were frequently missing--not because the processes were not in place, but mainly because those asking for the projects were not aware of the fundamental need for defining what "done" looks like before starting the project. There were many books, journal papers, and articles describing the technical activities performed during the execution of the project. Many describe how to define strategic initiatives, business mission statements, and measures of performance for the business. But rarely did I encounter a source of guidance that connected the dots between a business strategy based on projects and the management of those projects. In the end, what was missing was a detailed description of how to connect business or mission strategy with project execution using the contents of this book. Performance-Based Project Management is about the principles, practices, and processes of project management that make those connections. Before I begin showing you how to do this, I need to make a disclaimer. Although people execute these principles, practices, and processes, my focus in this book is not on people in a traditional manner. There are more than enough books about the "people" side of project management. People's processes change, and so does the underlying technology of managing a project. The team members, stakeholders, and the project managers looking after the project are probably not the same over the life of the project. People come and go. Technology comes and goes. What is "immutable" are the principles and the practices for how to successfully manage a project. The singular beneficial takeaway of this book is: - How to clearly define the purpose of the project; that is, how to have clarity of purpose, - How to construct the artifacts, or elements, that represent that clarity, and - How to measure the performance of the technical outcomes from the work on the project performed by the people. Excerpted from Performance-Based Project Management: Increasing the Probability of Project Success by Glen B. Alleman All rights reserved by the original copyright owners. Excerpts are provided for display purposes only and may not be reproduced, reprinted or distributed without the written permission of the publisher.