You should analyze all the differences in behavior from the departments in order to make the correct architectural decision. The simplest case is the one in which you make only a single product (a single bounded context, i.e. TaskManagement) that is used by all departments.
From what I understand so far, the differences are only related to the authorization: some departments may assign tasks only to some users, other departments may assign tasks to all users and so on. This can be extracted in a separate module that corresponds to a separate bounded context: Authorization. This means that the TaskManagement bounded context is not affected by these differences, a task has the same behavior for all departments.
The Authorization is largely debated on books/the internet, but as a little implementation suggestion, you could make the calls to the Authorization bounded context in the Application layer, before the calls to the Aggregates from the TaskManagement bounded context; the UI also uses the Authorization bounded context, in order to load the corresponding user list when a task is assigned.
TaskManagement is a bounded context that can permit off-the-shelf solutions. For example, Jira is used by a lot of companies and by all departments from those companies. In the "worst" case scenario, you can have different instances of the TaskManagement application for each department, with a different database, but with the same source code.