TL;DR Let’s stop using the word deadline and replace it with “prediction”
I have a major problem with the way that a lot of projects (notice I didn’t say all projects) are run. It still baffles me sometimes the way that the PMs of this world (whatever the P is) are pretty much hacked off with all the engineers (the doers in this process) taking zero responsibility for their code.
I got into a bit of a discussion on twitter (it happens) with swardley and Alex Hudson and others about managing projects.
I am not a very good Project Manager if you want me to be honest. I have actual PM qualifications though! I know how to Project Manage. I have the skills. I have managed many projects of course and I’ve even picked up the buzzwords (we’re soooo Agile and do Sprints!)
And I use Trello at Movivo (woooooooohooooooo)
But I’ve always hated deadlines. Well… the word at least. Those fixed points in time that feel like we should have two epochs in our Project world
Before Project Deadline (BPD)
After Project Deadline (APD)
(And generally nobody dies)
(This bit is simple Project Management stuff we should all know at least intuitively)
The thing is, the way that a project works, you have something called the Project Management Triangle:
Project management triangle
The Project Management Triangle (called also Triple Constraint or the Iron Triangle) is a model of the constraints of…
They are in a balance.
But in most tech project scenarios my experience is this:
- Someone/client/boss creates a project that needs doing
- The team behind it say “I reckon we can build that by… x date”
- (On x date): We built most of it, but had to change some stuff, but it does what you want!
What this scenario shows is that what people outside the process often hear is “Your project will be completed by this time (deadline)”, and that fixed point is hard and fast and an immovable object.
The problem is that essentially, within the triangle, what you’re doing is fixing the schedule constraint at the start.
Which is fine, so long as you have the ability to play with at least one of the other two parts, which are the scope and cost.
But you very often don’t.
Because the project owner often gives you a budget to deliver this project. Asking for any more part way through is basically saying “you didn’t scope this properly”.
And if you end up not completing the project with 100% of what was scoped, then you essentially haven’t “delivered” the project correctly.
Let’s be ABSOLUTELY clear on this
Most of the time, most clients completely ignore the triangle.
Yup… Project Managers know all about it
And the clients don’t care.
They just want what they want and delivered when they want it.
But we’re all Agile now
I love the idea of Agile (it’s like the idea of serverless — Update: because they are more “philosophies” than rigid structures) and when it’s done right, it’s brilliant. But most of what I see as Agile is not Agile according to the ideas of the manifesto:
Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. These are our values and…
Basically, the key (as I see it) to agile is that you essentially stop trying to force a complete scope before you know what you’re doing, and try to develop constantly working solutions.
In other words, when you deliver something, it actually does a bunch of things, and you can say what it does (but it may not be everything… yet).
But the funny thing about this, is that for most people, this doesn’t fit into the way they think about projects.
(I remember a project that I did, where we followed this pattern, specifically stating at the start that we would deliver parts of the project at a time in priority order. The client said it was fine, but months into the project, they kept saying they wouldn’t accept anything until the last priority was completed. We ditched them as a client, and walked away, lost money and learned a lot)
Projects are still this fixed, finite budget, finite time, and limited resources thing.
Which is why Agile often (not always) works really well for funded startup scenarios where there is flexibility on both budgets and time.
It also works well when you have a large enough pool of developers/product people who know the process and are allowed an amount of flexibility in both scope and timescales (notice here that this means you have to accept an amount of risk that costs may be higher than expected — but they may be much lower too).
It often (not always) works poorly for constrained budgets. I cannot tell you the number of companies who have done a project using “agile” techniques who have then delivered what can only be described as a “minimal” solution, because they failed to take the client through a basic understanding of what user stories are all about at project initiation, therefore set the client up for a poorly defined set of stories, and basically it fails at that point.
So, where is the problem?
To be honest, even with all the buzzwords around startups (XP, Scrum, Lean, TDD, BDD, Design Thinking) there are always going to be new things, but at present, my view is that there is a lot of rubbish spoken about as the “right” way of doing things.
Unfortunately, what often happens is that project managers revert to something that looks like a mix of Waterfall and Agile in the end, because it’s easier, people understand it, and often, the layers of management fail to communicate properly, so the simplest thing to do is to do the simplest thing.
And that’s not necessarily a bad thing.
Every scenario is different of course, but my take on the problem is that you have to put in place the right tools and discussions as early as possible for the right stage of where you are.
I have to push you to swardley and his various maps to explain stuff, but this blog does talk about this point around when to use different PM tools/techniques:
Bits or pieces?
Every large system (whether a line of business or specific IT project) contains multiple components. Those components…
Basically, what I take out of that blog is the simple fact that no system of Project Management is right for any company at all times.
But we’re not all enterprise companies, with large teams, budgets to hire Simon and his skillset, or even the ability to hire good Project Managers (unless you luck out in the oh so messy recruitment process).
So how do we cope with Deadlines?
So what has this got to do with deadlines?
I’m going to make a radical proposal here.
We stop calling them deadlines
There’s no death here
It’s a review point.
So let’s call them Predictions
And be very clear that it’s a prediction not a deadline.
Every prediction of completion is a guess before you start.
Which is why when you do a fixed price project, you have to add in contingency, every time (and often that contingency is 2,3 or 4 times the predicted size of the project — so go for day rate, not fixed price, as it’s often cheaper, but carries higher risk).
Which is why every fixed price large scale IT project that some of the big consultancies do is so enormously overpriced, because they know (they absolutely know) that the scope will change and they will go back and push the timescales back and the budget up, and basically do the dance that means that in the end, it doesn’t matter if it works, because they’ve made their money.
(Note: Most startups are sick of hearing how a big consultancy has done something clever. It’s really easy to throw a large number of average/good people at a problem and come up with something. Startups basically do that on a shoestring all the time… ALL THE TIME. If you ask me, bringing in the right startup thinking in the enterprise world would go an awful long way to reducing costs of tech projects, increasing innovation, and getting rid of middle managers who have completely lost the plot with understanding how to manage risk)
So let’s stop pretending that IT projects are hard.
What is hard is predicting the future.
Which, let’s face it, is exactly what we’re doing when we start a tech project.