I assume, you were assigned to jump into the cold waters of maintaining an existing project?

I would start to find answers to the following questions:

• Who has maintained the code before? Is (s)he available for a walk through/introduction?
• Where is the documentation? Does it exist anyhow? Is it up-to-date?
• Where are the sources? Are they version controlled (e.g. learn from commit statements)?
• Where are the tests? Studying them might give some insight...
• Are there other tools (editors, xref, etc.) that can aid?
• Where is the test- or staging-system (to experiment w/o endangering production)?
• What is your boss' concrete expectation? (your task description)? Derive a small feasible but concrete task to start fiddeling with the code base.
• ...

Finally, for some people the learning by osmosis principle works. Skim through the sources, skim again, take notes while doing so. Finally, you'll have a mental map where to find something and how the pieces are connected to each other. Write new tests if you miss something or want to understand certain aspects. Experiment, but be sure you can undo your changes (e.g. version control).

HTH

Update: Additional PM resources:

• Becoming familiar with a too-big codebase?
• project structure / class browser for Perl?
• Analyzing large Perl code base.
• Code struct map building?

I am not aware of a book that covers the topic of assessing an existing project. Maybe McConnell / Code Complete, Martin / Working Effectively with Legacy Code, or Fowler / Refactoring: Improving the Design of Existing Code might have some helpful sections about it? Conway / Perl Best Practices might help you help the next generation (people that take over from you).
(in response to 919191)