Home > Articles > Software Development & Management > Management: Lifecycle, Project, Team

This chapter is from the book

This chapter is from the book

Notes

  1. From: Richard Sargent, 72762,3342 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project, Msg #159427, reply to #158778 Date: Mon, Jun 24, 1996, 2:22:20 AM Ed, A colleague of mine passed along this paraphrased quote. I think it applies here. The definition of (corporate) insanity is doing the same thing again and again, and each time expecting different results. I have no idea who originally framed the assertion, but it's gold! Richard Sargent 5x5 Computing Solutions Inc.
  1. From: Dave Kleist, 70730,1613 To: Ed Yourdon, 71250,2322 Topic: Ed's new book project, Msg #158064, reply to #158015 Date: Tue, Jun 4, 1996, 7:28:03 PM Ed, >> 1. Why would anyone in his right mind agree to work on a "death march" project (defined in the terms above)? << Because it's rarely printed as part of the want ad. Not much sense in saying, "Are you interested in working incredible hours for no additional benefit beyond your hiring salary? Does the idea of working endlessly on obsolete technology while 'waiting' for a slot to open up on that exciting GUI/DSS/warehouse/HTML subproject really entice you? Do you define three-tier architecture as an opportunity to hear what other project members will work on without your help?" Seriously, death march projects are rarely billed as such, and it takes a lot of work when being hired from the outside to discover if your hiring company is prone to creating death march projects. In addition, death march projects only look that way. While they demand the hours, every hour is not productive. After a while, peo- ple find ways to do the things they being deprived of (pay bills, run errands). It just isn't billed that way. The environment still sucks, people hate it. And, how accurate are those hours that are being billed? Where do they come from? Got any contractors? Ever heard of "nuisance hours" or "annoyance hours"? You know, where a contractor overbills because they can't stand some of the people they are working for. (Let me say right now that I've never done it and never will do it, but know people who have). The lead or manager does what the con- tractor thinks is stupid, and the contractor takes revenge (in their own quiet way). And, what about overhead? Are all hours to be marked to the project, including corporate and department meetings, training, etc.? >> 2. If a colleague of yours was about to take on the task of man- aging a death-march project, what is the ONE THING you would advise him/her to do? << Try to craft an exquisite exit clause in the contract <VBG>. Seri- ously, one of the reasons for a runaway is the inability of someone to hear reality, usually upper management (either side, IT or busi- ness). Someone taking over a death march has got to find an angle for them to get some manuevering room (functionality, cost, time) in at least one aspect or they are doomed. >> 3. Conversely: what is the ONE THING you would advise your col- league NOT to do, under any circumstances, when embarking upon such a project? << Acknowledge that it is going to be a death-march. Doesn't sound honest but admitting that it's going to be a killer can be demoral- izing for two reasons: one, people don't like to hear that the next 6-12 months could be hell; two, management usually underestimates the negatives. Not much hope if you know right out of the gate that it's going to be ugly. I had friends who worked on one project that had management openly admitting that there was going to be road- kill on the project. Oddly enough, they had trouble recruiting internal replacements once the turnover kicked in. Seriously, admitting upfront that it's out of control is already saying very little for one's management skills. If you ask, some- times staff will volunteer ways to help keep it from becoming a death march. In the death marches I've seen, the one thing that I've seen common to them all is a lack of empowerment among the staff. - Dave
  1. John Boddie, Crunch Mode (Englewood Cliffs, NJ: Yourdon Press/Prentice Hall, 1987), page 20.

  1. Scott Adams, The Dilbert Principle (New York: HarperBusiness, 1996), page 2.

  1. We'll discuss this idea in more detail in Chapter 4.

  1. It should be emphasized that while the dot-com startups are probably the most recent, and perhaps the most extravagant, examples of this phenomenon, they are by no means the only ones. The software industry has spawned startup companies since the 1960s, if not earlier, and it will continue spawning them as long as smart people have intriguing ideas for exploiting new technology.

  1. "X" used to be eight for many years, then it shrank to six. With the Enron/Worldcom scandals, the number seems to be shrinking steadily. Perhaps one day there will be only a "Big-One" accounting firm!

  1. Email from "Ought-Six," June 17, 2003.

  1. See my book, Byte Wars: the Impact of September 11 on Information Technology, for more discussion of this point.

  1. From: Kevin Huigens, 74762,2726
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158577, reply to #158015
    Date: Mon, Jun 10, 1996, 9:13:16 AM
    Ed:
    At our weekly staff meeting, my team and I had a brainstorming ses-
    sion on your 3 questions. Here's our answers:
    1. Why would anyone in his right mind agree to work on a "death 
    march" project (defined in the terms above)?
    Everybody wants to feel wanted Perceived opportunity
    Perceived money gain Can't afford to lose job
    Brought in from the outside to lead the project
    Willing suspension of disbelief
    Don't care whether project fails, get to work with cool technology
    On-the-job-training on new technology Eternal optimism
    Challenge Plain stupidity Chance to prove yourself
    To get the job done It's the only project
    Your friend is running the project Your brother is running the 
    project (It'd take more than friendship)
    Your boss said so You have no other life Nothing better to do
    Stock options Existing pay vs. expectation of raise Love is blind
    Resumé-building Ignorance Comeraderie
    Expectations for how long it will take are too low
    2. If a colleague of yours was about to take on the task of managing 
    a death march project, what is the ONE THING you would advise him/
    her to do?
    Leave me out Run! Keep your eyes open
    Ask "What's the pay?" Get a lot of rest before you start the 
    project 
    Make sure you can trust all of your co-workers
    Realize the developers aren't your enemy, the managers are
    Try to get management to understand the ramifications of the 
    project
    Communicate. Communicate. Communicate.
    Keep the team small Hire new graduates Keep the team intact
    Manage scope Review the design Focus is a substitute for time
    Make sure testing plan is ready when it's time to test
    Make sure you have a test plan Make sure everybody knows what to do
    Documentation is critical Don't rush to code
    Keep documentation updated and current
    Everyone should have access to documentation
    Have regular weekly progress meetings Have daily progress meetings
    All code works before you leave at the end of the day
    Keep plenty of good coffee on hand Make sure team is happy
    Make sure team has everything they need
    Use management by walking around
    Make sure everyone understands what they're doing
    3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such 
    a project?
    Don't plan a wedding Don't have unclear areas of responsibility
    Don't allow design changes lightly Don't assume 1st version is 
    final
    Don't become irritated or angry Don't lose your cool
    Don't let others lose their cool Don't forget to back stuff up
    Don't expect everyone on the team to be dedicated
    Don't get too personally involved in success or failure of the project
    Don't rely too heavily on 1 member of the team
    Don't allocate resources lightly
    Don't assume team members understand the entire project
    Don't overcommit Don't underestimate
    Don't refrain from asking questions when you don't understand
    Don't start the project
    Don't start the project if you haven't got the money to finish
    Don't commit to unreasonable dates
    Don't be afraid to quit if you feel management is unreasonable
    Don't be too hard on overworked, underpaid workers
    Don't let meetings last > 1.5 hours
    Don't be afraid to bend the rules
    Don't forget to have a life Don't sweat the small stuff
    Don't be afraid to let management know you need something
    Don't be afraid to stand up to management
    Don't forget to keep your resume updated
    Don't accept as gospel info from so-called experts
    Don't forget that management doesn't understand how to develop 
    software
    Don't forget that shortcuts just defer work, they don't eliminate 
    it
    Is that enough for you?
    Kevin
    
  1. From: Dave Kleist, 70730,1613
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158064, reply to #158015
    Date: Tue, Jun 4, 1996, 7:28:03 PM
    Ed,
    >> 1. Why would anyone in his right mind agree to work on a "death
    march" project (defined in the terms above)? <<
    Because it's rarely printed as part of the want ad. Not much sense 
    in saying, "Are you interested in working incredible hours for no
    additional benefit beyond your hiring salary? Does the idea of 
    working endlessly on obsolete technology while 'waiting' for a slot
    to open up on that exciting GUI/DSS/warehouse/HTML subproject 
    really entice you? Do you define three-tier architecture as an 
    opportunity to hear what other project members will work on without
    your help?"
    Seriously, death march projects are rarely billed as such, and it 
    takes a lot of work when being hired from the outside to discover
    if your hiring company is prone to creating death march projects.
    In addition, death march projects only look that way. While they 
    demand the hours, every hour is not productive. After a while, peo-
    ple find ways to do the things they being deprived of (pay bills, 
    run errands). It just isn't billed that way. The environment still
    sucks, people hate it.
    And, how accurate are those hours that are being billed? Where do 
    they come from? Got any contractors? Ever heard of "nuisance hours" 
    or "annoyance hours"? You know, where a contractor overbills 
    because they can't stand some of the people they are working for. 
    (Let me say right now that I've never done it and never will do it,
    but know people who have). The lead or manager does what the con-
    tractor thinks is stupid, and the contractor takes revenge (in 
    their own quiet way). And, what about overhead? Are all hours to be 
    marked to the project, including corporate and department meetings, 
    training, etc.?
    >> 2. If a colleague of yours was about to take on the task of man-
    aging a death march project, what is the ONE THING you would advise 
    him/her to do? <<
    Try to craft an exquisite exit clause in the contract <VBG>. Seri
    ously, one of the reasons for a runaway is the inability of someone 
    to hear reality, usually upper management (either side, IT or busi-
    ness). Someone taking over a death march has got to find an angle 
    for them to get some manuevering room (functionality, cost, time)
    in at least one aspect or they are doomed.
    >> 3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such 
    a project? <<
    Acknowledge that it is going to be a death-march. Doesn't sound
    honest but admitting that it's going to be a killer can be demoral-
    izing for two reasons: one, people don't like to hear that the next 
    6-12 months could be hell; two, management usually underestimates 
    the negatives. Not much hope if you know right out of the gate that 
    it's going to be ugly. I had friends who worked on one project that
    had management openly admitting that there was going to be road-
    kill on the project. Oddly enough, they had trouble recruiting 
    internal replacements once the turnover kicked in.
    Seriously, admitting upfront that it's out of control is already 
    saying very little for one's management skills. If you ask, some-
    times staff will volunteer ways to help keep it from becoming a 
    death march. In the death marches I've seen, the one thing that
    I've seen common to them all is a lack of empowerment among the
    staff.
    - Dave
    
  1. From: Steve Benting, 72410,477
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158362, reply to #158015
    Date: Fri, Jun 7, 1996, 12:59:21 AM
    Ed,
    As long as you're asking...
    >>1. Why would anyone in his right mind agree to work on a "death
    march" project (defined in the terms above)?<<
      Because it seems to be a well-thought-out project this time. 
    You've got someone leading who has a real sponsor in management, 
    the project plan appears to be solid, the people involved all 
    appear to be good. Hell, you *want* to work on this thing. Then it
    collapses because your sponsor gets taken out in a political strug-
    gle, the project plan turns out to be built on assumptions that are 
    incorrect, and one or two key people turn out to be flaky. You can
    learn to watch out for them, but sometimes you misjudge. And you
    don't want to believe that it's happening again. (I'm assuming some
    things here. I've only been involved on one large project, but it 
    certainly went down hard. Delivery date was October, '94 and later 
    moved to March '95. I was working on the contingency plan toward
    the end and left after most of the team in January '95. The new sys-
    tem still does not exist. The company is now in the process of pur-
    chasing someone else's system that doesn't have half of the
    functionality they originally required.) 
    >>2. If a colleague of yours was about to take on the task of man-
    aging a death-march project, what is the ONE THING you would advise
    him/her to do?<<
      I would say to take care of his/her people as much as possible. 
    Kick them all out of the office on Friday nights and try to make
    sure they're getting sleep. (Those months of 12-hour days six days 
    per week can just burn out the developers, making them either quit 
    or make too many mistakes.) No matter how badly the work needs to
    be done, you've got to take care of your people. Sometimes getting
    the most out of them requires sending them home. (If you know the 
    project's in trouble when you start, you've got a long haul ahead 
    during which you'll need good people.)
      Also, make sure that you've got the best salary scale possible. It
    won't make all the difference, but it should be cheaper than attri-
    tion if it's enough to keep some people on.
    >>3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such 
    a project?<<
      Don't let anyone put serious pressure on the employees besides 
    you. Run interference to keep the developers free from others who
    are trying to ask them to run that 2-minute mile. (We had a devel-
    oper working for us when I was the IS Manager -- and before the 
    aforementioned project was started -- who was writing a new commis-
    sions system. The Sales VP came down to tell her that until she 
    completed this system, her  -- the sales manager's -- salespeople 
    couldn't pay their mortgages. My VP quite rightly threw her out to 
    let the developer work in peace.) That's not to say that you can't
    push those employees yourself, but you have to have some control
    over the stress levels in the organization if you're going to keep 
    them going.
    >> I'd like to solicit input, feedback, war stories, case studies, good
    jokes, etc.<<
      This must be where I tell you about how, on that infamous project,
    the new President explained to me why he wouldn't sign off on 
    requirements when asked to. (Needless to say, scope creep was a
    major factor in its death.) He was a down-home type who thrived on 
    people taking his southern drawl as a sign that they were dealing 
    with a country bumpkin. He had also just orchestrated the removal 
    of our sponsor -- the previous President -- by killing the project. 
    His reason for the management group's refusal to sign off on
    requirements was that my VP was "going to hold our feet to the 
    fire" with that document. In other words, he wouldn't agree to sign 
    the document because he would have to live with it later! At this 
    time, I knew I really needed to get out of there, and quickly...
    Steve
    
  1. From: S. Marsh Roberts [ICCA], 70007,4251
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158111, reply to #158015
    Date: Wed, Jun 5, 1996, 5:31:15 AM
    Ed--
    >> 1. Why would anyone in his right mind agree to work on a "death
    march" project (defined in the terms above)? It's understandable 
    that an inexperienced software developer (or someone who hasn't had 
    the pleasure of reading Scott Adams' "The Dilbert Principle") might
    be bamboozled by management's claim that the death march is an 
    anomaly, and that the superhuman efforts are going to revolutionize
    the human race, defeat Communism, cure cancer, etc. But after 
    you've heard this pitch two or three times, it sounds like a broken
    record. So why do we get sucked into this again and again?<<
    The "heros" are needed, wanted, desired. They are certain of their
    place in history, if only they can keep this project from outright
    sinking under its own weight.
    The same people take on EMT work and enjoy firefighting (liter-
    ally). If you only win once in ten times, but everybody else lost
    all ten, wouldn't you be a hero, too?
    >>2. If a colleague of yours was about to take on the task of man-
    aging a death-march project, what is the ONE THING you would advise
    him/her to do? (The "one thing" motif was suggested by Jack Palance 
    in the wonderful movie "City Slicker", starring Billy Crystal)<<
    I'd encourage him to keep his sense of humor. It may be gallows
    humor, but it's all that such a group has. <sigh>
    >>3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such 
    a project? <<
    I would encourage him (and excuse me, it would be a him in 99/100
    attempts) to not invest in options or get a large mortgage. You can
    only take high risk in one arena at a time, without risking a total
    wipeout of personal assets.
    I once said that I would be willing to take a certain job whose
    incumbent tended over a seven year period to last no longer than a
    year. I figured that three months' salary would provide enough sav-
    ings to recover from the inevitable.
    Sharon
    
  1. From: Paul Neuhardt, 71673,454
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158349, reply to #158015
    Date: Fri, Jun 7, 1996, 12:20:19 AM
    Ed,
    << 1. Why would anyone in his right mind agree to work on a "death
    march" project (defined in the terms above)? >>
    For me, it was ego, pure and simple. They told me that they just 
    KNEW I could help prevent the project from becoming a death march. 
    I was made the "technical project manager," given ego boosts on a
    regualr basis, then hung out to dry along with the rest of the 
    team. Left, right, left, right, left, PLOP!
    (The really embarassing thing is, I let these same people do it to
    me AGAIN just one year later. Once I began to feel myself falling
    into the step of the death march, I ran like hell for the door. Me, 
    and about 60% of the rest of the staff. BTW, It's been four years
    now since I first got suckered in, and neither system has ever seen
    the light of day, nor will they.)
    << 2. If a colleague of yours was about to take on the task of man-
    aging a death march project, what is the ONE THING you would advise 
    him/her to do? >>
    To quote those mad englishmen in "Monty Python and The Holy Grail"
    I would say "RUN AWAAAAAYYYYYY!!!". It sounds like a flip answer,
    but it isn't really. Some of the most damaging effects of a death 
    march project are psychological. Lower self esteem, depression,
    anxiety and sudden mood swings are all behaviors I have witnessed 
    (and sometimes experienced) during these projects. I've seen at 
    least one marriage break up in no small part because the partner
    involved in a death march let it consume her so totally that she
    bacame an entirely different person, one whom her husband (and most 
    of the rest of us) had no desire to be around. I know another woman 
    who, when a three year "death march" ended with the project being 
    cancelled, said that it was the only experience in her life that
    even approached the heartbreak she felt when she miscarried during
    the sixth month of pregnancy. Now that's trauma. If you can get 
    out, go.
    << 3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such
    a project? >>
    If you can't beat 'em, this is one case where you do NOT want to
    join 'em. Do not let yourself become too emotionally attached to 
    the outcome of this project. Like POWs on death marches, think 
    about anything else but the march in order to survive. Try to go to
    work, grind out your day's brick for the wall, and go home. If you 
    want stimulation and personal reward, read a book, join a social 
    club, volunteer at the local animal shelter or buy a kiln and throw
    some clay pots. Do anything to keep your mind off of work as much 
    as possible. The moment you get to attached to the project, the guards 
    with the rifles win and you, the lowly POW, lose.
    Paul
    
  1. From: Al Christians, 74031,316
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158029, reply to #158015
    Date: Tue, Jun 4, 1996, 12:04:05 PM
    Ed
    Sounds like you are going to have a lot of fun this summer.
    1. Why would anyone in his right mind agree to work on a "death 
    march" project?
    Since you mentioned "City Slickers", the movie that used such
    regrettable sexual stereotypes, I am somehow prompted to reply 
    "testosterone", which is about the same as "because it's there." 
    There are plenty of jobs that raise the 'why?' question. Under-
    ground mining, cowboying, logging, smoke jumping, jet fighting,
    submarining, even high-rise window washing all have serious draw-
    backs far beyond what you describe for software projects, and yet 
    all these have practitioners whose sense of self is linked to their
    profession.
    But if you really think that reasons are needed, here are a few:
     a. We think we learned so much in the last experience that it would
    be a waste to not find a project on which it could be applied.
     b. We know that some of our colleagues are going to be suffering, 
    and we don't mind doing our part to lessen their burden.
     c. It's like a lottery ticket -- despite the odds, we can imagine 
    the possibility of large rewards if we win big.
     d. The high level of urgency that arises during these difficult
    projects redistributes power to those who know how to resolve the
    crises, i.e., us, and we like power.
    > 2. If a colleague of yours was about to take on the task of man-
    aging a death march project, what is the ONE THING you would advise 
    him/her to do?
    Remember that the people who love him/her, love him/her for reasons
    that have nothing to do with the project.
    > 3. Conversely: what is the ONE THING you would advise your col-
    league NOT to do, under any circumstances, when embarking upon such 
    a project?
    Since "this is the way it's been for a long time, and this is the 
    way it's gonna continue to be," don't try to work at a pace that you 
    can't sustain healthfully for a long time.
    Al
    
  1. From: David Maxwell, 100342,3620
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158991, reply to #158015
    Date: Mon, Jun 17, 1996, 4:53:16 AM
    Ed
    As I talked on another thread the other day, projects are like a 
    marriage. We tend to start of naiively and full of hopes and slowly
    as reality sets in, we have to reassess our expectancies within the 
    relationship. There are many reasons apart from *logic* that 
    attract people together into a marriage and it is the same case
    with projects. With a predominantly youthful workforce, it is 
    likely that the "death-march" project will occur again and again as
    a training ground for managers and developers alike. And, as I know 
    from personal experience, I often repeat the same mistake many 
    times before the penny drops.
    Niezche, the German philosopher in the last century said that 
    "society is governed by mediocrity". What he was presumably imply
    ing here is the central, conservative-stream will tend to dominate
    behaviour and control events. This central-stream is hell-bent 
    on preservation from the extremes and will draw the blinds on anything
    that threatens their positions. What we are really asking for in IT
    is a radical re-shaping of the way projects are managed, with open 
    vertical and horizontal communication.. and an openness to radical-
    ism. This is very threatening for the central core of the typical
    task, role, club organisational culture. An Organisation with a
    cuture of existentialism has a much better chance of developing
    good projest on a regular basis but these Organisations are still a 
    rarity.
    An old girl-friend of mine who is in a leading position in one of 
    the Major Business Schools regularly seeks advice from me as to how 
    to overcome the deluge of internal politics and methods that are 
    stifling their practices, certainly a case of not practicing what 
    they preach! In addition, Computer Science departments the world
    over are paying scant regard to People and Management issues as the 
    Lecturers themselves are, in general, inept outside of the techno-
    logical framework.
    So perhaps it is inevitable that, with an inappropriate education
    and cultural backdrop, we can expect "death march" projects to con-
    tinue to be the norm... But looking at it from another perspective, 
    these "death march" projects are the essential grist-for-the-mill 
    for the few success stories that make the whole show worthwhile.
    David
    
  1. This scenario is far more common in North America than it is in Western Europe or the Pacific Rim countries that I've visited. While companies all around the world have engaged in re-engineering projects, it's less common, outside North America, to see the "radical" re-engineering projects that eliminate large numbers of employees. And for the same reasons—cultural traditions, social policies, government regulations— there are fewer death march projects in these countries. The work force, especially in Western Europe, is far more likely to be shielded from excessive overtime, and is far more likely to adamantly refuse to give up sick days, vacation days, holidays, personal days, and other forms of time off. Whether this is a good thing or a bad thing is outside the scope of this book.

  1. Erik Petersen email, June 20, 2003.

  1. From: Rick Zahniser (SL), 70313,1325
    To: Ed Yourdon, 71250,2322
    Topic: Ed's new book project
    Msg #158437, reply to #158015
    Date: Fri, Jun 7, 1996, 10:57:25 PM
    Ed,
    >>why do they do it??<<
    I think they do it because, as Al, suggests, they think they're 
    better than others who have tried. And, sometimes they really are!
    (That doesn't eliminate the death march. In fact, it probably pro-
    longs it.) 
    I've told you before, I think everyone should be on at least one of
    these projects. However, there are some other things that you 
    should do at least once:
     + Spend a night in jail.
     + Get commode-hugging drunk
     + Raise a boy
     + Raise a girl
     + Start your own business
     + Climb Mount Fuji
    (The Japanese have a saying:
    "He who fails to climb Fuji-san is a fool. He who climbs Fuji-san 
    twice is an even greater fool.")
    One thing to do:
    Get a good manager, who is empowered to do the right things.
    One thing not to do:
    Kill yourself when the project goes south.
    Sr. ric
    
  1. Science fiction aficionados will recognize the similarity between Zahniser's advice and the wonderful aphorism from Robert Heinlein in Time Enough for Love: the Lives of Lazarus Long (Ace Books, re-issue edition, 1994): "A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects."

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020