PoddarCo

There have been quite a few comments on this post in different linked-in groups. Everyone may benefit from a consolidated exchange of ideas. So will post some of those comments here soon…stay tuned.

I guess one critical factor is missing. SIZE of the project must be considered before deciding whether to manage by Deliverable/ Milestone base or Task base. For an example project team more than 15 members (I just suggest) cannot be managed by deliverables because there can be so many inter-dependencies between tasks.

I absolutely agree that the result is paramount to the process. Once you have a desired result you should not care how the team has got there. However, seeing the tasks you can infer on the level of risk related to the path chosen by the team, so you can adjust the plans as to minimize the risks. In this respect, at least careful planning the tasks makes perfect sense.

Fast Forward Project Management is an approach to project management based on Goal Directed Project Management (GDPM) and is very much focused on the ‘What’ rather than the ‘How’.

Team collaboration at the initiation stage with the sponsor to define the scope, goals and objectives and developing a plan is something we have been doing for years with success! After all it’s the ‘What’ that the sponsor wants; the ‘How’ may change but if the correct amount of effort is applied at the front end in defining the ‘What’ that really shouldn’t change!

I think Adrian is right about the initiation stage and how critical it is. But I hear what you’re saying about the team being more independent – you don’t want to micromanage your team. And that’s good, but what if your project has a high level of tasks – if they aren’t managed well by your team, your deliverable could well be delayed. Your milestones would not be met. And if the PM isn’t keeping track of the tasks, the PM could be lost.

Laura Bamberg
Steelray Software
http://www.steelray.com

Copying a comment made by Brenda on a linked in post…
“Interesting. Have you ever managed by business case?”

Varun – I agree. Managing tasks instead of deliverables/milestones leaves a project manager vulnerable to being pulled into a level of detail that’s best left to subject matter experts and functional managers. Managing to deliverables and milestones forces a project manager to ‘steer the project ship’ so to speak, instead of getting bogged down in the engine room. Brenda’s point is so important as well. If the deliverables and milestones don’t support the business case, the project ‘ship’ may arrive on time with the correct cargo…but at the wrong port.

By Jennifer Katus Owner, Promomento

Quoting a comment from Leon Velazquez, PMP Project Manager at Alestra, made in one of the linked in groups –

Recently I switched to managing by deliverables and it has definetly improved the level of control, prioritization and focusing on the urgent and important. It’s easier to identify the critical path even though you have little or no detailed information.

An added benefit of managing by deliverables/milestones: I found most project sponsors and other managers who receive status reports are much more interested in the status of deliverables/milestones than they are on the status of tasks.

By Jennifer Katus Owner, Promomento

Quoting Asanga from a comment made on linked-in:
Interesting topic and I am trying to understand some basics here if you don’t mind clearing it out for me. What do you mean when you say “managing by deliverable/milestones” because wouldn’t you still have to track the task for that deliverable. Example project to build a wood box has tasks such as Order wood, prepare wood, cut into sizes, make side panels, assemble, final product. If you consider each task is done by separate group one can say deliverable of each group is that task it self? I do understand the reporting benefit that its easier for higher management to understand when its managed by deliverables.

Thanks for weighing in everyone. I think as PMs, we incorporate bits and pieces of all approaches suggested here in forming our own individual style. As Brenda and Jennifer mentioned, it is imperative that the project effort be tied to the business goals, otherwise what’s the point of that effort? Richard’s point about Situational Leadership is also something many of us do in managing different personalities, varying project demands or even diverse teams (development vs. researchers vs. sales, or onsite vs. remote vs. cross cultural teams). So a mix to suit your style and needs would probably work best.

Also as Asanga, Vladimir, Adrian and Laura highlighted, regardless of how one manages the project, one should still track all tasks for the deliverables. So, to that end, what I was suggesting in the post seems more focused on the execution phase. I don’t mean to suggest managing by deliverables/milestones in lieu of delving into the details. Identifying the detailed tasks and dependencies is important for scheduling, estimating/forecasting and identifying risks (among other things). Just didn’t get a chance to qualify that in trying to contain the blog post length, but it’s probably important to state.

Thanks for a stimulating exchange of ideas…look forward to many more…!
Regards
Varun

I don’t know if its a real choice – think as a true manager you owe it your bosses/clients to deliver (and hence manage by deliverables) and as a leader you owe it to your teams to resolve issues in the process of delivery (and hence manage by tasks).

In my job (as a management consultant), we manage relatively “simple” deliverables (i.e., we are usually not “building” anything except insights “delivered” on paper). However, these are built in relatively resource impoverished environments (always very short of time, information/ data, flexibility etc.) under relatively high stress situations. Not having a balanced management style in such situations will invariably lead to either your clients/bosses being dissatisfied or your teams feeling abandoned – neither of which are acceptable if you want to be able to sustainably deliver quality solutions. Have also found that this is been true for me in high-tech, pharma, financial services, utilities, retail and consumer goods – feel like it has to do with the dynamics of human interaction more than any sectoral biases.

As someone who “grew up” as a manager in the glory days of Hewlett Packard (30 years ago) I believe MBO (Management by Objective) is the most powerful tool any manager can use. However one key aspect of MBO is that the team is grounded in common cultural norms. If I tell a project team that the “what” matters not the “how” and they all have the same understanding of the quality level, legal boundaries, and cultural expectations (how we treat each other, our vendors, etc.) I get a great result. If these norms are not understood we get chaos (in a bad way) and potentially illegal “hows.” I have had the unfortunate experience of seeing project teams go outside the organizationally accepted boundaries to get the “what” done. This causes a large amount of rework and in the end is much less effective than if I would have managed in a task by task driven method. Before you go down the path of managing only by milestones and deliverables make sure the project team understands, and buys into, the boundaries and expectations of the organization.

Spot on Patrick,
I believe a PM’s management style should be dynamic and should depend on a number of factors among which are
A.how accountable team members are
B. Team members understanding of organizational culture, the quality base line and objectives.

Every projects manager appreciates being able to focus more on diverables and milestones rather than tasks but from experience, I’ve found that this ideal state(in my opinion) is often achieved after the project would have run for a while. At the start of the project, it’s ideal the PM pays some attention to tasks to acertain quality objectives are being met. Deliverables and Milestones can be focused on after the PM is sure that the team now has a good understanding of objectives. It should be the role of a functional manager to manage the tasks and make feedbacks available to the PM. My 2cents.

I fully agree with Varun, and this agreement is based on the practical experience I have while managing outsourced projects.

In outsourced projects, as a customer to the benefit of the projects, I always look in to getting the deliverables and milestones met. In most cases the payment is either linked to a milestone or a deliverable and hence taacking and monitoring them are of great importance. In such projects, we (customer) do not really care about the tasks – it is the responsibility of the outsourced team to manage the tasks – we rather care about the ROI. The ROI is achieved when we have got what we suppose to get.