27,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Fachliteratur
- Serie: Wiley CIO
- Sprache: Englisch
Your answer to the software project management gap The Complete Software Project Manager: From Planning to Launch and Beyond addresses an interesting problem experienced by today's project managers: they are often leading software projects, but have no background in technology. To close this gap in experience and help you improve your software project management skills, this essential text covers key topics, including: how to understand software development and why it is so difficult, how to plan a project, choose technology platforms, and develop project specifications, how to staff a project, how to develop a budget, test software development progress, and troubleshoot problems, and what to do when it all goes wrong. Real-life examples, hints, and management tools help you apply these new ideas, and lists of red flags, danger signals, and things to avoid at all costs assist in keeping your project on track. Companies have, due to the nature of the competitive environment, been somewhat forced to adopt new technologies. Oftentimes, the professionals leading the development of these technologies do not have any experience in the tech field--and this can cause problems. To improve efficiency and effectiveness, this groundbreaking book offers guidance to professionals who need a crash course in software project management. * Review the basics of software project management, and dig into the more complicated topics that guide you in developing an effective management approach * Avoid common pitfalls by perusing red flags, danger signals, and things to avoid at all costs * Leverage practical roadmaps, charts, and step-by-step processes * Explore real-world examples to see effective software project management in action The Complete Software Project Manager: From Planning to Launch and Beyond is a fundamental resource for professionals who are leading software projects but do not have a background in technology.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 389
Veröffentlichungsjahr: 2016
Ähnliche
Table of Contents
Cover
Title Page
Copyright
Dedication
Foreword
Acknowledgments
About the Author
Introduction
Software Project Management
A Holistic Approach
For Medium-to-Large Projects
Agile vs. Waterfall
Why Listen to Me?
Who Is This Book For?
Chapter 1: Software Development Explained: Creativity Meets Complexity
A Definition of Software Development
Why Is Software Development So Difficult? Hint: It's
Not
Like Building a House
The Simple, the Complicated, and the Complex
Metaphor #1: Piles of Snow
Metaphor #2: The Ikea Desk
Metaphor #3: Heart Surgery
Using the Three Metaphors in Project Management
Chapter 2: Agile, Waterfall, and the Key to Modern Project Management
Agile and Waterfall
Waterfall
Waterfall's Problems
The Requirements Requirement
Inflexibility
Loss of Opportunity and Time to Market
Customer Dissatisfaction
Agile
Lack of Up-Front Planning
Lack of Up-Front Costs
Stakeholder Involvement
Extensive Training
Where Agile Works Best
The Need for Up-Front Requirements in Many Projects
The Real World
Agile Enough
The Software Development Life Cycle
Chapter 3: Project Approaches; Off-the-Shelf and Custom Development; One Comprehensive Tool and Specialized Tools; Phased Launches and Pilots
The Custom vs. Off-the-Shelf Approach
History
The Benefit of Off-the-Shelf
Off-the-Shelf Examples
Thinking You're Editing When You're Actually Creating
Common Challenges with Off-the-Shelf Software
Business Compromise
Discovering You Made the Wrong Choice with Packaged Software
Breaking the Upgrade Path
Locked into a Partnership and the Product Roadmap
Expense of Off-the-Shelf
Where Packaged Software Works Well
Frameworks and the Blurring Worlds of Custom and Packaged Software
Integrations vs. One Tool for the Job
To Phase or Not to Phase
Bigger Is Not Always Better
The Pilot Approach
Why Not Pilot?
Chapter 4: Teams and Team Roles and Responsibilities Defined
Teams and the Roles on Teams
Project Leadership
The Key Business Stakeholder
The Project Sponsor
The Program Manager
Project Manager
Multiple Project Managers
Confusion About the Project Manager Role; It's More Limited than You Think
Project Team
The Business Analyst
User Experience
Designer
The Programmers
Architect
Systems Administrator
Team Member Choice and Blending Roles
Getting All the Roles Covered
Real-World Examples for Role-Blending
Professionals and Personalities
Insource or Outsource: Whether to Staff Roles with Internal People or Get Outside Help
The Myth that Insourcing Programming Is Better
Inexperience with Projects
How Knowledge Goes Stale
Outsourced Teams
When to Use Internal or External Teams
Roles Easiest to Outsource
Roles “in the Middle”
Roles that Are Usually Internal
Vendors and Hiring External Resources
Some Tech-Types to Avoid: Dot Communists and Shamans
The Shamans
Boundaries, Responsibilities, and Driving in Your Lane
Techies Who Don't Drive in Their Lane
Business Stakeholders Who Shirk Responsibilities
Business Stakeholders, Step Up!
Have a Trusted Technology Partner
How Best (and Worst) to Work with Your Technology Partner
Too Many Cooks
Chapter 5: Project Research and Technology Choice; Conflicts at the Start of Projects; Four Additional Project Delays; Initial Pitfalls
Choice of Technology, a Definition
The Project's Research Phase
Current State
Integrations and Current State
Data and Current State
Business Needs
Possible Technology Solutions
Demos
Comparison Grids
Talk to Other People, a Journalistic Exercise
How Do You Know When Your Research Is Done?
Research Reality Check
You Can't Run the Control
Religious Wars
Passion over Reason
Business Stakeholders and Controlling Ego
How to Stop a Technology Religious War
Not So Easy
Preventing a Technology Religious War
Being Right
Stopping a War in Its Tracks
Détente and Finally Ending a Technology Religious War
Clarity
The Role of the CIO
Two Most Important Factors in Core Technology Decisions
Other Conflicts that Delay the Start of Projects
The Project Charter, a Key Document
Chapter 6: Final Discovery; Project Definition, Scope, and Documentation
Budgeting and Ongoing Discovery; Discovery Work Is Real Work
Budgeting Final Discovery
What Comes Out of Final Discovery: A Plan
Getting to a Plan
The Murk
Getting Out of the Murk
The Plan for the Plan—Company A
How Anyone Can Make a Plan for the Plan
Different Approaches to Elicit the Plan for the Plan
Exception to the Murk
Breakout Sessions
The Weeds Are Where the Flowers Grow
Not All Questions Will Be Answered
Agile, Waterfall, and Project Documentation
The Scope Document
Project Summary
Project Deliverables
Out of Scope
Constraints
Assumptions
Risks
Timeline
Budget, Scope, Timelining, and Horse-Trading
Metrics
What About “the List”?
Defining and Visualizing and Project Scope
Where Does Design Fit In?
Working with Marketing Stakeholders
How You Know You're On the Wrong Track
A Word About Ongoing Discovery
Chapter 7: Budgeting: The Budgeting Methods; Comparative, Bottom-Up, Top-Down, and Blends; Accurate Estimating
An Unpleasant Picture
What Goes on Behind the Scenes; a Scene
Budgeting Type 1: Comparative Budgeting
Gotchas with Comparative Budgeting
Budgeting Type 2: Bottom-Up Budgeting
The Rub in Bottom-Up Budgeting
Budgeting Type 3: Top-Down and Blends
Why RFPs Don't Work
Accurate Estimating and Comparison Budgeting
Effective Estimating in Top-Down and Bottom-Up Budgeting
Establish a Base Budget for Programming, Ongoing Discovery, Unit Testing, Debugging, and Project Management
Percentages of Each
Programming Hours—Raw and Final
The Math Part
Additional Items to Consider
Budgeting and Conflicts
Chapter 8: Project Risks: The Five Most Common Project Hazards and What to Do About Them; Budgeting and Risk
Five Always-Risky Activities
Want Versus Need
Optimism Is Not Your Friend in Software Development
Facing Risks
A Few Words About Fault
Identifying Risks Up Front
Talking to Your Boss
Hidden Infections
The Contingency Factor
The Cost of Consequences
In the Real World
The Good News
A Common Question
Long-Term Working Relationships and Contingency
Chapter 9: Communication; Project Communication Strategy; from Project Kickoff to Daily Meetings
Project Kickoff
Project Kickoff Cast
Project Leadership
Company Leadership
Who Gives the Kickoff?
Kickoff Presentation
High-Level Project Definition
Business Case and Metrics
Project Approach
Team Members and Roles
Project Scope
Out-of-Scope
Timeline
Budget
Risks, Cautions, and Disclaimers
Monthly Steering Committee
Monthly Steering Committee Attendees
Monthly Steering Committee Agenda
Weekly Project Management Meeting
Weekly Project Management Attendees
Weekly Project Management Agenda
Daily Standup Meeting
Well-Run Meetings
Insist on Attention
Timeliness
Getting “into the Weeds”
Needs to Be Kicked Upstairs
Poor Quality Sound—Speakerphones and Cell Phones
Too Much Talk
Agenda and Notes
Chapter 10: The Project Execution Phase: Diagnosing Project Health; Scope Compromises
What Should Be Going on Behind the Scenes
The Best Thing You Can Ever Hear: “Wait.
What
Was It Supposed to Do?”
Neutral Corners
What If Things Aren't Quiet?
Making Decisions
How to Listen to the Programmers
SneakerNet and the Fred Operating System
Demos and Iterative Deliverables
Why Iterative Deliverables Are Important
Why Iterative Deliverables Are Hard
What You Can Do to Achieve Iterative Deliverables Even if It's Hard
Demos
Scope Creep
Dealing with Scope Creep; Early Is Better
Scope Creep and Budgeting
Scope Creep and Governance
Types of Scope Creep
Scope Creep and the Team
Chapter 11: First Deliverables: Testing, QA, and Project Health Continued
The Project's First Third
The Second Third
A First Real Look at the Software
The Trough of FUD
Distinguishing a Good Mess from a Bad Mess
An Important Checkpoint
Getting to Stability
First Testing and the Happy Path
Quality Assurance
Bug Reporting
Regression Testing
Bugs: Too Many, Too Few
Testing: The Right Amount for the Job
Too Much Testing?
Bug Cleanup Period
Timeline So Far
Chapter 12: Problems: Identifying and Troubleshooting the Three Most Serious Project Problems; Criteria for Cancellation
A Rule About Problems
Additional Resources
Fault—A Review
Common Late-Stage Problems
Lurking Infections
Wrong Technology Choice
Lack of Leadership
Chapter 13: Launch and Post-Launch: UAT, Security Testing, Performance Testing, Go Live, Rollback Criteria, and Support Mode
User Acceptance Testing: What It Is and When It Happens
Controlling UAT and “We Talked About It in a Meeting Once,” Part Deux
Classifying UAT Feedback
Bugs
Not Working as Expected—The Trickiest Category
Request for Improvement
Feature Request
Conflict Resolution and Final Launch List
Load Testing
Performance Testing
Security Testing
Sign-Off
Questions to Ask Regarding Launch Readiness
Not Knowing Is Not Acceptable
Criteria for Rollback
Singing the Post-Launch Blues
Was It All a Big Mistake?
Metrics
Ongoing Development
Surviving the Next One
Project Tools
1. Project Roles—Checklist and Blend-ability
2. Budgeting Formulas—Calculating a Budget Estimate
3. Budgeting for Contingency—Arriving at a Contingency Number
4. Project Meetings—Key Meetings, Participants, and Agendas
5. Running Effective Meetings—Tips to Keep Meetings on Track
6. The Trough of FUD—Graphic of Emotions in Software Development
7. Alpha Stage/First Look—How to Distinguish a Good Mess from a Bad Mess
8. Project Timeline—A High-Level Typical Timeline
9. Heat Map—A Tool to Track Project Status
10. Budget Tracking—A Tool to Report on Project Budget Status
11. Project Flow Graphic—A Graphic Showing Times of Project Conflict and Calm
12. Common Late-Stage Problems—The Three Most Common Causes of Problems
13. Classifying UAT Feedback—Instructions to User Acceptance Testers
14. Cyber Security—Important Safety Tips
Glossary
Index
End User License Agreement
Pages
xvii
xviii
xix
xx
xxiii
xxiv
xxv
xxvi
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
101
102
103
104
105
106
107
108
109
110
111
112
113
115
116
117
118
119
120
121
122
123
124
125
126
127
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
201
202
203
204
205
206
207
208
209
210
211
212
213
216
223
224
225
226
227
228
229
230
Guide
Cover
Table of Contents
Begin Reading
List of Illustrations
Chapter 1: Software Development Explained: Creativity Meets Complexity
Figure 1.1
Figure 1.2
Figure 1.3
Chapter 2: Agile, Waterfall, and the Key to Modern Project Management
Figure 2.1
Figure 2.2
Figure 2.3
Figure 2.4
Chapter 4: Teams and Team Roles and Responsibilities Defined
Figure 4.1
Figure 4.2
Figure 4.3
Chapter 6: Final Discovery; Project Definition, Scope, and Documentation
Figure 6.1
Chapter 7: Budgeting: The Budgeting Methods; Comparative, Bottom-Up, Top-Down, and Blends; Accurate Estimating
Figure 7.1
Figure 7.2
Chapter 9: Communication; Project Communication Strategy; from Project Kickoff to Daily Meetings
Figure 9.1
Figure 9.2
Figure 9.3
Chapter 10: The Project Execution Phase: Diagnosing Project Health; Scope Compromises
Figure 10.1
Chapter 11: First Deliverables: Testing, QA, and Project Health Continued
Figure 11.1
Figure 11.2
Figure 11.3
List of Tables
Chapter 4: Teams and Team Roles and Responsibilities Defined
Table 4.1 Role Checklist and Blendability Worksheet
Chapter 5: Project Research and Technology Choice; Conflicts at the Start of Projects; Four Additional Project Delays; Initial Pitfalls
Table 5.1
Chapter 8: Project Risks: The Five Most Common Project Hazards and What to Do About Them; Budgeting and Risk
Table 8.1
Chapter 9: Communication; Project Communication Strategy; from Project Kickoff to Daily Meetings
Table 9.1
THE COMPLETE SOFTWARE PROJECT MANAGER
MASTERING TECHNOLOGY FROM PLANNING TO LAUNCH AND BEYOND
Anna P. Murray
Copyright © 2016 by Anna P. Murray. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the Web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at http://www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages.
For general information on our other products and services or for technical support, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002.
Wiley publishes in a variety of print and electronic formats and by print-on-demand. Some material included with standard print versions of this book may not be included in e-books or in print-on-demand. If this book refers to media such as a CD or DVD that is not included in the version you purchased, you may download this material at http://booksupport.wiley.com. For more information about Wiley products, visit www.wiley.com.
Library of Congress Cataloging-in-Publication Data
Names: Murray, Anna, 1966- author.
Title: The complete software project manager : mastering technology from planning to launch and beyond / Anna P. Murray.
Description: Hoboken, New Jersey : John Wiley & Sons, Inc., [2016] | Includes index.
Identifiers: LCCN 2015036771 (print) | LCCN 2015040806 (ebook) | ISBN 9781119161837 (cloth) | ISBN 9781119219910 (ePDF) | ISBN 9781119219903 (ePub)
Subjects: LCSH: Computer software—Development. | Software engineering--Management.
Classification: LCC QA76.76.D47 M877 2016 (print) | LCC QA76.76.D47 (ebook) | DDC 005.1--dc23
LC record available at http://lccn.loc.gov/2015036771
Cover Design: Wiley
Cover Image: © shuoshu / Getty Images
To my partner in life and business, Chris Moschovitis. Your support makes all things possible.
Foreword
A generation ago, Internet pioneer Carl Malamud took issue with people who complained about bulky computers, byzantine interfaces, and buggy software: “A lot of this ‘too hard to use’ stuff will go away. Radio was so messy for the first 20 years, it wasn't funny. Cars, ditto—you had to be a mechanic to drive one.” Computers, he prophesied, would one day be as easy to use and reliable as automobiles had become, and the electronic frontier would become as simple to navigate as an Interstate with a road atlas.
That day came, of course—including Google Maps to replace the road atlas—but it brought along a paradox. The simplicity, power, and awesomeness that users and executives take for granted disguise the very technical, messy, and difficult work that happens behind the scenes. Gremlins lurk under the lid of your laptop; krakens crouch behind the scrim of your Cloud. A lot of what seems to gleam is the shimmer of WD-40 on duct tape.
Amateurs cheerfully rely on smoothly running software for business and pleasure, but the work of IT is no place for an amateur. Creating and designing systems, maintaining them, and running projects to install, fix, rip out and replace, upgrade, and integrate them—these are complicated tasks. They rarely go according to plan, because they invariably run into some obstacle that could not possibly be foreseen. Even professionals in the industry can be seduced by a project's progress into thinking, “No problem,” when they should be thinking, “Oh, this is hairy.” And, of course, finger-pointing is the consequence of problems, with IT blaming the business, the business blaming IT, and everybody blaming the consultants and software companies.
Anna Murray's book is an extraordinary accomplishment: It speaks as clearly to the IT professional as it does to executive civilians like me. (I'm an English major with a Mac.) For the professional, it is an experienced, no-nonsense guide: the mentor you wish you had. Anna tells you how to put an IT project into the strategic framework that is right for your organization, how to scope a project, how to communicate and plan with stakeholders; she tells you how to assemble your tools and team; she explains how to find, select, and manage vendors; and she tells you how to cook and eat crow when you need to—as you almost certainly will.
The strategic point is particularly valuable. IT long ago migrated from the glass house to the desktop, but it is now part of every nerve and sinew of an organization: It is in the skin that touches customers, in the brain that analyzes performance, in the heart that pumps resources where they are needed. Technologists don't need to be strategists, but they can no longer be strategically ignorant. Anna shows how to connect strategy and IT, how to ask the right questions, and how to frame the trade-offs and decisions that complex IT projects require in a way that business leaders can understand.
This is, at the same time, the book IT managers should give to their nontechnologist colleagues, bosses, and internal customers. Her distinction among IT projects that are simple, complicated, and complex is worth the price of admission by itself. I can think back to half a dozen cases where the business-IT relationship got into trouble because the nontechnologists did not know or could not understand what their IT colleagues were up against. Any executive who reads this book will ask better questions, get better answers, and have a better understanding of the answers.
Thomas A. StewartExecutive Director, National Center for the Middle MarketFisher College of BusinessThe Ohio State University
Acknowledgments
This book grew out of a two-decades-long conversation with my colleagues and with the many clients we are privileged to serve. Starting back in the Windows 3.1 days, we have grappled with the complexities of technology and survived the numerous inevitable crises that accompany software development. My work has provided me with incredible opportunities to collaborate with and learn from these exceptional professionals.
I am grateful for Denise Mitchell and Rebecca Harrigan, incomparable technology leaders, partners, and clients, and for the great team at Kellogg Corporation. Also, for the executive group and the great IT, BA, and PM teams at Harvard Business Publishing. I also owe a debt of gratitude to my own team, from whom I am always learning: Frank G. Andrews, Pedro Garrett, Atsushi Tatsuoka, and Steve Vance.
Thanks goes as well to fellow technology writer Mike Barlow, who showed such generosity of spirit and time in championing this book. To Sheila and Gerry Levine, whose wise counsel has supported me through everything from content to contracts. And, to the International Women's Writing Guild, whose sisterhood of writers and teachers filled all kinds of gaps from craft to the business of writing.
What could be more valuable to a writer than an editorial partner with skill, wit, and wisdom? Hilary Poole, writer and editor extraordinaire, was one of the original collaborators on this project. Thank you for all your help from tidied-up commas to slashed technology jargon.
To the incredible team at Wiley: Sheck Cho, Pete Gaughan, Connor O'Brien, Michael Henton, and Caroline Maria Vincent. Your professionalism and collaboration are all any author could hope for.
And finally, to Chris Moschovitis, whose brilliance in technology and so many other things awes me every day. I am lucky to go to work with you each morning and to come home to you each night.
About the Author
Anna P. Murray is a nationally recognized technology consultant and the founder of emedia LLC, a certified women-owned business. She has consulted on and run large-scale software projects for Kellogg, Harvard Business Publishing, Time Out New York, Slate Group, The American Association of Advertising Agencies, National Cancer Institutes, New York magazine, and many others.
Murray is a double winner of the Stevie Award for Women in Business, a recipient of a Mobile Marketing Association award for mobile app development, several Kellogg agency partner awards, and Folio's Top Women in Media Award. She has served as President and Vice President of the International Women's Writing Guild.
One of a rare species—a woman who owns a successful software-development company—she loves to combine her two passions: technology and writing. Anna writes on technology from a variety of vantage points, including its humorous impact on daily life, its serious business applications, and its role in changing the way people relate to one another.
After spending several years as a teacher and journalist, Murray founded emedia, one of the earliest web-development firms, in 1996. She holds a bachelor's degree from Yale and a master's in journalism from Columbia.
Introduction
The history of software development teaches us that between 30 and 40 percent of all software projects fail. A good majority of those are canceled completely and never see the light of day. It seems everyone has a different prescription for how to avoid this fate. There are shelves of books on how to improve the software development process—books on Agile methodology, Scrum, the Waterfall method, rapid application development, extreme programming, top-down versus bottom-up, and even something called the chaos model.
When a business is faced with a software development project, people don't have the time to become experts in software management and development theory. What you need is not theory, but rather a practical, hands-on guide to managing this complex process, written in a language you can understand.
Some undertakings—be it having kids, climbing Mount Everest, or, yes, software development—are just difficult. And sometimes the most helpful thing is to hear from someone who has been there before and walked the path. That person can tell you what you're going to encounter and what difficulties to expect. An experienced guide may not be able to take away the challenges, but she can prepare you for them.
About a year ago, I was working on a large implementation project. About halfway through, a young project manager came to me and said, “Anna, do you have a crystal ball? Because at the beginning of this project you sat us all down and told us what to expect. You gave us a list of many things and every single one of them has happened—and happened on schedule. Do you have that written down anywhere?”
Now I have it written down somewhere.
Software Project Management
This book is specifically about software project management. There are many other types of project management. Project management is needed for digging oil wells, building skyscrapers, and launching rockets.
Examples of software projects include
Launching websites
Installing a CRM (customer relationship management) tool
Implementing a new accounting package
Building a custom application for your business
Software is truly “its own animal.” People tasked with managing software projects need processes and advice just for them.
A Holistic Approach
Many books on project management focus on what I call the “literal project manager,” the person whose title is “project manager” on his business card. He or she may have a specific certification in the discipline of project management. In Chapter 5, we'll talk in depth about project teams and team members. For now, it's important to understand that the literal project manager is not the only one with project-management responsibilities. People might even be surprised learn how narrowly focused the project manager's job often is (Figure I.1).
Figure I.1
Many books on project management concentrate only on the literal project manager. The purpose of many of these books is to help the project manager pass his or her certification tests, such as the PMP exam. That's great, if you are facing the exam. Unfortunately, this narrow focus leaves much out, not only for the literal project manager but for everyone else.
True project management extends to many people and to the entire business. There is the project sponsor, the program manager, the project manager, and programming teams as well as stakeholders in the broader business. Therefore, this book takes a holistic view of project management. It can be read by businesspeople, programmers, project managers, program managers, and CEOs—anyone who is involved in or affected by a software project (Figure I.2). Of course, it has critical information for people whose job titles are project manager and program manager.
Figure I.2
For Medium-to-Large Projects
Project management looks different depending on the size of the project. The sort of project management involved in putting up your personal WordPress blog likely happens all in your own head. Inside of businesses most projects that last more than a couple of weeks require some kind of external project management.
For this book, I will be giving processes and advice appropriate for medium-to-large projects. This generally means projects that take at least three months and may last as long as two years. The reason I've chosen to focus on projects of this size is they are the most common. Also, smaller projects, as noted earlier, probably don't need much project management at all. Finally, I have found that once people understand the fundamentals of managing medium-to-large size projects, they are able to scale the processes and recommendations both up and down to suit their needs.
Agile vs. Waterfall
For those of you who don't know these terms, don't worry. We'll talk more about this in Chapter 2. Many people familiar with modern software development want to know right up front: Are you talking about project management practices for Agile development or for Waterfall?
This book assumes the incorporation of key Agile methodologies, while acknowledging that most businesses cannot adhere to a purely Agile style. In fact, the issue of Agile vs. Waterfall is a major reason I wrote this book. After running hundreds of software projects inside many different types of businesses, I discovered that good project management is a blend. It must be “agile enough.”
Why Listen to Me?
As the CEO of emedia (www.emediaweb.com), I have been developing software and managing software teams since 1994. I am proud to say that we have a superb track record in delivering software development projects, from large database implementations to small business websites, on time and on budget.
I've managed website launches, database migrations, finance system replacements, custom application development, content management system implementations, and packaged software deployments. The dollar value of these projects has ranged from the small thousands to the tens of millions. It's allowed me to see the commonalities among many software development endeavors and to develop strategies to improve the process.
I am also proud to say that the majority of my customers have been with me for years—a decade or longer in some cases. When you have a challenging undertaking, you want a partner you trust.
Who Is This Book For?
If you're inside an organization undertaking a software development project, this book is for you. If you are a consultant or vendor who rolls out software for customers, this book is for you, too. If you are a business leader, programmer, project manager, or program manager, this book is also for you.
This book has chapters on all the pragmatic stuff you need to know: organizing and staffing a project; the common conflicts that crop up; planning; risk management; and, of course, budgeting. There's even a chapter for people who are midway through a project and are encountering problems. If you read from start to finish, the book will take you through the life cycle of a software development project. Or, you can dip into the chapter based on your particular interest or area of challenge.
Chapter 1Software Development Explained: Creativity Meets Complexity
There are shelves of books and hundreds of thousands of articles dedicated to making software development better. Why has it been so hard for smart professionals to just make software projects run smoothly, on time and on budget? What's up here?
A Definition of Software Development
Software development is any activity that involves the creation or customization of software. As noted in the introduction, it can include
Launching websites
Installing a CRM (customer relationship management) tool
Implementing a new accounting package
Building a custom application for your business
All these activities qualify as software development. Most businesses will, at some point, be confronted by a software development project. Technology is now so intrinsically integrated into business that it's impossible to avoid.
Why Is Software Development So Difficult? Hint: It's Not Like Building a House
A lot of people use the metaphor of house building as a comparison for the activity of software development. I believe this metaphor does an enormous disservice to the process. I reject this metaphor because it gives people a false sense of security and a false understanding of the nature of software development.
A house is concrete and well understood by all. We have all been inside houses. We all share comparable assumptions about what a house is. The same cannot be said for software. In many cases, I have sat in a room with people with completely divergent views about even the most basic aspects of their software project.
Frequently, in developing software, you are creating something from nothing. That means the end product could be practically anything. Here are some endeavors in which, as in software development, you are creating something and the outcome could be a wide range of possibilities:
Writing a novel
Growing a garden
Composing a symphony
There is a “blank slate” quality to creative activities. When you begin a novel, for example, the end product could take an almost infinite variety of forms. The listed endeavors, you'll notice, are all open to a wide scope of interpretation. One person's assumptions regarding the nature of a garden (flowers) may not remotely match another person's (vegetables). So it is with software development: You might think that the parameters of your project ought to be “obvious”—but they may not be obvious to your colleagues.
The previous examples all capture a fundamental reality of software development. By its very nature, software development is creation. You're going from a state where something doesn't exist to one where it does. At the beginning, the outcome could be anything, which means that everyone in the room probably has a different understanding about what the project actually is.
The Simple, the Complicated, and the Complex
In The Checklist Manifesto (2009, Metropolitan Books), a book I highly recommend, author Atul Gawande talks about three types of endeavors—the simple, the complicated, and the complex. It's helpful to understand these distinctions because software development almost always involves all three:
Simple project components are easy to conceptualize. You know what needs to get done, and you simply need to get out the elbow grease and do it.
Complicated project components are hard to understand and involve a lot of steps, but they are not very risky. If you read the directions carefully enough and follow them, you will get the project done.
Complex pieces of projects, on the other hand, have a lot of variables like the complicated, but they are also highly fluid and very risky.
As already noted, software projects almost always involve all three types of activities: the simple, the complicated, and the complex. The percent mixture of each depends on the project.
I use three of my own metaphors to describe the simple, complicated, and complex as they relate to software development. Mastering these three metaphors and learning to apply them in software will help you manage any software project more successfully.
Metaphor #1: Piles of Snow
“Piles of snow” is the phrase I use to describe the simple activities within a software project.
Imagine a massive snowstorm blew through overnight. You wake up and your 200-foot-long driveway is completely blanketed in white. Worse, the plow guy called to say he can't make it. The city plow comes through and there is now an even greater pile at the end of your driveway (Figure 1.1).
Figure 1.1
What you need to do is absolutely clear. Get a shovel and dig! How to do it is also no mystery.
Keep in mind simple doesn't mean easy. In fact, most of the time a lot of labor is involved in piles-of-snow software tasks. It's going to be a lot of work to shovel that driveway, especially if there's no one to help. But the “project” is simple in concept and in execution: Dig until you are done.
I will return to the “piles of snow” metaphor again and again in this book.
Metaphor #2: The Ikea Desk
“Ikea desk” is a term I use to describe complicated aspects of software projects.
Furniture from the Swedish store Ikea comes boxed up and involves seemingly millions of little pieces (Figure 1.2). The directions are expressed solely in pictures, presumably because it's more efficient to do it this way when you serve an international customer base. Imagine the effort to translate all those directions into hundreds of languages!
Figure 1.2
To begin your Ikea desk project, you must lay out all the tiny pieces on the floor and match them to the illustrations in the directions. Then you must meticulously follow the directions. There is frequently trial and error. Wait. Was that the part? It doesn't seem to fit. No, I think this one is the right screw. It's the smaller-than-middle-sized one.
Anyone who's put together an Ikea desk remembers a weekend spent on the living room floor before the furniture piece is finally ready. It can be frustrating. It's time consuming. You may be missing a part and have to go back to the Ikea store and wait on the customer service line. Despite all this, success is virtually guaranteed. With enough time and Allen wrenches, you will get it done.
Ikea desks require more application of brainpower (e.g., reading and interpreting detailed directions), more concentration, and more backtracking and redoing than shoveling piles of snow. Further, the time it will take to assemble the Ikea desk may be harder to judge than the driveway shoveling. You may say something like, “I'll have this baby assembled by noon,” only to realize you put the wrong screws in and assembled it backwards. It's more like midnight when you actually finish. But in both cases, a successful outcome is 99 percent guaranteed.
Metaphor #3: Heart Surgery
The Checklist Manifesto uses heart surgery as an example of a complex activity, and it works well to describe aspects of software development.
To perform heart surgery, you absolutely need extensive training and skill. Further, your patient might have an undiagnosed medical problem that causes the operation to unexpectedly fail. The human body is not 100 percent understood by anyone. It is squishy and organic and unpredictable. The fact is, no matter how much you plan, certain variables are out of your control (Figure 1.3).
Figure 1.3
Unlike Ikea desks or piles of snow, heart surgeries are unpredictable and risky. Training and experience helps, but even with all that, you have no guarantee that the surgery will succeed.
Hint: Finding a surgeon with experience in risky heart surgeries does help.
Using the Three Metaphors in Project Management
Ideally, your project would involve many piles of snow, a moderate number of Ikea desks, and as few heart surgeries as possible. You would strive to reduce complexity in your software to the degree possible. In many cases, this is the best approach and we'll continually return to it throughout this book.
But sometimes the choice isn't up to you. Your project may simply have complex elements you can't avoid. Many, if not most, software projects do.
Furthermore, to say something is “complex” or a “heart surgery” is just another way of saying it's risky, with many unpredictable and unknown elements. This brings us back to the concept of creativity, discussed at the beginning of this chapter. Creative endeavors involve, by definition, lots of unknowns. One of the main reasons people undertake software projects is, indeed, to be creative and to come up with something new. That's what we call innovation! And innovation is a key business goal for many organizations. Is there a business that does not wish to pursue innovation?
The problem comes in when people sign up for complexity in an unconscious way. They never look at the pieces of their project and evaluate which are snow piles, Ikea desks, and heart surgeries. Worse, believe it or not, some people seek out complexity. Why would someone do that? Signing up for complexity and risk sounds crazy, right?
One only needs to drive on the freeway for a reminder that human beings often and consistently seek out risk. Software development is usually exciting to business stakeholders, who may spend most of their lives in dusty old Excel spreadsheets. The chance to do something creative and techy brings out the risk taker in many people.
The reality is that most people, even programmers, do not analyze the projects they undertake in terms of the simple, the complicated, and the complex. They sign up for a project and simply accept, “It is what it is.” However, especially in the first phases of your project, it is essential to identify what is a pile of snow, what is an Ikea desk, and what is likely to be a heart surgery. Then you can make informed decisions on project approach, planning, staffing, and budgeting. You can make considered choices about where you can and cannot reduce complexity and where you consciously wish to sign up for complexity to achieve your business goals.
Chapter 2Agile, Waterfall, and the Key to Modern Project Management
Agile and Waterfall
Many professionals, especially those with little or no technology background, enter into projects in an unconscious way. They may not have heard the terms “Agile” or “Waterfall.” And they might not know which of these methods their tech teams practice. Agile vs. Waterfall is certainly the most commonly heard debate in terms of approaching a software project.
People involved in software development have almost certainly heard the terms Agile and Waterfall. They will be familiar with the ongoing debate about these two forms of project approaches. Understanding these two ways of approaching projects—when and where one method has an advantage over another, and what version in what balance is right for your organization—is foundational to good software project management.
First, here are some definitions.
Waterfall
You could replace the term “waterfall” with the term “traditional.” The Waterfall project approach is generally regarded as a more traditional way to manage software development.
The Waterfall process has been around for decades. It is a sequential way of developing software:
Gather software requirements
Design the technical solution
Code the software
Test and debug the software
Deliver the finished product
Enter maintenance mode
Sounds logical, right?
The name Waterfall came from the boxes and arrows used to illustrate these steps. The arrows make it seem like water is flowing over a series of small waterfalls (Figure 2.1).
Figure 2.1
Waterfall's Problems
Nothing is perfect and the Waterfall method is no exception. Over many decades Waterfall was the default method to develop software, and many problems were common.
The Requirements Requirement
The Waterfall method calls for all the software's requirements to be thoroughly collected and documented up front, then handed off to an implementation team. This practice conjures an image: Tome-like requirements documentation is presented to a programmer who then disappears into a cave for long months before emerging in spring with a finished product.
It's very difficult to do “thorough enough” requirements gathering. How much is the right amount? You could go on infinitely documenting every possible user click under every possible condition.
Two results were common in the Waterfall method: (1) Requirements took so long as to be impractical. (2) Requirements were missed. In the first case, a software project can't get off the launch pad. In the second, programmers may work while assuming they have the complete requirements, only to discover later they were wrong. Since the product is not seen until the very end in the Waterfall method, this leads to costly refactoring of software.
Inflexibility
In the Waterfall method, you define things first, and then the programmers get to work. Changes to specifications are frowned upon. There is a formal “change request” process by which any alteration to the initial requirements goes through a review and costing process.
Loss of Opportunity and Time to Market
One of the famous rules in technology is Moore's Law. This is the axiom that states that computing power will double every 18 months. You see the effect of Moore's Law all around you. Chips get smaller, cell phones get more powerful, and flat screen TVs get cheaper.
Moore's Law also has an impact on software development project management. In technology, things move fast—really fast. If a software project takes 18 months to deliver, you've missed an entire Moore's Law cycle, because the business specifications were written 18 months ago.
What has happened in the intervening months? What progress has been made in the technology world around us that your project could leverage?
If you ask these questions in a formal Waterfall environment, you'll be greeted with a snarl and presented with a change-request form.
Customer Dissatisfaction
Did the project requirements truly capture what the business wanted? It takes a very talented and thorough business analyst to do this. Were the requirements accurately transmitted to the programming team? Again, very nuanced and consistent communication must happen to achieve this goal.
Here's another reality: People forget. It's unfortunate, but they do. For a little while, as the project team interacts with the business stakeholders and gathers requirements, the business stakeholders are deeply engaged. Then, the project team disappears to work on the project and the business stakeholders forget. Worse, they often start to embellish in their own heads what the software will do when it's done. The finished business requirements document is often never read. The business stakeholders look at the impressive pile of paper and just assume it contains all their hopes and dreams. It must, right? It's so thick with so many Visio diagrams. The business requirements document collects dust in a drawer.
When the project is delivered, many months later, the customer declares it wasn't what they wanted.
Agile
“Agile” is a relatively new term, officially coined in 2001 when a group of software professionals released a document called the Agile Manifesto. However, many of us who were in software development prior to 2001 were already working on ways to make software development more flexible and reduce some of its problems.
The Agile Manifesto (and many books and articles written since) codifies a software development method that isn't just a modification of the Waterfall method. It throws Waterfall over the proverbial waterfall.
The easiest way to understand Agile is as the extreme opposite of traditional sequential software development. The Agile process values constant collaboration, frequent deliverables, and continuous evolution of requirements. There is constant communication; shifts are made in real time; and surprises are less frequent.
Figure 2.2
