book

The Complete Software Project Manager

Name: The Complete Software Project Manager
Author: Anna P. Murray
ISBN: 9781119161837

by Anna P. Murray

January 2016

Beginner to intermediate

256 pages

6h 13m

English

Wiley

Read now

Unlock full access

Cover
Title Page
Copyright
Dedication
Foreword
Acknowledgments
About the Author
Introduction
Software Project ManagementA Holistic ApproachFor Medium-to-Large ProjectsAgile vs. WaterfallWhy Listen to Me?Who Is This Book For?
Chapter 1: Software Development Explained: Creativity Meets Complexity
A Definition of Software DevelopmentWhy Is Software Development So Difficult? Hint: It's Not Like Building a HouseThe Simple, the Complicated, and the ComplexMetaphor #1: Piles of SnowMetaphor #2: The Ikea DeskMetaphor #3: Heart SurgeryUsing the Three Metaphors in Project Management
Chapter 2: Agile, Waterfall, and the Key to Modern Project Management
Agile and WaterfallWaterfallWaterfall's ProblemsThe Requirements RequirementInflexibilityLoss of Opportunity and Time to MarketCustomer DissatisfactionAgileLack of Up-Front PlanningLack of Up-Front CostsStakeholder InvolvementExtensive TrainingWhere Agile Works BestThe Need for Up-Front Requirements in Many ProjectsThe Real WorldAgile EnoughThe 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 ApproachHistoryThe Benefit of Off-the-ShelfOff-the-Shelf ExamplesThinking You're Editing When You're Actually CreatingCommon Challenges with Off-the-Shelf SoftwareBusiness CompromiseDiscovering You Made the Wrong Choice with Packaged SoftwareBreaking the Upgrade PathLocked into a Partnership and the Product RoadmapExpense of Off-the-ShelfWhere Packaged Software Works WellFrameworks and the Blurring Worlds of Custom and Packaged SoftwareIntegrations vs. One Tool for the JobTo Phase or Not to PhaseBigger Is Not Always BetterThe Pilot ApproachWhy Not Pilot?
Chapter 4: Teams and Team Roles and Responsibilities Defined
Teams and the Roles on TeamsProject LeadershipThe Key Business StakeholderThe Project SponsorThe Program ManagerProject ManagerMultiple Project ManagersConfusion About the Project Manager Role; It's More Limited than You ThinkProject TeamThe Business AnalystUser ExperienceDesignerThe ProgrammersArchitectSystems AdministratorTeam Member Choice and Blending RolesGetting All the Roles CoveredReal-World Examples for Role-BlendingProfessionals and PersonalitiesInsource or Outsource: Whether to Staff Roles with Internal People or Get Outside HelpThe Myth that Insourcing Programming Is BetterInexperience with ProjectsHow Knowledge Goes StaleOutsourced TeamsWhen to Use Internal or External TeamsRoles Easiest to OutsourceRoles “in the Middle”Roles that Are Usually InternalVendors and Hiring External ResourcesSome Tech-Types to Avoid: Dot Communists and ShamansThe ShamansBoundaries, Responsibilities, and Driving in Your LaneTechies Who Don't Drive in Their LaneBusiness Stakeholders Who Shirk ResponsibilitiesBusiness Stakeholders, Step Up!Have a Trusted Technology PartnerHow Best (and Worst) to Work with Your Technology PartnerToo 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 DefinitionThe Project's Research PhaseCurrent StateIntegrations and Current StateData and Current StateBusiness NeedsPossible Technology SolutionsDemosComparison GridsTalk to Other People, a Journalistic ExerciseHow Do You Know When Your Research Is Done?Research Reality CheckYou Can't Run the ControlReligious WarsPassion over ReasonBusiness Stakeholders and Controlling EgoHow to Stop a Technology Religious WarNot So EasyPreventing a Technology Religious WarBeing RightStopping a War in Its TracksDétente and Finally Ending a Technology Religious WarClarityThe Role of the CIOTwo Most Important Factors in Core Technology DecisionsOther Conflicts that Delay the Start of ProjectsThe Project Charter, a Key Document
Chapter 6: Final Discovery; Project Definition, Scope, and Documentation
Budgeting and Ongoing Discovery; Discovery Work Is Real WorkBudgeting Final DiscoveryWhat Comes Out of Final Discovery: A PlanGetting to a PlanThe MurkGetting Out of the MurkThe Plan for the Plan—Company AHow Anyone Can Make a Plan for the PlanDifferent Approaches to Elicit the Plan for the PlanException to the MurkBreakout SessionsThe Weeds Are Where the Flowers GrowNot All Questions Will Be AnsweredAgile, Waterfall, and Project DocumentationThe Scope DocumentProject SummaryProject DeliverablesOut of ScopeConstraintsAssumptionsRisksTimelineBudget, Scope, Timelining, and Horse-TradingMetricsWhat About “the List”?Defining and Visualizing and Project ScopeWhere Does Design Fit In?Working with Marketing StakeholdersHow You Know You're On the Wrong TrackA Word About Ongoing Discovery
Chapter 7: Budgeting: The Budgeting Methods; Comparative, Bottom-Up, Top-Down, and Blends; Accurate Estimating
An Unpleasant PictureWhat Goes on Behind the Scenes; a SceneBudgeting Type 1: Comparative BudgetingGotchas with Comparative BudgetingBudgeting Type 2: Bottom-Up BudgetingThe Rub in Bottom-Up BudgetingBudgeting Type 3: Top-Down and BlendsWhy RFPs Don't WorkAccurate Estimating and Comparison BudgetingEffective Estimating in Top-Down and Bottom-Up BudgetingEstablish a Base Budget for Programming, Ongoing Discovery, Unit Testing, Debugging, and Project ManagementPercentages of EachProgramming Hours—Raw and FinalThe Math PartAdditional Items to ConsiderBudgeting and Conflicts
Chapter 8: Project Risks: The Five Most Common Project Hazards and What to Do About Them; Budgeting and Risk
Five Always-Risky ActivitiesWant Versus NeedOptimism Is Not Your Friend in Software DevelopmentFacing RisksA Few Words About FaultIdentifying Risks Up FrontTalking to Your BossHidden InfectionsThe Contingency FactorThe Cost of ConsequencesIn the Real WorldThe Good NewsA Common QuestionLong-Term Working Relationships and Contingency
Chapter 9: Communication; Project Communication Strategy; from Project Kickoff to Daily Meetings
Project KickoffProject Kickoff CastProject LeadershipCompany LeadershipWho Gives the Kickoff?Kickoff PresentationHigh-Level Project DefinitionBusiness Case and MetricsProject ApproachTeam Members and RolesProject ScopeOut-of-ScopeTimelineBudgetRisks, Cautions, and DisclaimersMonthly Steering CommitteeMonthly Steering Committee AttendeesMonthly Steering Committee AgendaWeekly Project Management MeetingWeekly Project Management AttendeesWeekly Project Management AgendaDaily Standup MeetingWell-Run MeetingsInsist on AttentionTimelinessGetting “into the Weeds”Needs to Be Kicked UpstairsPoor Quality Sound—Speakerphones and Cell PhonesToo Much TalkAgenda and Notes
Chapter 10: The Project Execution Phase: Diagnosing Project Health; Scope Compromises
What Should Be Going on Behind the ScenesThe Best Thing You Can Ever Hear: “Wait. What Was It Supposed to Do?”Neutral CornersWhat If Things Aren't Quiet?Making DecisionsHow to Listen to the ProgrammersSneakerNet and the Fred Operating SystemDemos and Iterative DeliverablesWhy Iterative Deliverables Are ImportantWhy Iterative Deliverables Are HardWhat You Can Do to Achieve Iterative Deliverables Even if It's HardDemosScope CreepDealing with Scope Creep; Early Is BetterScope Creep and BudgetingScope Creep and GovernanceTypes of Scope CreepScope Creep and the Team
Chapter 11: First Deliverables: Testing, QA, and Project Health Continued
The Project's First ThirdThe Second ThirdA First Real Look at the SoftwareThe Trough of FUDDistinguishing a Good Mess from a Bad MessAn Important CheckpointGetting to StabilityFirst Testing and the Happy PathQuality AssuranceBug ReportingRegression TestingBugs: Too Many, Too FewTesting: The Right Amount for the JobToo Much Testing?Bug Cleanup PeriodTimeline So Far
Chapter 12: Problems: Identifying and Troubleshooting the Three Most Serious Project Problems; Criteria for Cancellation
A Rule About ProblemsAdditional ResourcesFault—A ReviewCommon Late-Stage ProblemsLurking InfectionsWrong Technology ChoiceLack 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 HappensControlling UAT and “We Talked About It in a Meeting Once,” Part DeuxClassifying UAT FeedbackBugsNot Working as Expected—The Trickiest CategoryRequest for ImprovementFeature RequestConflict Resolution and Final Launch ListLoad TestingPerformance TestingSecurity TestingSign-OffQuestions to Ask Regarding Launch ReadinessNot Knowing Is Not AcceptableCriteria for RollbackSinging the Post-Launch BluesWas It All a Big Mistake?MetricsOngoing DevelopmentSurviving the Next One
Project Tools
1. Project Roles—Checklist and Blend-ability2. Budgeting Formulas—Calculating a Budget Estimate3. Budgeting for Contingency—Arriving at a Contingency Number4. Project Meetings—Key Meetings, Participants, and Agendas5. Running Effective Meetings—Tips to Keep Meetings on Track6. The Trough of FUD—Graphic of Emotions in Software Development7. Alpha Stage/First Look—How to Distinguish a Good Mess from a Bad Mess8. Project Timeline—A High-Level Typical Timeline9. Heat Map—A Tool to Track Project Status10. Budget Tracking—A Tool to Report on Project Budget Status11. Project Flow Graphic—A Graphic Showing Times of Project Conflict and Calm12. Common Late-Stage Problems—The Three Most Common Causes of Problems13. Classifying UAT Feedback—Instructions to User Acceptance Testers14. Cyber Security—Important Safety Tips
Glossary
Index
End User License Agreement

Content preview from The Complete Software Project Manager

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 ...

Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.

Read now

Unlock full access

More than 5,000 organizations count on O’Reilly

O’Reilly covers everything we've got, with content to help us build a world-class technology community, upgrade the capabilities and competencies of our teams, and improve overall team performance as well as their engagement.

Julian F.

Head of Cybersecurity

I wanted to learn C and C++, but it didn't click for me until I picked up an O'Reilly book. When I went on the O’Reilly platform, I was astonished to find all the books there, plus live events and sandboxes so you could play around with the technology.

Addison B.

Field Engineer

I’ve been on the O’Reilly platform for more than eight years. I use a couple of learning platforms, but I'm on O'Reilly more than anybody else. When you're there, you start learning. I'm never disappointed.

Amir M.

Data Platform Tech Lead

I'm always learning. So when I got on to O'Reilly, I was like a kid in a candy store. There are playlists. There are answers. There's on-demand training. It's worth its weight in gold, in terms of what it allows me to do.

Mark W.

Embedded Software Engineer

Publisher Resources

ISBN: 9781119161837Purchase book

Cloud Computing

Data Engineering

Data Science

AI & ML

Programming Languages

Software Architecture

IT/Ops

Security

Design