Online Sample Chapter
eXtreme Project Management Concepts
Table of Contents
Preface.
PART I.
1. The New Project Environment. Forces Driving Change. Driving Force 1: A Power Shift. Driving Force 2: The Free Agent Army. Driving Force 3: The Global E-Economy.
2. Project Management Evolution. The Four Waves of Project Management.
3. eXtreme Concepts. Project Management Versus Technical Management. Context and Content. Whole-of-Life Project Management. Project Manager as Facilitator. Sponsors as Executive Project Managers. Scenario Planning. The L.A. Law Model. Rapid Planning. Virtual Teams. It's the Context, Stupid.
PART II.
4. eXtreme Project Management Context. Two Very Different Types of Work. Process Work. The Two Cultures in Conflict. The Categories of Project Work. Project Size.
5. The eXtreme Project Management Model. Project Management Processes. Project Justification, Approval, and Review. The Critical Information for Project Approval. Project Planning. Project Tracking. Project Reporting and Change Control. Postimplementation Reviews. A Note on the Project Initiation and Feasibility Study. The Project Charter or Business Case. The Only Stable Thing Is Change.
6. The RAP Process. Why Should We Run RAP Sessions? Different Stakeholders, Different Agendas. Great IdeaúBut I Don't Have a Team Yet. The RAP Structure. RAP Technology. How Long Should a RAP Take?
7. Analyze Project Success. What Are Expectations? The Seven Success Criteria. Degree or Level of Stakeholder Satisfaction. Meeting of Objectives and Requirements. Meeting Budget. Meeting Deadlines. Added-Value Requirements. Quality Requirements. Team Satisfaction. eXtreme Tool 1: Success Sliders. Don't Panic! It Is Meant to Be Subjective.
8. Define Scope, Objectives, and Stakeholders. What Is the Difference between Scope and Objectives? Conflict Is Inevitable. Levels of Objectives. Refining Your Objectives. Let's Not Get Physical. Don't Fence Me in. Stakeholders and Related Projects. What Is a Stakeholder? Related Projects: A Special Case of Stakeholder. Focus and Communicate. Formalizing Stakeholder Relationships. Sponsor Agreement: The Most Important of All. Who Is Your Team?
9. Analyze Added Value. The State of the Art. Problems with Traditional Cost/Benefit Approaches. The Ultimate Fiddle. Added-Value Analysis. The Added-Value Chain. The IRACIS Model. Actual Versus Notional Costs. Shadow Pricing: Hedonic Costing and Contingent Valuation. Benefits Realization. Cost-Effectiveness Model. Another Form of Double-Counted Benefits. Additional Added-Value Drivers. A Final Note on Added-Value Analysis.
10. Define Quality. Project Quality Deployment. Linking Product and Process Quality: QFD. What Is a Quality? Toward an Effective Quality Plan: PQD in Action. Step 1: Define the Product Requirements. Step 2: Negotiate Product Quality Attributes. Step 3: Review Quality Attributes with Your Sponsor. Repeat Until. Quality Index. Quality in Action. Quality Assurance Drivers. Quality Assurance Principles. Quality, Estimates, Costs, and Risks. The Impact of Quality. The Hot Buttons. A Final Note on Quality for Now.
11. Select a Development Strategy. Strategy Ain't Methodology. The Four Development Strategies. Monolithic or Waterfall. Release, Version, or Incremental. Fast Track, Evolutionary, or Production Prototyping. Hybrid. Rapid Application Development (RAD), Agile, and Other Variations. RAD or Time-Boxing. Radical Fast Track. Microsoft's Daily Build. Agile, Lite, or Extreme Methods. Mixing and Matching. Partitioning Guidelines. By Function or Data. By Stakeholder. By Benefits. Strategy Selection. Strategy as a Change Control. Strategy and Risk Assessment.
12. Analyze Risk. Project Risk Assessment Overview. Many Classes of Risk. Project Risk Management. Project Risk Assessment. Subjective Versus Objective Risk Assessment. The Risk Assessment Process. Overall Project Risk Assessment. Risk Containment or Reduction. Risk Management Plans. Risk Tracking and Reporting. Shooting the Messenger.
13. Develop Task Lists. Develop Project Task Lists. Methodologies: A Brief Introduction. 1. Tailor Methodology. 2. Brainstorm Project Tasks. 3. Fine-Tune Your Methodology. 4. Review with Other Experts. 5. Repeat the Process. The Amazing 5/10 Day Rule. The Risk of the Project or Task. The Nature of the Task. The Experience of the Team Members. The Degree of Trust. A Moral Dilemma. Where Is the Moral Dilemma? Scenario and Real-Time Planning.
14. Estimate Tasks. Causes of Estimation Error. Misestimating the Scope. Misestimating the Stakeholders' Effort. Misunderstanding the Quality. Miscalculating the Project Risk. Forgetting Tasks. Misunderstanding Your People. Estimation Overview and Principles. Getting Our Language Right. Project Estimation Points. Estimation Principles. Avoid Single-Person Estimation. Always Complete a Risk Assessment Prior to Estimation. Where Possible, Use Relevant Experts. Always Carefully Document Estimating Assumptions. Review the Work Breakdown Structures. Always Undertake Sensitivity Analysis. The Detailed Estimation Process. Saying No Revisited. A Review of Risk Assessment. Develop a Work Breakdown Structure. Complete a Function Point Estimate. Complete Team-Based Estimates. Not Another Note on Sensitivity Analysis! Adjust for Quality Agreement.
15. Develop Schedule. Develop Project Execution Plan. Step 1: Develop a First-Cut Network. Step 2: Adjust Estimates to Elapsed Days. Step 3: Develop First-Cut Schedule. Step 4: Schedule Actual Resources. Step 5: Adjust the Schedule as Required. Scenario Planning Revisited. Develop Project Staffing Agreements. Oops! Wrong Planet, Wrong Person. A Typical Skill Model. Virtual Team Twist.
16. Develop Return on Investment. Develop Cost and ROI Scenarios. ROI Fundamentals. Analyzing Project Costs. Future and Present Values. Developing Your ROI. Cost-Effectiveness.
17. Project Tracking and Reporting. Project Tracking. The Tracking Mechanism. The Use of Automated Project Management Tools. Various Tracking Concepts. We Aren't Painting Walls: We Are Building Dreams. Tracking Mechanism. Tracking Summaries. Building a Project Metric Database. Project Reporting. Project Management and Technical Deliverable Reviews. The Project Reporting and Review Process. Really Radical Reports. Assistance to Projects. Reporting to Stakeholders. The Project Change Control Process. Maintaining the Project Management File. The Business Case Is the Focus of Everything.
18. Postimplementation Reviews. The Postimplementation Review. The Postimplementation Review Focus. Don't Forget Your Sliders. The Timing of Postimplementation Reviews. The Learning Loop Concept. Client Satisfaction Surveys. The Postimplementation Review Team. The System Support Review. Benefits Realization Planning. The Benefits Realization Plan. The Project Sponsor's Role. Benefits Reviews.
19. Support. The Support Problem. The Production Portfolio Concept. Portfolio Investment Effort. The Production Support Portfolio. The System Efficiency Review. Production System Activities and Support Costs. Passages: The Life Cycle of Production Systems. 1. New Product or System: Childhood. 2. Mature Product or System: Adulthood. 3. Old Product or System: Geriatric. Conclusion.
PART III.
20. Getting the Sponsor You Deserve. Rule 1: The Bag of Money and the Baseball Bat. Rule 2: The Passive Conduit. Rule 3: You Generally Get the Sponsor You Deserve. Rule 4: In the Absence of Information, Executives Still Make Decisions. Rule 5: Educate as Well as Inform. Rule 6: The Level of Help You Get Is Inversely Proportional to Your Delay in Asking. Rule 7: Show Them the Money. Rule 8: Beam Us Up, Scotty. Rule 9: No Sponsor, No Start.
21. Getting the Stakeholders You Deserve. Rob's Corporate Mathematics. Why You Need Your Stakeholders. How to Win Stakeholders Over. Remember They Have Other Jobs as Well. How to Get the Project You All Want.
22. A Question of Ethics. Situation 1. Situation 2. Situation 3. Situation 4. Situation 5. Best Practice and Best Behavior. Organizational and Individual Impact. Drawing the Line - An Extreme Project Management Responsibility. A Draft Code of Ethical Behavior for eXtreme Project People.
23. The Success Sliders Redux. Requirements Are Not the Same as Expectations. So, What Are Expectations? The Swiss Army Knife. Other Tips for Understanding Expectations. Become a Culture Vulture. Check out the Scenery. Learn Their Language. Say It Once, Hear It Many Times.
24. In Case of Emergencies. The Dark Side. Dark Side 1: Don't Tell Anyone. Dark Side 2: Hope It Will Get Better. Dark Side 3: Covertly Degrade Quality. Dark Side 4: Covertly Degrade Functionality. Dark Side 5: Work Harder - Long-Term. Dark Side 6: Hire Consultants or Contractors and Blame Them. Dark Side 7: Blame Your “Users”. Dark Side 8: Blame Everyone - A Witch Hunt. Dark Side 9: Leave the Project. Dark Side 10: Add Lots of People - The Horde Model. Dark Side 11: Stop the Project. The Good Side. Good Side 1: Shift the Deadline. Good Side 2: Shift the Requirement. Good Side 3: Partition and Add People. Good Side 4: Overtly Degrade Quality. Good Side 5: Change the Technology. Good Side 6: Change the People. Good Side 7: Work Harder - Short-Term. Good Side 8: Leave the Project. Good Side 9: Mix and Match. Good Side 10: Stop the Project. Come to the Dark Side, Luke.
25. The Secret of Great Project Managers. References. Index.
Preface
Introduction
On a recent trip to London, I was amazed as my cabbie, Steve, nudged forward into the face of three lanes of oncoming traffic to cross a busy intersection that we had been waiting at for over five minutes. "Only a cabbie could pull that off," I commented, as we avoided potential accidents. Steve laughed and replied, "I have been driving cabs for 23 years. We cabbies have a term. We use the road. Other people drive but we use the road."
By bending rules, taking calculated risks, and using his experience of the many roads, lanes, and alleys of London, Steve made the journey faster, more efficiently, and safer by using rather than driving on the road.
Later I thought about the difference between "using the road" and "driving on the road" and the difference between eXtreme project management and traditional project management.
For people faced with too many projects, projects that seem to change every day, not enough good people, and not enough time and money, eXtreme project management is about using the road.
Why Should You Read This Book?
The simple answer to this question is for you to answer a couple of other questions:
- I have a completely stable and realistic project plan.
- My organization has a stable strategic plan.
- My stakeholders are fully committed to my project.
- My sponsor is fully effective and available to me quickly.
- I have a completely clear statement of scope and objectives.
- My team is loyal and devoted to the project.
- We have effective risk and quality management plans.
- My organization understands project management.
- I have access to a group of expert project managers.
- I have all the tools, technology, and techniques I need.
- My project and organization are not changing rapidly.
If you answered "Yes" to all these questions, this book should be used to raise your Project Manager of the Century award higher for all to see and envy. If you answered "No" to any of these questions, this book will help you get a perfect score.
This book is about a new and radical approach to managing projects and teams--project management (XPM). It represents a quantum leap in project management.
Our group has been developing, implementing, and refining this approach over the past 25 years. This new project management approach is not based on academic theories or esoteric models. Rather, it has been forged through the experience of thousands of hours of practical experience in hundreds of real projects. The projects have been in virtually all sectors of business—most government areas, insurance, banking, health, computing software, information technology (IT) hardware and IT services, research and development, retail services, policy development, and manufacturing.
What Makes This Book Different?
eXtreme project management is fundamentally different from mainstream and traditional project management approaches.
eXtreme Project Management Test
To show the radical difference between eXtreme project management and traditional project management, let's explore the answers to this question: How do you determine the progress of a project?
The traditional project management answers to this question include:
- Is the project meeting agreed deadlines?
- Is the project in budget?
- Have there been changes to the scope and objectives?
Indeed, most project management systems are based on reports only on budget and deadline compliance.
eXtreme project management adopts a completely different approach to measuring project success and progress:
- Are stakeholders being informed and consulted about project status?
- Have there been unapproved changes to scope and objectives?
- Are the cost and benefits assumptions still valid?
- Has the agreed product quality been compromised?
- Are project risks unchanged?
- Is the sponsor completely aware of the project status?
- Are the team members satisfied with the project?
In effect, traditional project management looks inward and downward whereas, eXtreme project management looks outward and upward.
Over the past 25 years, we have studied and researched project management and related topics from as many perspectives as possible. We have read every book (currently more than 100) and article (many hundreds) on project management we can find. We have searched the Internet and have attended meetings of professional project management groups such as the Project Management Institute and the Australian Institute of Project Management. In addition, we have discussed our views and models with more than 20,000 project managers in our workshop series.
The longer we look, the more we are convinced that most published project management material has missed the mark. Either the models are too basic and simplistic or too theoretical and complex. In many cases, they are just unrealistic. For example, many project management texts suggest that you have to acquire and implement complex system or project development methodologies (at the cost of hundreds of thousands of dollars). Critical management issues such as quality, benefits realization, and risk were either completely ignored or plugged in as afterthoughts.
Sometimes we wonder whether the author or expert even lives on the same planet that we do! Their world seems so organized, so rational, so structured, and so devoid of the complex interpersonal politics we see every day in our clients that we wonder whether we have a distorted view of reality.
However, 20,000 people cannot be wrong. Our workshop participants do live on the same planet as we do and in the same world of complex organization dynamics.
Traditional project management approaches reflect the engineering and construction models of project management. They are based on a set of assumptions that are increasingly irrelevant in the chaotic and ambiguous world of organizations facing the new millennium. Concepts such as fixed requirements, long development time frames, stable teams and technology, and passive involvement of project stakeholders who trust their expert project managers have become historical myths.
Our new project management approach has been continuously refined and expanded to reflect the realities of the new business paradigm. It is based on a different set of assumptions that include dynamic requirements, compressed development schedules, virtual teams, unstable technology, and total involvement of project stakeholders. Our project management approach is totally focused on the analysis, measurement, and realization of financial benefits from the project, managing the total whole-of-life project cycle, complete integration of quality issues, and proactive project risk management.
We have evolved our project management approach to be as simple as it can be and as complex as it needs to be.
In his terrific book, Management of the Absurd, Richard Frason (1996) described how James Watt saw something that millions of other people had also seen but "not seen." It was Watt's observation of how steam coming from his tea kettle could be used to power steam engines that sparked the Industrial Revolution. Watt also saw the "invisible obvious" that so many others could not.
So much of this book is about the invisible obvious. Time and time again throughout this book, you'll find yourself saying "Of course! Why didn't I think of that? It's so obvious. It is so simple."
However, as Richard Riodan said when he was mayor of Los Angeles, "Simple and easy aren't the same words."
Most important, as we first stated in 1981 in People and Project Management (1981) and in Third Wave Project Management (Thomsett, 1992), our project management approach is totally focused on people and the relationships among the many people involved in projects.
What This Book Is Not About
This book is not about how to develop work breakdown structures and project schedules. It is not about developing simplistic and mechanical models such as project plans (which are never followed anyway). Most important, it is not boring. Many of the project management books that we have read present project management as some dry, cold, and quasi-scientific "pursuit."
We totally reject this view of project management. Our experience is that project management is one of the most challenging, creative, and exciting activities you can undertake. We hope that this is reflected in this book.
The Structure of the Book
To assist our readers who are under eXtreme project deadlines and working conditions, we have structured the book into three parts for quick access.
Part 1—eXtreme Concepts
This covers the background to XPM. We look at the evolution of project management, the emerging project environment, and the forces driving the need for XPM.
Part 2—eXtreme Tools
This introduces the XPM tools such as RAP sessions, learning loops, success sliders, and the detailed techniques used in XPM planning and tracking.
Part 3—Additional Resources
This includes readings that provide further tips; advanced tools; and related issues such as project sponsorship, negotiation, communication, ethics, and other critical project management concerns. There are additional readings available on our Web site www.thomsett.com.au
Each part is related but they can be read independently if you are in a hurry; though we hope you get to read the entire book eventually. Great project managers will read all of this book.
During our journey as consultants to major organizations, we have seen many strange and wonderful things. In many cases, what we observed put the bizarre events in the series The X Files to shame. At the end of the chapters in Part 2, we have included a section called The P Files (where P represents people or politics). The P Files entries support the points raised in the associated chapter.
A Note on Terminology
Throughout this book we refer to business projects. This term includes all the typical elements of business process redesign and development, new policy development, IT development, and change management. Readers who have either a business or IT background will find the concepts and techniques relevant. After all, there is no such thing as an IT project. eXtreme projects embrace and include all aspects of business, IT, policy, administration, human resources, change, and research effort that all projects should include. We also do not use the term user, which we dislike intensely, to refer to non-technical people. As we explain in the next chapter, this term has been used to marginalize and diminish the critical role that business experts and clients play in contemporary projects.