In my previous discussion about enterprise project management in “dynamic environments”, I identified dynamic environments as organizations that:
Operate in highly competitive markets
Build and maintain market share via regular new product introduction
Must respond to rapidly evolving requirements
Optimize their product portfolio via product platforms that can be leveraged for individual customers or markets
Are constrained by time, money and skilled resources
I stipulated that project delivery teams (and not just project managers / the PMO) should be held accountable for project planning and execution responsibilities to ensure that project schedules and status accurately reflect the “situation on the ground”. Let's dig a little deeper into enterprise project management, focusing on the need for team members to prioritize and select the tasks they are going to start working on in the present time and communicate those decisions back to the project manager /schedule coordinator.
Of course, this process begins when the project manager/schedule coordinator assigns dates and team members to the project tasks. With this information, team members have visibility into what they could be working on days, weeks or months at any future point in time. With enterprise project management and execution, the degree to which these scheduling predictions come true depends on many factors, but most project schedules need to be updated regularly to provide highly reliable dates for tasks that should be executed in the present time. But even the most ardent project managers / coordinators can’t be 100% accurate in the scheduling of present-time tasks and hence there are situations when the team member (a) may not commence work on a task as scheduled (b) must work on an unscheduled activity, or (c) must start work on a task before its start date. As a result, team members are often making micro-planning decisions with respect to which tasks to actually work on in the present time. And the more inaccurate the schedules are with respect to tasks in the present time period, the team members will have to make that many more decisions of which tasks to work on.
For most organizations with enterprise project management, it is unrealistic to expect or demand that all project plans have 100% or even 90% accurate task dates. That approach can quickly overload the person responsible for maintaining the project plan and the effort quickly reaches a point of diminishing returns rendering it counterproductive. I don’t think there is a steadfast rule that can be applied – for some tasks 100% accuracy must occur and it can be much less for others depending on the situation. It is also unrealistic for most organizations to allow team members to reschedule the tasks (i.e. change the task start and finish dates in the project plan). If they were, the team members would be acting, to some degree, as project managers/schedule coordinators and that would just create more confusion in the near and long term as there would be so many changes being made to the schedules it would be render them useless.
I believe a balanced approach with enterprise project management can be realized by:
providing team members visibility into the overall schedule, especially project and program milestones
giving team members visibility to all tasks to which they are assigned as soon as that information is available, even if it is highly probable the task dates may change
providing team members visibility into upstream and downstream task dependencies so they can see who/what they will be waiting on and who/what will be waiting on them
providing a mechanism by which team members can select any scheduled tasks and drop them into a personalized “WIP” bucket in which they can prioritize and sequence (but not schedule) the tasks
providing an efficient mechanism by which they can communicate to the project manager / schedule coordinator forecasted start or finish dates for the tasks
providing an efficient mechanism by which the project managers / schedule coordinators can either accept or reject the forecasted dates and efficiently communicate their decisions back to the team members
(There may be some readers of this blog who believe they are exempt from this situation because they are following an Agile process. But Agile projects are not completely “plan date free" and there are times when tasks aren’t ready for the team members to start working on and the team member must decide to work on something else. I do believe that Agile projects are better equipped to self-correct the plan.)