Tests are valuable. At the very least, they record that somebody considered that they should spend time writing them, so presumably they had some value to somebody once. With luck, they will contain a complete record of all the features and bugs that the team has ever worked on – though they may also just have been a way to hit some arbitrary test coverage number without being carefully thought through. Until you look at them, you won't know which is the case here.
If most of your tests pass most of the time, then just bite the bullet and invest the time in figuring out what the few tests that fail were trying to do, and either fixing or improving them so that the job will be easier next time. In that case, skip forward to the Determine the intent for each test section, for some advice on what to do with a small number of failing tests.
On the other hand, you may be faced with a Red build now, and hundreds or even thousands of tests which haven't passed for a while, and Jenkins hasn't been Green for a long time. At this point, the Jenkins build status has become useless, and a key indicator of problems with your check-in is no longer working. You need to fix this, but can't afford to stop all forward progress while you tidy up the mess in your living room.
In order to keep your sanity while performing the required archaeology to determine what value can be recovered from the tests which have been failing, I'd recommend the following steps:
Temporarily disable the failing tests.
There are several ways you could do this, depending on your environment, which you don't clearly describe so I can't really recommend any particular one.
Some frameworks support the notion of expected failures. If yours does, then this is great, as you'll see a countdown of how many tests are left in this category, and you'll even be informed if some of them start passing unexpectedly.
Some frameworks support test groups, and allow you to tell Hudson only to run some of the tests, or to skip a group of the tests. This means you can occasionally run the test group manually to see if any are now passing.
Some frameworks allow you to annotate or otherwise mark single tests to be Ignored. It is harder to run them as a group in this case, but it stops them from distracting you.
You might move the tests to a source tree that isn't normally included in the build.
In extremis, you could delete the code from the HEAD of the version control system, but this will then make it harder to recognise when the third phase has been completed.
The goal is to get Jenkins to go Green as soon as possible, so you can start moving in the right direction as soon as possible.
Keep tests relevant.
Resolve to add new tests as you add or modify code, and commit to keeping all the passing tests passing.
Tests may fail for a variety of reasons, including the fact that they weren't well-written tests to start with. But once you get Jenkins green, keeping it that way is really important.
Get used to writing good tests, and make it a big deal if tests start failing.
Determine the intent for each test.
Go through the disabled tests one by one. Start with the ones that affect the modules that you change most frequently. Determine the intent of the test, and the reason for failure.
Does it test a feature that was removed from the code base on purpose? Then you can probably delete it.
Is it catching a bug that nobody has noticed yet? Reinstate the test and fix the bug.
Is it failing because it was making unwarranted assumptions (e.g. assuming button text would always be in English, but now you have localised your application for multiple languages)? Then figure out how to make the test focus on a single thing, and isolate it from unrelated changes as best you can.
Does the test sprawl through the whole application, and represent a System test? Then remove it from your main Jenkins test suite and add it to the Regression suite that runs less frequently.
Has the architecture of the app changed beyond recognition, so the test no longer does anything useful? Delete it.
Was the test added to artificially increase code coverage statistics, but actually does nothing more than confirm that the code compiles correctly and doesn't go into an infinite loop? Or else, the test simply confirms that your selected mocking framework returns the results you just told it to? Delete it.
As a result of this, some tests will stand, some be modified, some split into multiple independent, bite-size chunks, and some removed. As long as you are still making progress with new requirements, setting aside a little time to deal with technical debt like this is the responsible thing to do.