Ed Yourdon email: ed@yourdon.com

Website: www.yourdon.comBlog: www.yourdonreport.com

Twitter, LinkedIn, Facebook, Flickr: “yourdon”

Hanoi, November 2013

Death MarchProject Management

2

Intro: what is a “death march” project?Wikipedia definition (“death march”) Current example: Obamacare website (see Oct 16, 2013 Bloomberg article, “The Obamacare Website Didn’t Have to Fail. How to Do Better Next Time”)Almost always: Significant schedule pressure – project must be finished in far less than “nominal” time. Often: Staffing shortages – project must be done with significantly fewer people than in a “normal” projectSometimes: budget limitations – inadequate funding to pay for people, development tools, and other resources.Inevitably: greater risks (>50% chance of failure), more pressure, unpleasant politics Almost always: heavy overtime (more than just 10-20% extra effort), personal sacrifices, increased burnout, higher turnover, lower productivity, lower qualityIncreasingly often: significant corporate consequences (e.g., bankruptcy), lawsuits, personal legal liabilities

3

Succeeding with death-march projectsNot: tyrannical behavior (which rarely works anyway)Not: Breath-taking charismatic, visionary leadership.Compatible with, but not the same as: extreme programming (XP), agile methods, rapid application development (RAD), etc.An appreciation that time is the most precious resource

Avoiding the squandering of time (usually raises political issues)Requires appreciation of the dynamics of software processesMust help project team members manage their time effectively

Usually a combination of several things:Savvy "political" behavior — including the absolute necessity of breaking some rulesSkillful negotiation of deadlines, budget, resourcesAppropriate “peopleware” strategiesAppropriate system development processes (especially agile, perhaps also SEI-CMM, XP, etc)Monitoring and controlling real progress on a day-by-day basisAppropriate use of development tools & technologies

4

More on Steve JobsNone of us can be exactly like Steve Jobs ... and it’s not clearwhether any of us would want to be exactly like himBut he achieved remarkable things, and it may be useful to adopt/adapt some of his best ideasMany of his successful accomplishments involved death-march projectsSuggestion #1: watch his 2005 Stanford commencement address. “Stay hungry, stay foolish.”Suggestion #2: See October 13, 2013 New York Times article, “And Then Steve Said, ‘Let There Be an iPhone!’” Watch Steve’s comments on the importance of passionRead the Walter Isaacson biography, “Steve Jobs”Some key ideas/concepts to think about:

Look for projects that will “put a dent in the universe”Be demanding and brutally honest, to eliminate “B” players and have a project team with only “A” playersIs it really necessary to be a mean, nasty, un-generous bastard to succeed?Is the demand for perfection necessary, or is “good enough” really good enough?

Consider breaking rules in your organization!!!!!!!

Published under the GNU Free Documentation License (GFDL) 5

If You’ve Got an iPhone Project, You’d better Be Agile

Most of us will never have an “iPhone project” — ‘one is very fortunate if you get to work on just one of these projects in your career’Some things to remember:

You won’t anticipate all of the technical problems that you’ll faceSome problems will seem insurmountable; initial design(s) will failThe users will have no idea what their requirements are, for they will be looking at something completely newBut they will change their opinions and expectations dramaticallyNevertheless, their opinions will change dramaticallyEstimation is impossible, since it’s something never done before

6

More on breaking rulesThis is often a cultural/ethnic/national issueAnd it may be a generational/age issue — e.g., younger employees might find it easier to be rebellious, and break any rules they don’t likeIt may be a question of degree: everyone is nervous, to some extent, about confronting authority, inviting punishment, risking being fired, etc.But it depends on the stakes: all of us would break rules — without hesitation — to save our childrens’ livesPerhaps I should say, “Reinterpret the rules to your advantage”Or just, “Be brave!”Examples of rules that you might break (or reinterpret)

Refusing to accept deadlines or schedules that are clearly impossibleRefusing to make project team work 9-to-5 hours in unproductive office environmentRefusal to allow/disallow (depending on situation) massive amounts of overtimeRefusal to wait for approval before allowing “morale budget” expenditures

Download (free) first four chapters of “Hacking Work: Breaking Stupid Rules for Smart Results” — or buy the book on Amazon

7

2. PROJECT POLITICSKey questions for death march projectsIdentifying owners, customers, shareholders, and stakeholders in a death march software projectStakeholder disagreementDetermining the basic nature of the projectLevels of commitmentA new idea: prediction markets

8

Identifying the playersKey point: your chances of success in a death march project are often zero if you don’t know who the key players areAlso crucial that everyone on the project understands this – not just the project managerTypical players:

Owner: who pays for, or “accepts” the system?Customer: who will actually use the system?Stakeholder: someone whose interests are affected by the success/failure of the project, and who can affect the outcome of the project – and who may thus become an ally or obstacle to project success. See “Project Clarity Through Stakeholder Analysis,” by Larry Smith, Crosstalk: The Journal of Defense Software Engineering, Dec 2000The "loser user"

Note: these roles may not be obvious, and they may shift during the course of the project

9

Stakeholder disagreementAn observation from Tom DeMarco: incomplete, ambiguous specifications are often a sign of irreconcilable disagreements among stakeholders, rather than incompetence on the part of systems analystsIn addition, these disagreements invariably cause significant project delays, which imperils the deadline.One solution that project manager should try very hard to implement: JAD sessions. (see Joint Application Development for good discussion of techniques.)If that's not possible, try to get a commitment from stakeholders that all issues requiring their approval, consent, or review will be resolved in no more than 24 hours. For a good example of this, see discussion of “death march software engineering” in the 100-day projects carried out by Tom Love's ShouldersCorp.

10

Determining the Basic Natureof the Project

chances of success

happiness

Key point: get the project team members to indicate where they think they fit into this grid.

suicide

missionimpossiblekamikaze

“Ugly”

11

Levels of CommitmentThe parable of the chicken and the pigRemember that different members of the “key players” have different levels of commitment...... some of which may be publicly stated, and some of which may not... and all of this may change on a daily basisA reminder: one of the primary reasons we succeeded with Y2K is that (for the first time!) we actually had substantial commitment from the CEO and the Board of Directors

12

Wisdom of crowdsRefers to the process of taking into account the collective opinion of a group of individuals, rather than a single expert, to answer a question or provide informationOne popular example, involving collecting/gathering of information: WikipediaAnother popular example, involving non-experts to determine what news is important, so that people outside the group can view the news based on those ratings: DiggBut also used to for estimating/predicting outcomes and results (e.g., elections winners, likelihood of achieving a deadline/schedule, value of coins in a jar, etc). Remember: such events may change dynamically!Works best when crowd has: diversity, independence, decentralization, and ability to aggregate judgments/opinions. Group does not have to be cohesive; members do not even have to know each other.Failures more likely if crowd exhibits: homogeneity, centralization, division (lack of access to other’s info), imitation, emotionality

13

Prediction marketsBasic concept: let “wisdom of the crowds” provideassessment of likelihood of achieving deadlines and/or other organizational goalsCurrently being studied/researched by Google, Microsoft, and other software/IT organizationsSee “Using Prediction Markets to Support IT Project Management,” by Herbert Remidez and Curt JoslinBasic idea: assign a value of, say, $1.00, to the achievement of a specific goal (e.g., meeting a deadline)And then let participants buy and sell “shares” of stock in a fictional company trying to achieve that goalIf average price is $0.55, then there the “crowd” is saying there is a 55% chance of achieving that goal.A tool to consider: Inkling Markets (see case study from large telecommunications company)

14

Details on Inkling MarketsSpoke recently to Adam Siegel, adam@inklingmarkets.comHosted version of service uses U.S.-based hosting vendor — not acceptable to many European/Asian IT organizationsHosted version of service costs $6 per user per month, with minimum of 250 users. Volume discounts for larger groups“Installed” service (on your servers, behind your own firewall) is $45,000 plus $4 per user per month, min 250 ppl45-day free demo lets you try it at no risk“Public” Web-based access is free, and you can create a “private group” to try out the concept within your organization

15

3. PROJECT NEGOTIATIONSManaging project definition at the beginning of the projectUsing project definition to manage requirements creepEstimating techniquesTools for assisting estimation processTradeoffs between schedule, budget, staff, qualityTools for rational negotiationDocumenting political issues and decisionsWhat to do when rational communications are impossible

16

Managing Project Definition:What does “success” mean?Many projects succeed/fail at the very beginning, before any tech. work is done. Fundamental requirement: identifying who has the right to declare “success” – owner, shareholder, etc, etc.Typical definitions of “success”

finishing on time, or at least "reasonably close" to on-timestaying within budget, or at least not too far above the budgetdelivering the required functionality, or at least a tolerable amount of functionalityproviding “good enough” level of quality, in terms of "show-stopper" bugsProviding adequate efficiency/capacity/performance to get the work donegetting the next round of VC funding, or launching the IPO

Key indicators of a doomed project:Nobody can articulate what “success” means for this project……or it’s such a vague definition that it will be hard to demonstrate successKey stakeholders cannot reach agreement on definition of success

The combination of these constraints may prove impossible to achieve – so the pragmatic aspect of success often depends on agreement as to which areas can be compromised or satisfied.Biggest risk: lack of realistic triage at beginning of projectFor more details, see my articles, “Spelling Success,” Computerworld; and “Long-Term Thinking,” Computerworld; and “The Value of Triage,” Computerworld

17

"Good Enough"General concepts

Facebook’s version: “Move fast and break things”, and “Done is better than perfect.” (See Mark Zuckerberg’s Feb 1, 2012 letter to investors: “the Hacker Way”)Familiar concepts of Pareto Principle (the “80-20 rule”) are often ignoredRemember: "triage" is not the same as "prioritization"Early triage is crucialDocumentation of good-enough standards is crucial

FunctionalityCritical: without these functions, system can't be used at allImportant: without these functions, there will be substantial cost/problemsDesirable: without these functions, users will whine and complain

QualityDefects by severityMean Time To Repair (MTTR) by severity levelCredible evidence of “convergence” to an acceptable level of quality

Performance (response time, throughput, volume, capacity, etc.)Critical: failing this level means that daily/weekly workload can't be doneImportant: failing this level means significant loss of productivity/capacityDesirable: failing this level creates a noticeable, annoying impact

Published under the GNU Free Documentation License (GFDL) 18

Estimating: IntroductionWhat is estimation? The calculated approximation of a result (e.g., a completed deliverable), even if theinput data is incomplete or uncertain Estimation is not the same as negotiationEstimation is not the same as a political demand/decree that a project be finished on a particular dateTraditionally, there have been many, many problems with the way estimating has been carried out in IT development projects...

Published under the GNU Free Documentation License (GFDL) 19

Problems withtraditional estimation

The estimate is actually a thinly-disguised acceptance of a political demand for a specific completion dateThe estimate is the result of a negotiating process analogous to haggling over the price of a rug in a Middle East bazaarThe estimate is carried out by people with no experience in the details of the work to be done — so it’s just a guessThe estimate is carried out by people who have a vested interest in achieving a desired result, and/or who are susceptible to persuasion and “group-think”Even if it’s acknowledged that the initial estimate is only approximate, the “cone of uncertainty” is ignored — re-estimating is forbidden.Stakeholders (managers, key customers, etc.) are extremely loath to acknowledge the need for re-estimatingEven project leaders and IT professionals are often reluctant to re-estimateNote: all of this has been well understood in the IT field for 30 years or more — but we have rarely confronted the problem directly and chosen a different approachAnd there’s no guarantee that it will “magically” change just because someone says “we’re agile now!”

Published under the GNU Free Documentation License (GFDL) 20

Agile EstimatingInitial estimate of entire project often necessary as a result of “envisioning” activityKey point: envisioning activity takes hours or days, not weeks or monthsFundamental concept: accept the reality that the initial estimate is likely to be quite inaccurate Take advantage of “wisdom of the crowd”Use techniques to reduce the likelihood of “group-think”Revise estimates after every iteration/version/sprintUse previous “actuals” to guide future estimatesResist temptation to promise future miracles/overtime to compensate for past shortfalls

21

Estimating TechniquesFor complex projects, get a commercial estimating toolFundamental truth: to estimate a project you need metrics from previous projects. Most IT organizations have almost no metrics about previous death march projects.Thus, most of what’s described as “estimating” is either “guessing” or “negotiating” (see “Metrics and the Seven Elements of Negotiation,” by Michael Mah, IT Metrics Strategies, April 2001)Political reality: estimates are produced by people with little prior estimating experience, and who have a vested interest in believing their optimistic predictionsA radical suggestion: create a separate estimating group whose work is judged and rewarded by accuracy of its estimates, not the political acceptability of estimatesFor a new approach to estimating, see “critical chain” approach, which “pools” safety estimates across several tasks within a project.Also, try the concept of “prediction markets”

22

Additional strategiesfor estimating

System dynamics models, e.g., Tarek Abdel-Hamid’s model in iThink Copies of The Mythical Man-Month for all concerned…or copies of Tom DeMarco’s The Deadline for those who prefer a less serious book.Estimating tools, such as COCOMO-2; also, COSTAR and SLIM (Michael Mah) and SPR-20 and SEER-SEM (see YouTube video)Time-boxing to see how feasible/infeasible the project constraints really are

23

Tradeoffs between schedule, budget, functionality, staff, quality

Key point: it’s not a linear tradeoff – see Fred Brooks, The Mythical Man-Month (Addison-Wesley, 1995)Relationship is a non-linear, third-order polynomial relationship – see Larry Putnam and Ware Myers, Measures for Excellence: Reliable Software on Time, Within Budget (Prentice-Hall, 1992)Biggest risk: tradeoffs are usually negotiated, under pressure, late in the project schedule – without accepting the non-linear tradeoffs ...... and without accepting the reality that much of the partially-finished work will be lost foreverTo negotiate tradeoffs rationally, you need to have one of the estimating packages mentioned earlier

Published under the GNU Free Documentation License (GFDL) 24

Project NegotiationsEven if the boss’ “estimate” seems reasonable, it’s still a political demandThe boss has almost certainly not spoken with the users about their detailed requirementsSo he has no basis at all for the “estimate” he has given youMore likely, his “estimate” is based on a similar dialogue with someone else at the higher level of executive politics where he spends his timeIn any case, he is creating an environment in which you know that the most you can hope for is an “incremental” change in the proposed schedule or budget

25

Negotiating gamesDoubling and add some...Reverse doublingGuess the NumberI’m Thinking of...Double Dummy SpitThe X-Plus GameSpanish InquisitionLow BidGotcha – throwing good money after badChinese Water TortureSmoke and Mirrors/Blinding with Science

thanks to Rob Thomsett, for his “Estimating Games” Web article

26

Estimating strategiesDon’t get tricked into making an “instant estimate” – ask for time to think about (a week, a day, even an hour)State the estimate in terms of confidence levels, or ± ranges, etc.Jim McCarthy (formerly of Microsoft, author of Dynamics of Software Development): make the customer, or other members of the organization, share some of the uncertainty.Project manager: “I don’t know precisely when we’ll finish – but I’m more likely to be able to figure it out than anyone else in the organization. I promise that as soon as I have a more precise estimate, I’ll tell you right away.”Do some reading and research to become better at this area, e.g.:

Bargaining for Advantage: Negotiating Strategies for Reasonable People, by G. Richard Shell (reissue edition, Penguin Books, June 2000)Getting Past No: Negotiating Your Way from Confrontation to Cooperation, by William Ury (Bantam Doubleday Dell, 1993)

27

Documenting political itemsDocument all of these key issues, as part of the permanent record – otherwise, you're likely to find that people “forget” unpleasant realities that you told them about when the project beganOr even worse, the people who made commitments to you about key political issues may have quit, died, retired, been fired, or gotten run over by a crazy Hanoi motorcycle driver.Key things to document (probably in a “project plan” document)

Background of the project (why is this project being carried out?)Scope (what to leave in, what to leave out; use a context diagram for simplicity)Technical assumptionsTechnical dependenciesConstraintsProject approach (what kind of development process will be used)Quality approachDevelopment plan (resource schedule, project schedule, release schedule)

28

What to do when rational negotiation breaks down

Remember Nancy Reagan's advice: “Just say no!”Would you commit to running a marathon in one hour?

Quit (the project or the company)Appeal to a higher authorityGo see the movie Gladiator, and learn to say, like Russell Crowe, “We who are about to die salute you!”Decide which “rules” you’re going to break in order to achieve an “irrational” set of schedule/resource demands that have been imposed upon you.Redefine the project as a kamikaze, suicide, etc., and make sure entire project team knows it.Key point: project leader has to believe in the possibility of achieving project goals... and must be able to convince team members without lying to them

29

Succeeding with death-march projectsNot: tyrannical behavior (which rarely works anyway)Not: Breath-taking charismatic, visionary leadership.Compatible with, but not the same as: extreme programming (XP), agile methods, rapid application development (RAD), etc.An appreciation that time is the most precious resource

Avoiding the squandering of time (usually raises political issues)Requires appreciation of the dynamics of software processesMust help project team members manage their time effectively

Usually a combination of several things:Savvy "political" behavior — including the absolute necessity of breaking some rulesSkillful negotiation of deadlines, budget, resourcesAppropriate “peopleware” strategiesAppropriate system development processes (especially agile, perhaps also SEI-CMM, XP, etc)Monitoring and controlling real progress on a day-by-day basisAppropriate use of development tools & technologies

Ed Yourdon email: ed@yourdon.com

Website: www.yourdon.comBlog: www.yourdonreport.com

Twitter, LinkedIn, Facebook, Flickr: “yourdon”

Hanoi, November 2013

Death MarchProject Management