One way I know is to use OPTION(MAXDOP 1).

It Sets the maximum number of processors the query processor can use to execute a single index statement. Fewer processors may be used depending on the current system workload.

check out See Rickie Lee's blog on parallelism and CXPACKET wait type.

code example :

SELECT *
FROM test t,
WHERE t.CourseID= 5
ORDER BY t.LessonWeekDay
option (MAXDOP 1)

The problem could be in table statistics.
is statistics is not good enough maxdop 1 will not help

strategy 1:
the first and foremost is to keep an eye on result size of the recordset SP returns.
No matter, whatever the result size, user wants to see the max of 50 records or 100 (pagesize) and user does have a dislikeness towards scroll down.
So Always, restrict your recordsize with pagination handled at server level.
again, there are multiple approaches are there but best option is "keyseeks" approach.
google for the keyseeks method.

strategy 2:
table might be locked continuously for inserts/updates (typical scenario in OLTP).
In this case, I recommend following strategy:
add a datetime column "rec_lockout_till" and add a default value of "getdate()+ 5 minutes"

and all queries should refer to

select * from table with (nolock)
where rec_lockout_till < = getdate()

logically, mutually exclusive coz, while inserting, you are forwarding the time ahead of 5 min. and while retrieval, backwarding the condition.

ex:
current time is: 3.34pm:
so
for all inserts happening at present, rec_lockout_till will be 3: 39pm
and
for retrieval,
we are interested in
rec_lockout_till < =3:34 pm

with (nolock) allows the dirty reads where as rec_lockout_till < =3:34 pm condition nullifies the effect of dirty reads.
over all, you get the performance benefits of with(nolock).