Executing Tasks with Enterprise Project Management

By MHomrich

Enterprise project management is about more than just planning your projects. It’s about effectively executing them. We recently started talking more about PLM process execution, including enterprise program and project management solutions and product change management. You may have seen my colleague’s recent discussion around different approaches companies might take to product development process management. I’d like to continue this discussion, focusing more on the prioritization and execution of tasks in a project.

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.)

What do you think?

Leave a Reply

This article first appeared on the Siemens Digital Industries Software blog at