Better ways to plan and discuss alternative development plans

Question

I have a designer, a remote front end developer, a remote back end developer and a remote full stack.

When I estimate timelines I decide the tasks throw them into some gantt software set reasonable times depending on what task is then organize the tasks so that when 1 person is waiting for something, something else is being done. I also take into account that there are some areas guys know better, and so might take slightly longer if I give it to the full stack dev rather than the back end dev for example.

Product and sales will start trying to optimize things; what if we do this first. What are the dependencies here, maybe if we do this instead, we can defer this decision until later because the work for both of these features is the same.

Everyone assumes that because I have done 1 set of planning, I know how long it will take if the ordering is all changed. I think this would be entirely possible if I planned features as blocks, and accepted that some people will be underutilized for periods and thus I should expect overall delivery to take longer but then I am sacrificing costs and time for the sake of being able to explain things.

Additionally my view of the planning involves about 100 tasks, compared to theirs which are high level items. So as you can imagine, moving things about is time consuming and it isn't always obvious to me that doing task 35 after task 85 is going to cause some issue.

Is it better for me to just plan things in a way that it can all be reorganized for these types of discussions. Should I expect to make 3+ plans and present them all as options? Or is there some better way to deal with this.

Answer 1

Two points I want to comment on:

When I estimate timelines

Stop estimating work for other people. Unless you are the one doing the work, you're not the one who's supposed to estimate it. The ones doing the work are the ones who estimate.

when 1 person is waiting for something, something else is being done [...] people will be underutilized for periods and thus I should expect overall delivery to take longer

You have that backwards. When you optimize for 100% utilization, you're sacrificing throughput. Consider the following situations:

Situation A:

• Alice starts working on Task A
• Bob starts working on Task B
• Charlie starts working on Task C
• Charlie hits a roadblock, needing help from Alice. But Alice is busy with A so Charlie moves on to D.
• Bob hits a roadblock, needing help from an external party. Bob moves on to E.
• Alice hits a roadblock, needing help from Bob. But Bob is busy with E so Alice moves on to F.
• The external party gets back to Bob but he's busy with E so he waits until the next day to reply.
• Alice finishes F. Bob's still busy with E so Alice moves on to G.
• Alice and Bob both finish E and G. Alice wants Bob's help with A but he's moving back to B now, so Alice moves on to H.

...Meanwhile the highest-priority work, A, B, and C, has been sitting so long that no one remembers what they were doing for them.

Situation B:

• Alice starts working on Task A
• Bob starts working on Task B
• Charlie starts working on Task C
• Charlie hits a roadblock, needing help from Alice. But Alice is busy with A so Charlie switches to pairing with Bob.
• Bob hits a roadblock, needing help from an external party. So Bob switches to helping Alice while Charlie starts researching foobar widgets.
• Alice hits a roadblock but Bob is there to help her. A is completed.
• Alice moves to help out Charlie, who switches back to Task C, while Bob starts refactoring old code.
• The external party gets back to Bob. He switches back to Task B and finishes it, moving on to Task D.
• Alice and Charlie finish Task C, moving on to Tasks E and F.

Hopefully you can tell which approach is better for the business and the team. Optimize for throughput, not utilization. 100% utilization is a fallacy.

Answer 2

I think you are approaching this from the wrong end. It seems to me that you don't need more plans, but less.

Although military in origin, the following is a well known quote in project management:

No plan survives contact with the enemy - Helmuth von Moltke the Elder

Your one plan is being changed by product and sales people. Why do you think this will be any different than plan two or three? And can you really plan for every combination of features? If you estimate everything as blocks, do you then think that work will occur exactly as estimated no matter how you rearrange the blocks? The Cone of Uncertainty says it won't.

What you need here is a way to do a high level planning with the product and sales people covering a shorter period of time (a couple of weeks, one month at most), figure out what exactly they want to do, then split those things into tasks for your team to do. Then repeat.

This is an Agile approach to planning. Instead of splitting things into phases like planning and execution, you try to deliver the things that bring more value first, deliver them, then plan what to do next, deliver, plan, and so on. If you try to create too many plans, a lot of them won't happen as initially outlined and end up to be waste once reality (i.e. contact with the enemy) forces you to re-plan.

Answer 3

I totally agree with Bodgan's reply. It seems you are tying to micromanage a development team, so stop doing that and instead let the development team own the plan. Get the business stakeholders to nominate a product owner who can determine business priorities and let the team construct a backlog and then work through it. Are you familiar with Scrum or Kanban methods? That's something you could suggest to the team.