I’m sitting with Alan Cooper, chairman of the board of Cooper (a company that humanizes technology, he says). He just gave a talk at the PNP Summit (there are two more PNP Summits coming up) about how to avoid “death-march software.” I wasn’t able to record his talk, but recorded most of the conversation that happened afterward. Should be fun to put out there.
I asked him how he can tell if companies are on death-march behaviors. Here’s his answer: “I ask them “who sets the deadline?” You should set your own deadlines. That’s how professional people work. The boss shouldn’t be able to set your deadlines. If the deadline is imposed from the outside, that’s it right there. That’s your smoking gun. It’s stupid not to give your people the resources they need.”
So, are you on a death march?
Scobleizer 
I realise I don’t have the conversation to base this off of, only the paragraph above, but that question of, “Who sets the deadline” being an indication of a death march seems a bit myopic.
There are plenty of reasons to set deadlines for people to meet. The idiocy (and again this may have been in your conversation) is sticking to deadlines no matter what.
If there is a business driver to meet a date and you tell your people to meet it without asking if it is possible, that is also myopic. It all comes down to negotiation. The business needs a date met, the workerbees should come back with, “Here’s what we can give you by that date.”
If it is everything the business asks for then great. If not, you begin the discussions that will lead the business to either scaling back scope or adding people and money.
Like blogs 😉 it’s all about having the conversations that bridge the blue sky with the what’s possible.
LikeLike
I realise I don’t have the conversation to base this off of, only the paragraph above, but that question of, “Who sets the deadline” being an indication of a death march seems a bit myopic.
There are plenty of reasons to set deadlines for people to meet. The idiocy (and again this may have been in your conversation) is sticking to deadlines no matter what.
If there is a business driver to meet a date and you tell your people to meet it without asking if it is possible, that is also myopic. It all comes down to negotiation. The business needs a date met, the workerbees should come back with, “Here’s what we can give you by that date.”
If it is everything the business asks for then great. If not, you begin the discussions that will lead the business to either scaling back scope or adding people and money.
Like blogs 😉 it’s all about having the conversations that bridge the blue sky with the what’s possible.
LikeLike
I realise I don’t have the conversation to base this off of, only the paragraph above, but that question of, “Who sets the deadline” being an indication of a death march seems a bit myopic.
There are plenty of reasons to set deadlines for people to meet. The idiocy (and again this may have been in your conversation) is sticking to deadlines no matter what.
If there is a business driver to meet a date and you tell your people to meet it without asking if it is possible, that is also myopic. It all comes down to negotiation. The business needs a date met, the workerbees should come back with, “Here’s what we can give you by that date.”
If it is everything the business asks for then great. If not, you begin the discussions that will lead the business to either scaling back scope or adding people and money.
Like blogs 😉 it’s all about having the conversations that bridge the blue sky with the what’s possible.
LikeLike
Matthew, yeah, that’s the problem with blogs. You can only post so much text and can’t give the context around a conversation.
The thing he was trying to point out is that companies on death marches force everyone to live with a pre-determined deadline without really doing the design work first and without really understanding the scope, or depth of what’s needed. Or the resources needed.
There also isn’t a whole lot of honesty, or understanding of the problem set between executives and developers, he said.
More to come on this one.
LikeLike
Matthew, yeah, that’s the problem with blogs. You can only post so much text and can’t give the context around a conversation.
The thing he was trying to point out is that companies on death marches force everyone to live with a pre-determined deadline without really doing the design work first and without really understanding the scope, or depth of what’s needed. Or the resources needed.
There also isn’t a whole lot of honesty, or understanding of the problem set between executives and developers, he said.
More to come on this one.
LikeLike
Matthew, yeah, that’s the problem with blogs. You can only post so much text and can’t give the context around a conversation.
The thing he was trying to point out is that companies on death marches force everyone to live with a pre-determined deadline without really doing the design work first and without really understanding the scope, or depth of what’s needed. Or the resources needed.
There also isn’t a whole lot of honesty, or understanding of the problem set between executives and developers, he said.
More to come on this one.
LikeLike
Deadlines are important. It’s important to have commitments on getting stuff done and its important to have *realistic* predictions of when stuff will actually get done. So here is why it’s bad when schedules and deadlines are imposed from the top down: Upper management generally doesn’t have a clue how long tasks will take. When people who don’t really understand the task at hand make a schedule based on marketing and profitability, the result is unrealistic, and either the deadlines get missed or quality suffers. Of courses it is important to consider marketing and profitability in project manangement, but the right way to do it is give people lower down a detailed description of the task and allow them to be part of the planning process. If you can’t make a profitability bar then you may need to reduce the scope of the task.
LikeLike
Deadlines are important. It’s important to have commitments on getting stuff done and its important to have *realistic* predictions of when stuff will actually get done. So here is why it’s bad when schedules and deadlines are imposed from the top down: Upper management generally doesn’t have a clue how long tasks will take. When people who don’t really understand the task at hand make a schedule based on marketing and profitability, the result is unrealistic, and either the deadlines get missed or quality suffers. Of courses it is important to consider marketing and profitability in project manangement, but the right way to do it is give people lower down a detailed description of the task and allow them to be part of the planning process. If you can’t make a profitability bar then you may need to reduce the scope of the task.
LikeLike
Deadlines are important. It’s important to have commitments on getting stuff done and its important to have *realistic* predictions of when stuff will actually get done. So here is why it’s bad when schedules and deadlines are imposed from the top down: Upper management generally doesn’t have a clue how long tasks will take. When people who don’t really understand the task at hand make a schedule based on marketing and profitability, the result is unrealistic, and either the deadlines get missed or quality suffers. Of courses it is important to consider marketing and profitability in project manangement, but the right way to do it is give people lower down a detailed description of the task and allow them to be part of the planning process. If you can’t make a profitability bar then you may need to reduce the scope of the task.
LikeLike
Here are some notes in my blog from Cooper’s recent “Ending the Death March” talk.
I didn’t quite get what exactly the “blueprint” solution he recommends would work (and the inner-workings of the “Triad”)… Alan’s response to my questions live here.
I just wish I didn’t have to take a course to get to the bottom of this!
LikeLike
Here are some notes in my blog from Cooper’s recent “Ending the Death March” talk.
I didn’t quite get what exactly the “blueprint” solution he recommends would work (and the inner-workings of the “Triad”)… Alan’s response to my questions live here.
I just wish I didn’t have to take a course to get to the bottom of this!
LikeLike
Here are some notes in my blog from Cooper’s recent “Ending the Death March” talk.
I didn’t quite get what exactly the “blueprint” solution he recommends would work (and the inner-workings of the “Triad”)… Alan’s response to my questions live here.
I just wish I didn’t have to take a course to get to the bottom of this!
LikeLike
– So, are you on a death march?
– Yes, I am, but I enojoy having some pressure. How else am I going to get some adrenaline? Anyhow, it is limited pressure. We try to follow SEI’s CMMI guidelines.
LikeLike
– So, are you on a death march?
– Yes, I am, but I enojoy having some pressure. How else am I going to get some adrenaline? Anyhow, it is limited pressure. We try to follow SEI’s CMMI guidelines.
LikeLike
– So, are you on a death march?
– Yes, I am, but I enojoy having some pressure. How else am I going to get some adrenaline? Anyhow, it is limited pressure. We try to follow SEI’s CMMI guidelines.
LikeLike
Robert, glad I was on the right track. I didn’t think that was something Mr. Cooper would support outright as the quote above (taken solely on its own (caveats understood)) would be the other end of the spectrum.
But one thing to point out, especially to bigger companies, is that there will be multiple areas that practise different strategies to bring concepts to market. Just because one area of the company rushes something to market to meet a date (when they know there are major bugs) doesn’t mean the rest of the company is like that.
In a way, it would be nice to have this situation within a big company. You could start tracking quality produced by the different approaches to see what truly works and why. In my experience, the “deadline or else” metality can only work if the company is committed to supporting what they launch from day -1; continuously and quickly relaunching with improvements. My guess is this is a little cheaper in the software world.
Anyway… 🙂 I could go on and on as figuring out how companies can do better work is of much interest to me.
LikeLike
Robert, glad I was on the right track. I didn’t think that was something Mr. Cooper would support outright as the quote above (taken solely on its own (caveats understood)) would be the other end of the spectrum.
But one thing to point out, especially to bigger companies, is that there will be multiple areas that practise different strategies to bring concepts to market. Just because one area of the company rushes something to market to meet a date (when they know there are major bugs) doesn’t mean the rest of the company is like that.
In a way, it would be nice to have this situation within a big company. You could start tracking quality produced by the different approaches to see what truly works and why. In my experience, the “deadline or else” metality can only work if the company is committed to supporting what they launch from day -1; continuously and quickly relaunching with improvements. My guess is this is a little cheaper in the software world.
Anyway… 🙂 I could go on and on as figuring out how companies can do better work is of much interest to me.
LikeLike
Robert, glad I was on the right track. I didn’t think that was something Mr. Cooper would support outright as the quote above (taken solely on its own (caveats understood)) would be the other end of the spectrum.
But one thing to point out, especially to bigger companies, is that there will be multiple areas that practise different strategies to bring concepts to market. Just because one area of the company rushes something to market to meet a date (when they know there are major bugs) doesn’t mean the rest of the company is like that.
In a way, it would be nice to have this situation within a big company. You could start tracking quality produced by the different approaches to see what truly works and why. In my experience, the “deadline or else” metality can only work if the company is committed to supporting what they launch from day -1; continuously and quickly relaunching with improvements. My guess is this is a little cheaper in the software world.
Anyway… 🙂 I could go on and on as figuring out how companies can do better work is of much interest to me.
LikeLike