
The Complete Software Project Manager
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
More details
Other editions
Additional editions

Person
Content
- Intro
- Title Page
- Copyright
- Table of Contents
- 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
Chapter 1
Software 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).
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!
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).
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...
System requirements
File format: ePUB
Copy protection: Adobe-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Install the free reader Adobe Digital Editions prior to download (see eBook Help).
- Tablet/smartphone (Android; iOS): Install the free app Adobe Digital Editions or the app PocketBook before downloading (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (not Kindle).
The file format ePub works well for novels and non-fiction books – i.e., „flowing” text without complex layout. On an e-reader or smartphone, line and page breaks automatically adjust to fit the small displays.
This eBook uses Adobe-DRM, a „hard” copy protection. If the necessary requirements are not met, unfortunately you will not be able to open the eBook. You will therefore need to prepare your reading hardware before downloading.
Please note: We strongly recommend that you authorise using your personal Adobe ID after installation of any reading software.
For more information, see our ebook Help page.