Deadlines are a proxy for dependencies

The deadline is important because of scheduling, and whoever needs to use your thing has a certain stretch of time where they can implement their part.

I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts. You could make a gannt charts from it, if you add all the estimates, and define the available parallelism, but the reason for doing some piece of work is whatever depends on it, and you can follow the dag up to the end feature

Don't disagree, but deadlines are a very indirect and poor proxy which focuses on time rather than deliverables.

> whoever needs to use your thing has a certain stretch of time where they can implement their part

But the idea that timelines are critical to a project's progress must be a myth, because software projects are almost always delivered late. The dependency is always on the feature or deliverable, not on the date. The depending team will work out how to cope because that's what happens every day in most software shops anyway.

I'm not saying that deadlines and timelines are bad. I'm just saying that they should not be the core organising principle for delivering a project.

Bad PMs and biz stakeholders are often the straw men for why deadlines are unreasonable or don't work. But if you take a high performing team with good cross-functional trust, deadlines serve a very valid function as a forcing function to make decisions, cut scope, and otherwise make progress towards shipping. Without them, it's all too easy for time spent to balloon for a million different small but justifiable reasons.

And sometimes (not all the time), it does make sense for a deadline to be the core organizing principle, see this Mary Poppendieck talk for an interesting example: https://www.infoq.com/presentations/tyranny-of-plan/

I enjoyed that video some time ago, but I really didn't get the takeaway about timelines. Maybe I didn't watch it through.

Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice.

So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible.

Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.

It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.

I do largely agree with you, except here:

> Deadlines are about synchronizing different groups

If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role.

Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers.

For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”.

As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving.

Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.

“whoever needs to use your thing has a certain stretch of time where they can implement their part.”

This can be ameliorated many times by attempting to mock something that covers the most likely interaction between the dependencies. For example, you are waiting for an API to provide some data to you: create an agreed upon JSON format that you will expect to receive and use that to mockup the interface till it’s complete. This allows both sides to move forward more independently till both are complete and ready for integration.

I think as well that this is a problem that Kanban solves quite well. Instead of having a team sitting around waiting for another team, ideally you have people who can take a bit of work from a board and be productive even if their primary project is stalled. This is (part of) how I've run my last few projects and it's been very successful from a productivity perspective.

The problems I've had with this is getting management to understand that productivity and developer quality-of-life is important. They want road maps, god damn it, because reasons. And they say they won't hold us to the road map, but then they do. And at the same time, the road map captures productivity because now you're doing what the road map says instead of being productive.

But building software is often like building a tunnel. You don't know what you're going to be drilling through until you've drilled through it.

> I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts.

Thats called an Event Chain Diagram and it is the bit that comes after doing a CPA, with or without a PERT.

I strongly believe that Microsoft Project is the reason for the incredibly poor quality of project management we generally see in our field. I spent a few years working in organisations where project planning is done properly, by real Project Managers, that understand how to deal with uncertainties around time and effort required to deliver a thing. That was actually glorious and I’m no longer able to tolerate the clowns that saturate our field

> I’m no longer able to tolerate the clowns that saturate our field

I looked up Event Chain Diagrams and it is probably overkill for the scale of projects I typically work on. Nevertheless it's much more reasonable than the kind of MS-Project based things I've been forced into working with over the years.

Perhaps the worst part of this journey for me has been that I've supposedly been in positions of authority when this has happened. The gravitational pull of what is essentially waterfall project management is so hard that refusing to do it expends significant political capital.

So the clowns are out in force even in my little patch, and I laughed out loud when I read your comment.

You're describing a crippled form of PERT charts, which I favour over gantt charts anyway.

> ...and project managers seem to think their role is to hit people over the head until morale improves and features are delivered, no matter what.

Sorry to hear. Thankfully I've been lucky in that most of the project managers that I've worked with tended to focus on the things that are blocking their technical staff from completing their work, and those blocks get put on the project managers task list to be unblocked.

I think it really depends on the industry. If you're in a tech company with lots of experienced software people in charge then it's different. But the majority of projects I've worked on (and, I'd argue, the majority of projects) are about getting software into non-software businesses.

In that case, the problem is you need PMs who are well versed in the domain, software, AND project management. But typically, you get people who have done a PMI or Some Agile Framework™ course and think they know how to do it.

> why oh why do we prioritise deadlines over productivity

I feel this is a tradeoff between latency and bandwidth.

Hitting a tight deadline (or Sprint goal) by creating a bunch of technical debt delivers the feature we need today faster (lower latency). But at the expense of making features tomorrow more difficult to create (lower long-term bandwidth).

I think it's OK to prioritize one over the other based on the business needs.

But I think it needs to be an explicit decision and tradeoff, and I worry that too often managers choose low latency because they can feel it and see the results, and don't understand the tradeoff they're making.

Right, there are times when you need deadlines and you need to make decisions. Knowing what I know today, I would recommend cutting scope over technical debt, but that's beside the point really.

My problem is where the whole project is managed based on deadlines rather than the flow of work. Deadlines kill productivity, but productivity = efficiency = saving money.

The financial accounting for these things is complex, but considering most projects run late anyway, why even bother with deadline based management?