4 ms·

Yeah, it seems like scope needed to be reduced in order to deliver an MVP on time.

pyrolistical 4y ago
I wonder if we have conditioned clients to expect everything now. Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run? Do we have too much of a revolving door for an organization to see this trend?
- rayiner 4y ago
  Yes. If you need more time ask for it and explain why it’s necessary and why the delay couldn’t have been anticipated. It’s better to be late than be late and also delivery a shoddy product.
  - HeyLaughingBoy 4y ago
    Sounds a lot like the discussion I had with my 12 year-old about his Science term paper :-)
    - rayiner 4y ago
      Being transparent and communicating roadblocks early is just a good way to get through life. Nobody likes to hear something will take longer than expected, but what people really hate is non-communication that leads to unexpected delay, or even worse, poor work that's delivered late.
- throwawaysleep 4y ago
  Pretty much. I have never seen a product manager/project manager see a multi year project through to the end. I also suspect a lot of it comes down to it not being the problem of anyone until the end of the project. Sales can promise whatever they want. Tech can put it off for a while.
- origin_path 4y ago
  "Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run?" It sounds paternalistic but yeah, that can happen. I've been in this sort of office politics situation where that was an issue. The problem in that case was that the projects were quite long and touched many different people inside the customer companies, many of whom had differing agendas. In particular the customers were banks and their security people had a habit of demanding very specific changes that would clearly sink the entire project a couple of years down the line, and even contradict the original justifications for it. Unfortunately the company I worked for at the time had a lot of difficulty with this concept. The upper management tended to abstract the political complexity inside these banks as "the customer wants X so why aren't we giving them X" where in reality there was no "the customer", just lots of people inside big orgs who weren't really talking to each other. The notion that "the customer" could be incoherent and we needed to manage that somehow just wasn't there at all, they just saw it as anti-social arguing. So it was in fact career limiting for me to point out these issues.
Mathnerd314 4y ago
It seems like Agile would have been a great fit. Too many requirements, no real information - it's exactly the situation where throwing out prototypes and getting feedback can lead to a solution.
- TremendousJudge 4y ago
  I don't think hiring some certified Agile gurus and reshuffling all the teams in the middle of the project would have improved the chances of delivery.
  - ajmurmann 4y ago
    It depends if you do certified Agile™ or apply some core agile principles. Getting something that works ASAP and then iterate is a huge win whenever possible. Losing steam on a project that hasn't met any useful milestone yet must be one of the main sources of waste in our industry. Granted, 15 months in might make it tough to correct course towards a shippable milestone. Definitely worth the exercise tough.
- tootie 4y ago
  Agile is great for running execution teams and gives you real-time feedback on progress, but if you have a contract with fixed scope and timeline, you're just boxed in. Agile requires flexibility on time and/or scope and it's not amenable to a services contract unless you have a very trusting customer.
  - Mathnerd314 4y ago
    It's not clear how long the project lasted but it was at least 3.5 years. So the time-line couldn't have been that rigid; yes there was a Gantt chart but those are like horoscopes. And since the requirements kept coming in there was no fixed scope. As far as the customer goes you can say something like "we'd like to deliver a prototype early" and then it sounds like you're exceeding the contract. You just have to get them to prioritize features while avoiding discussing the fact that it's impossible to deliver all the features they requested. Basically you treat the lists as a wishlist rather than a requirements list. Maybe you come clean later once they like the prototype. I'm not saying it would have saved the project, I'm just saying it's better than giving up and saying "the project is doomed" like OP did. But maybe OP wasn't cut out for a leadership role.

I wonder if we have conditioned clients to expect everything now. Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run? Do we have too much of a revolving door for an organization to see this trend?

rayiner 4y ago
Yes. If you need more time ask for it and explain why it’s necessary and why the delay couldn’t have been anticipated. It’s better to be late than be late and also delivery a shoddy product.
- HeyLaughingBoy 4y ago
  Sounds a lot like the discussion I had with my 12 year-old about his Science term paper :-)
  - rayiner 4y ago
    Being transparent and communicating roadblocks early is just a good way to get through life. Nobody likes to hear something will take longer than expected, but what people really hate is non-communication that leads to unexpected delay, or even worse, poor work that's delivered late.
throwawaysleep 4y ago
Pretty much. I have never seen a product manager/project manager see a multi year project through to the end. I also suspect a lot of it comes down to it not being the problem of anyone until the end of the project. Sales can promise whatever they want. Tech can put it off for a while.
origin_path 4y ago
"Are we harming our own customers by allowing them to make demands that in turn only harm themselves in the long run?" It sounds paternalistic but yeah, that can happen. I've been in this sort of office politics situation where that was an issue. The problem in that case was that the projects were quite long and touched many different people inside the customer companies, many of whom had differing agendas. In particular the customers were banks and their security people had a habit of demanding very specific changes that would clearly sink the entire project a couple of years down the line, and even contradict the original justifications for it. Unfortunately the company I worked for at the time had a lot of difficulty with this concept. The upper management tended to abstract the political complexity inside these banks as "the customer wants X so why aren't we giving them X" where in reality there was no "the customer", just lots of people inside big orgs who weren't really talking to each other. The notion that "the customer" could be incoherent and we needed to manage that somehow just wasn't there at all, they just saw it as anti-social arguing. So it was in fact career limiting for me to point out these issues.

Mathnerd314 4y ago

It seems like Agile would have been a great fit. Too many requirements, no real information - it's exactly the situation where throwing out prototypes and getting feedback can lead to a solution.

TremendousJudge 4y ago
I don't think hiring some certified Agile gurus and reshuffling all the teams in the middle of the project would have improved the chances of delivery.
- ajmurmann 4y ago
  It depends if you do certified Agile™ or apply some core agile principles. Getting something that works ASAP and then iterate is a huge win whenever possible. Losing steam on a project that hasn't met any useful milestone yet must be one of the main sources of waste in our industry. Granted, 15 months in might make it tough to correct course towards a shippable milestone. Definitely worth the exercise tough.
tootie 4y ago
Agile is great for running execution teams and gives you real-time feedback on progress, but if you have a contract with fixed scope and timeline, you're just boxed in. Agile requires flexibility on time and/or scope and it's not amenable to a services contract unless you have a very trusting customer.
- Mathnerd314 4y ago
  It's not clear how long the project lasted but it was at least 3.5 years. So the time-line couldn't have been that rigid; yes there was a Gantt chart but those are like horoscopes. And since the requirements kept coming in there was no fixed scope. As far as the customer goes you can say something like "we'd like to deliver a prototype early" and then it sounds like you're exceeding the contract. You just have to get them to prioritize features while avoiding discussing the fact that it's impossible to deliver all the features they requested. Basically you treat the lists as a wishlist rather than a requirements list. Maybe you come clean later once they like the prototype. I'm not saying it would have saved the project, I'm just saying it's better than giving up and saying "the project is doomed" like OP did. But maybe OP wasn't cut out for a leadership role.