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

Do you find yourself having to clarify project tasks assignments sent out to resources when you published your Project schedules? Do you spend unnecessary time clearing up confusion or even conflict around task assignments to teams?

Here is the first in a series of best practices tips for project managers working in the Microsoft Office Project Server EPM environment.

Task Management Tip #1: Assign as few resources as possible to each task.

Ask yourself, “If I assign a task to two people, who is responsible for it?”

Consider this common scenario:

Suppose you assign a task to two resources, Peter and John. Monday rolls around and it appears from the updates waiting for you from Friday that neither Peter nor John have updated the shared task. You will likely call or e-mail both of them to remind them to update the shared task. John responds Monday afternoon, stating that he is waiting for Peter to do his part first, to let him know that he can do his. You hear from Peter on Tuesday morning that he thought John was going to do his part first.  By Tuesday afternoon you finally get Peter and John on a call and work out the division of labor, but not without some refereeing and defensiveness about the confusion.  By late Tuesday of the week after the task was to scheduled to start, you have Peter working on the task, while John is waiting, more tension on your project team, and having wasted your time and Peter and John’s time on at least six e-mail exchanges, a few phone calls, and frustration, and perhaps some interpersonal conflict, on your team because of poor communications.

In reality, assigning multiple resources to a single task can lead to confusion and delays, and can make accountability more difficult to manage.

In addition to these universal issues of delegation, assigning a task to multiple people has further risks in the Project Server environment:

1. Task updating is more complex.
2. Resource leveling is also more complex.
3. Tracking can be more complex, too. One slacking resource can negatively impact the Earned Value metrics for other on-time resources assigned to the same task.

When two or more resources update a task in Microsoft Office Project Server (through Project Web Access), a number of potential issues come into play. Each resource is supposed to enter the time they worked on the task. If the task is complete, but they have not worked as many hours as were estimated, they will need to enter either ‘0’ hours remaining or mark the task complete.

Issue 1: Share tasks usually take more time to manage: If the multiple resources do not confer (spend additional time on communications to manage a task), how will they know if the task is complete?

Issue 2: Updating shared tasks is more complex: If the multiple resources do not confer, but one of the resources marks the task ‘complete’, the other resources will not be able to log their time against that task.

Issue 3: Undoing ‘done’ tasks requires extra steps: If resources enter as many hours as were estimated for a task, but the task is not really complete, PWA will automatically mark that task complete, because they have worked the estimated amount of hours. (This is great if the task was complete; but an extra, sometimes overlooked step if the task is still incomplete.) Resources need to enter the estimated hours of work remaining at the time of their updates or PWA will automatically calculate and status the task based on the original estimate. If this happens and someone detects it, it will require more (wasted) time and steps to change the task back to an incomplete state.

Assigning each task to just one resource, you make your life and job as a project manager much easier.

• Updating tasks will be more efficient for you and your project team members.
• You avoid wasting time resolving confusion and conflicts.
• You are able to hold resources accountable for their work and updates without unnecessary cycles of discussion, defensiveness, and conflict.
• You protect responsive resources from getting dinged for laggards’ irresponsibility.

By breaking tasks down to the ‘work package’ level, to the point that you can assign them to a single resource you will keep things simpler for resources updating their tasks in PWA.  Your reporting will likely reflect reality more closely, and you will not have to chase down resources to qualify or confirm their updates. (Well, not as much anyhow.)

Do yourself and your project teams a favor, and make your life and projects easier to manage. Learn to apply . . .

Task Management Tip #1: Assign as few resources as possible to each task.

Posted By: Kevin Williamson

The top soft skill for a Project Manager has to be communication. Without efficient communication, your project will suffer. Your relationship with your team, stakeholders and sponsors is critical to the project’s success. If poor communication tarnishes these relationships, you are putting your project at risk for success.

Have you ever wondered why the same statement resonates differently between two people? One tool that may help to understand these differences is being able to identify personality preference types.

One approach is based on a personality typology developed by Carl Jung. He identified three aspects of one’s personality. This typology was further developed into four aspects by Isabel Myers-Briggs. These personality profiles are:

Of course no type of categorization is 100% one way or the other all the time. But by being aware of the differences of how people obtain information, and process information, communication can be tailored to be more effective. And by observing people and how they communicate, you can begin to identify where they may fall within these preferences.  For example, if you notice someone speaking with more concrete facts, they probably have a preference for Sensing and you know that they will understand things better if they are presented in a linear and detailed fashion. If someone is quiet and contemplative, they most likely have a preference for being Introverted and you can adjust and not expect a quick reaction as they will need some time to think about what you said and process internally.

The flip side of observing the possible preferences of others is that you must be aware of your own communication style and preferences. And as a Project Manager, you must develop the skills necessary to modify your communication style to bring out the best in your team and ensure success…. on a team level and for the entire project.

If you are interested in seeing where you may score along these personality preferences, you can take a free online test at: www.humanmetrics.com and choose the Jung Typology Test. It will be very enlightening!

Posted By: Lynn Jesus-Olhausen