SQL Server execution plan is using PK instead of index

SQL Server might be able to use the second index if you add CreateDate to the include list (and Process_Id to the key), but between the join conditions and the fact that your primary filter criteria is the 7th column in the key (why is the first column ProjectType_Id?), it's still going to perform a scan of that index, and it would only be chosen if the table (represented by the clustered index) is a lot wider than this (we can't tell how many other columns are in the table but not mentioned in the query). The first index is not suitable because, while it could be used to locate the rows for the where clause, it does not contain Unit_Id, which is necessary for the first outer join. SQL Server determines that it's cheaper to scan the clustered index than to seek on the skinny index and perform lookups for every single row to obtain the other necessary data to satisfy the query.

So, you might try dropping both indexes, and creating this index instead (this is just a first stab):

 CREATE NONCLUSTERED INDEX [IX_Project_02a] ON [dbo].[Project]
  (
    [Company_Id], -- made this the leading key column
    [Unit_Id],  -- moved this up to help facilitate the first join
    [Process_Id]  -- added this to help facilitate the second join

    -- removed several columns here
       -- they are not necessary for this query, and if they are
       -- necessary for other queries, may be better as INCLUDE
  )
  INCLUDE
  (
    [CalculateSequencialProject],
    [ProjectStatus], -- for this query, does not need to be in the key
    [CreateDate],
    [OpeningDate],
    [ForecastClosingDate],
    [RealClosingDate]
  );

(Note that the second index may actually be useful for other queries, so check index_usage_stats, don't just drop it because I said so. The first index, on just Company_Id, is highly unlikely to be useful for any queries.)

A hash match is generally suboptimal; it means that the inputs are not sorted. Better indexes can usually eliminate those.

The following query is taking 5 seconds to return 9692 rows

It shouldn't take that long. You must be using an underpowered (or cloud) server. If you had run the query from within Plan Explorer, it would have included I/O metrics and other useful performance information.

however this table have more than 15 indexes that don't reference it.

This is a red flag that your table may be too wide, and/or that your indexing strategy is not well-planned. Try to normalize your table design and give proper thought to your indexes. You should fix the spelling errors like DescriptionTittle and CalculateSequencialProject while you're at it.

It is using the PK instead of my indexes. Why?

Because there is no index with Company_Id as the leading key that can also provide the other columns needed in the query.

Every JOIN is causing a Hash Match, is that ok? I mean considering that the final query will have more than 10 JOINs.

With the tiny number of rows in your tables at the moment, yes. It is probably optimal. The cause of the slow performance is almost certainly elsewhere - probably a hardware issue.

Writing a query with 10 joins is often a sign of trying to do too much in one query. Instead of writing one monster query (which you will have endless trouble optimizing), break the query into manageable blocks, and use temporary tables (indexed if necessary) to hold small intermediate results.

You will get better quality execution plans, and more predictable performance this way. Your final queries will likely be comprehensible by mere humans as an additional benefit. Maintaining queries usually represents more of the lifetime cost of a database than the initial implementation, so writing simpler queries usually pays off in the long run.

Other Observations

You appear to be using uniqueidentifier as the type for your Id columns. This often indicates a lack of understanding of the tool you're using (Entity Framework?) and what data types make good primary keys.

Your tables contain very few rows. If you intend to scale this, you need to develop and test with a representative data volume and value distribution.

You should get into the habit of prefixing your table references with the schema prefix, perhaps it is dbo.Process, for example.

You should also get into the habit of using aliases for your object references e.g. dbo.Project AS P.

If you really want to test the performance of hash joins versus lookups, you may, for testing purposes, put a WITH (FORCESEEK) hint on the table references in your query.

Ultimately, I am suggesting you employ a decent DBA to assist you at this stage.