Best practices in writing task names for PWA users
The second in a series of best practices tips for project managers working in the Microsoft Office Project Server EPM environment.
By Kevin Williamson, Senior Portfolio Advisor, Advisicon
Do you find yourself having to clarify project tasks sent out to resources after you publish a Project schedule? Do you spend unnecessary time clearing up confusion around resources assignments?
One of the biggest timewasters in a project is having to clarify task assignments.
From your experience, rank the actions (below) by which one the majority of your project resources will choose if they do not understand a task assignment notification they receive by e-mail?
A. Do nothing until you check with them to see if they have started the task. (‘Passive’ Response)
B. Do nothing, but complain to others that they don’t understand your task assignments. (‘Passive Aggressive’ Response)
C. Start working anyhow and assume all of the risks associated with working without clarity. (‘Half-cocked’ Response)
D. Try to figure out what your assignment means, drill into the task details, then call the project manager . (‘Independent’ Response)
E. Call or e-mail the project manager to ask for clarification. (‘Direct’ Response)
We have probably experienced all of these responses. Personally, I prefer ‘E’. But no matter how you rank the responses or how your project resources tend to respond to unclear task assignments, every response requires more time than you likely built into your project schedule.
Main Point: Resources need to understand a task assignment before they can start working on it effectively.
The My Tasks page and My Assignments view in PWA do not at first glance reveal the larger project context for a given task assignment.
To see the task in the context of its project task path, Work and Remaining Work, Related Assignments, or task Notes, a resource will need to click on the Task Name to drill down to the Assignment Detail view (see screen shot below).
For those exceptional resources that choose D. above and try to figure out assignments on their own before they call you, a lot can be learned from the Assignment Detail view. If they are very resourceful, they can also communicate with other resources who are assigned to related tasks in the Related Assignments section by hovering over the resource name under the Assigned To column, click on the circle, which opens a menu of options (see below):
A resource can select to Send Mail to coordinate directly with other resources (or select from the other options). Unfortunately, the Send Mail option does not automatically reference the subject or insert any reference to the project or task context of the communication.
In general, though, you and your resources are better off if the task assignment is clear to begin with.
Task Management Best Practice #2: Write task names as verb phrases.
To save yourself the hassles of project management communications delays because project resources do not understand project task assignment descriptions, follow these simple steps:
Step 1: Tasks are things to do. The best way to describe a task is with a verb phrase. Complete the Task Name field for each task with a verb phrase that accurately describes the action you want each resource to complete.
Example: Elicit, document, validate, and verify user stakeholder class representatives’ requirements.
Step 2: Ask yourself: Will this Task Name (verb phrase) communicate clearly what this particular resource needs to do based on this Task Name alone, or do I need to give them more detailed instructions?
If the task is more involved than a single verb phrase can sufficiently describe, use the Notes field to describe the task in more detail. The level of detail you use in task notes will depend on your working history with each resource, their knowledge, and whether you are confident that the resource will understand exactly what you need them to do or not. If not, use the Notes field for that task:
Example of using Notes field to specify task directions:
1. Review business case and project initiation request.
2. Review technical specifications.
3. Choose elicitation technique that has worked best with this user class stakeholder requirements in the past – ask previous project managers or look at previous project documentation.
4. Prepare elicitation documentation.
5. Elicit and document user stakeholder class representatives’ requirements.
6. Review requirement documentation for completeness and accuracy.
7. Map user requirements to business case requirements and technical requirements to ensure they correspond.
8. Analyze user requirements for internal consistency.
9. Analyze user requirements for feasibility within project schedule, cost, and resource requirements/constraints.
10. Review user class stakeholder requirements documentation with user stakeholder class representative to verify.
11. Have user stakeholder class representatives sign off authorization of requirement documentation.
12. Send verified user class stakeholder requirements documentation to Project Manager.
Step 3: Ask yourself, “Would it be more time-efficient to review this task with the resource in person or by phone than just depend on how PWA presents a task?” There may be a lot of factors that you weigh in answering this question, but, ultimately, you will want to err on the side of clarity to avoid unnecessary delays due to confusion.
Posted By: Kevin Williamson