8 ms·

No one can manage projects, especially technology projects

76 points by weare138 6y ago

anotheryou 6y ago
TL;DR: fix hiring (well he doesn't even say that, just "pick the right people" which sadly most of us have only some control over).
- Fannon 6y ago
  But how could "pick the right" people possibly work out for everyone? Maybe some higher paying / more prestigious companies can do that. But that would still leave the other companies with the original problem and not change anything about the industry wide statistics / problem? However, the author also points out training. So changing the quality of education and the culture around the people can drive this into a better direction.
  - anotheryou 6y ago
    The two "under-performing" types I encountered where "hard to work with" and unskilled. Unskilled but smart is not a big problem as long es there are some more senior people. They might not get that much done, but they are still net positive :). And of course they improve if you can hold them for a longer time. People really hard to work with on the other hand are a tough nut and can hold back projects. I think this is often bad hiring. At least a company I worked for hired because they couldn't find anyone better (for the budget) and it turned out to be a big mistake. Either way, you have to live and calculate with what you have. If you do product work however I don't see why deadlines are all that important and would rather focus on the small, most impactful next iteration.
    - loopz 6y ago
      Hard to work with may dissolve if management set a good culture where everyone meet on even terms. Having a few hold all the keys to the kingdom scales badly.
      - anotheryou 6y ago
        Haven't made that experience. I worked in really good cultures where I loved the teams, but that can't always remedy the situation. It's just a drag on everyone: Nobody wants to work with that person, they fail to communicate important things, there are pointless discussions. Even honest communication, mutually agreed on workflows and so on can't always fix things.
    - jon-wood 6y ago
      If you’re doing software product work I’m totally with you on small impactful iterations. When you’re delivering a hardware product this is a lot more difficult to pull off. There are definitely ways to take an agile approach to hardware development, even if you’re working with an OEM, but the outcomes look a lot more like waterfall than your typical Agile with a big A people are comfortable with. The outcome of your iterations are long specification documents (which you’ve already got feedback on from your OEM), and a lot more detail than you’d typically go into development for on the software side since it has to integrate with the actual hardware.
      - anotheryou 6y ago
        Right, I also like waterfall for bigger projects with fix requirements at the end. In fact I also mix agile with waterfall. So much easier to keep adjusting your requirements for a few milestones ahead than to scramble together stories to fill the next sprint every other week.
- ccortes 6y ago
  I still don't get why most of the recruiting process is left to the HR department. I get they objective is to minimize your distraction as a manager, but it's such an important part of building a good team and it feels that in many cases you (the manager, not necessarily PM) contribute like 20% of the whole process.
  - anotheryou 6y ago
    I recently was part of the hiring process for the first time and it was 80% the team, 10% me and 10% HR/boss doing the decision. The person we hired is absolutely awesome :)
Closi 6y ago
> [Research shows that] Only 58% of organizations fully understand the value of Project Management > Why do only 58% of companies value project management? Well, that seems to be taking the research totally out of context in the first paragraph. And then just rambles on about having great people, and having them really well trained in project management. Wow, who would have thought being good at project management and making people better at project management was the solution to getting better at project management!? "Is scope creep the problem? No, thats just a symptom of people again, and training. Did I mention I have a book?" Maybe I'm just cynical here, but there doesn't seem like too much insight here.
konschubert 6y ago
Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.
- ardit33 6y ago
  That is a very good point. I think non-technical people can not understand the complexities that go with building new products.
- choeger 6y ago
  Maybe it becomes time to change that. Less innovation and more repetition could help here. I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
  - pbourke 6y ago
    > I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends. I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
    - Findeton 6y ago
      Some things don't change that much. Good luck deprecating Postgres.
  - pornel 6y ago
    Physical projects have a construction phase, because they don't have the luxury of zero-cost copying. If you want to construct two identical houses, you still need people to lay bricks twice. If you want two identical websites, you deploy the same files twice. By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.
hungryforcodes 6y ago
He seems to be pushing his book and possibly at the end his school: "Years ago I wrote a book – IT's All about the People: Technology Management That Overcomes Disaffected People, Stupid Processes and Deranged Corporate Cultures – that focused on the human element in technology. The premise is as correct today as it was then." Projects are hard and deal with the unexpected. If you've never done anything like whatever you are trying to do before, you will encounter delays. These are really not failures -- in fact a lot of projects are "finished" with many additional "add on" pieces and enhancements scoped for future work. Tellingly, companies that do the same thing over and over again (video game companies come to mind), are actually pretty good at delivering on time and on budget. With a stable and experienced workforce, the right corporate culture and reusable work breakdown structures, it's all possible.
- smarx007 6y ago
  Seems like the author finally stopped using the word "suck" while talking about people in print: https://www.goodreads.com/review/show/300695296?book_show_action=true https://www.goodreads.com/review/show/300695296?book_show_ac...
  - darkerside 6y ago
    This is an incredibly well written review. Much better than the linked article, which is derivative, vacuous, and full of typos. > Training should be re-invented around practice. Project management residents should learn how and what to do to manage projects successfully, and just like the medical profession, bad project managers should be washed out of their residencies. This seemed to be the only novel idea in the article, and it comes at the end, and is never explained.
mdorazio 6y ago
I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I know HN loves to talk about how much the PMs they've reported to suck, but having worked with many clients on dozens of projects, it's rarely that simple. While bad PMs are definitely way too common, so are bad development teams. And remember that PMs are usually getting shit on from two directions at once (development teams and management teams) with often very little authority to actually fix things. It's usually bad management practices and attitudes that sink projects and make life hell for everyone, and the cause of that is usually lack of understanding and empathy for how software development works. The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.
- loopz 6y ago
  If management don't understand the projects, and they generally don't, what are they really managing? Oh yeah, get the pay but use position as shield and sword.. You'll see the few exceptions are acting more like a PM, on and off.
  - rualca 6y ago
    > If management don't understand the projects, and they generally don't, what are they really managing? With the inception of Agile, by definition software projects are impossible to understand in the sense of having a clear idea regarding concrete goals and risks, technical designs, and timelines. Yet, you will need to manage resource allocation, plan tasks, eliminate risks, and coordinate between stakeholders. That's what a manager does.
    - loopz 6y ago
docflabby 6y ago
Something that always seems to get missed is successful projects are linked to motivation. If everyone in the project is motivated to make it a success it's more likely to be. Use an old technology none of the programmers are interested in and they go find other jobs or not work very hard as they put there efforts into their more interesting side projects.. As an example, projects linked to fulfilling legal requirements normally succeed because the motivation is strong - failure = fine/prison time. Most projects I've seen failure where senior managnent doesn't want the project anymore but need a way of getting rid of it while saving face. Classic way is to pass the project onto another department...
shuringai 6y ago
they had me on the first part then it became clear the article is just a book advertisement
dragonsky 6y ago
I've observed and participated in a reasonable number of projects, both IT and otherwise. In my experience there are two problems that seem to exit in every project that either failed or had to go on to life support: 1. The deliverables were not clearly defined and maintained. How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep. 2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system. Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working. If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.
- magicalhippo 6y ago
  > People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not. In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt. After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project. This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.
deleted 6y ago
[deleted]
withPurpose9973 6y ago
“I wrote a book on how PM is hard. It starts by hiring the right people. Of course, I wrote a book detailing how all the people involved at scale keep screwing it up. Buy my book.” This a circular advertisement for a book. I am guessing it’s more to with how most organize socially for human emotional reasons first and tacitly don’t give a shit about ephemeral nonsense except to play “Society: The Board Game”.
aitchnyu 6y ago
My pet solution is to use traditional MVC frameworks like Django, Laravel, use Bootstrap stock themes for style, and sprinkle in specific JS wdigets as needed. This will (IME) make day to day work much less chaotic. The chaos of changing business requirements will be amplified when we reimplement API and React for every page and errant JS breaking even scroll. If I can dream, non-tech guys can only mention high-level goals based on data than interface. Instead of the mandate "in one day, reimplement snazzy chart from slick app...", tell "show top 5 contributors" and tech guys can provide an economical solution first and iterate on it later.
jack_riminton 6y ago
It's true that leadership is the key. Projects are successfully lead, not managed. This means leading those above too: getting more resources, communicating and managing expectations The nature of projects is that they're often one-offs or something that the company hasn't done before. So unless you're being very generous with time, scope and quality estimates you're likely to be way off because of optimism bias
hawktheslayer 6y ago
Reading this article calls to mind von Tiesenhausen's Law of Program Management: "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."
gonzo41 6y ago
I'm going to go out on a limb and say that smaller project are a possible solution. Do less and deliver something. I've just gotten off two, multi-year projects, the first crashed and burned due to a mismatch between business process, vendors and the skills in the organization to understand what it does and translate that into requirements. From the development side, we made a lot of stuff. Most of it was junk. The second project arrived at a point underdone. Unable to replace the existing production solution because of a lack of a burning deck. I'd put this down as a failure as well. Mostly on the strategic leadership side. In the meta sense these projects weren't that bad. People got money for doing them, and that money was spent in the economy. Maybe Amazon is onto something with their two pizza teams, and 7 page proposals.
- mrich 6y ago
  Smaller teams, and product management should be done by the development team. This will only work with at least some experienced developers on board who have shipped something before and had to deal with the results of that in production as well. For dedicated product managers the risk is high that the person does not know enough about the product or development. This is especially true in organizations where product management is an "easier" career path compared to development.
ngrilly 6y ago
Poor article in my opinion. The problem described in the article is very true. But the solution, “focus on people”, is mostly tautologic and doesn’t explain at all what makes some projects successful and not others. I’m disappointed.
yowlingcat 6y ago
A key elephant in the room in this article: if it's just about hiring the right people, why is that so hard? Because most companies treat technology as a cost center, not a profit center. Even for companies where that's the case, treating technology like a cost center is like treating legal as a cost center -- existential company killing risk goes way up if you don't pay for the real deal. And for companies where it isn't, you'll just flat out waste your money. Pay for a Yugo when you need a big rig and you'll get exactly what you paid for, which won't be what you need.
blackrock 6y ago
Maybe you should stop thinking your stupid L33T coding interviews will get you the best engineers. And actually interview your engineers for stuff that matters. Like how they achieve redundancy, resilience, and fidelity in their software development. And also, get some managers with half a brain, to understand that changes to the requirements can affect development efforts.
eecks 6y ago
From my experience it all comes down to budget. If IT is a cost, then the ideal thing to do is to deliver while minimizing that cost (duh!). When you do that you get solutions that are the quickest and cheapest thing at that moment. This actually has further impact on other projects because everything is done badly.
acalzycalzy 6y ago
They’ve been managing them since the beginning of technology
nix23 6y ago
Really forbes? https://en.wikipedia.org/wiki/Saturn_V https://en.wikipedia.org/wiki/Saturn_V
ksec 6y ago
My question is, I wonder how Apple does it. Or May be Netflix. I think that is the only two in FAANG that is any good in product / project at a large scale.
- tnr23 6y ago
  It's only Apple. The problem space of Netflix is easy.
- sg47 6y ago
  Apple brute-forces it. They announce or decide to announce a release and do what's needed to meet that date. Netflix relies on people being driven to do the right thing with the consequence that those that don't deliver will be shown the door.
bob33212 6y ago
Projects fail because you have misaligned incentives. The CEO gets a pat on the back when he announces a Technology Modernization project, The Executive team gets a pat on the back when they negotiate 20% off the Modernization Project with IBM. The IBM salesman gets his commission as soon as the deal is signed. Then when the project fails everyone blames someone else. If you want the project to succeed tell all those people that they will get their reward at the end of a successful project not before it has even started.
bobbydreamer 6y ago
Tech projects should be easy to manage buy it fails due to, 1. Because of time sheet. It's either not tracked or questioned or sometimes it's questioned too much. 2. PM is not technical and believes the story being told. 3. PM calls for a meeting and asks for status but doesn't go to each people to collect information who is delaying or is he waiting for someone else's input. Flow is cut somewhere. 4. With sprints, too many managers but all sprints are handled by few Dev's, DBAs and testers. 5. Project changed its course into a discovery journey and everybody is too focused on the side track. All this I have dealt.

76 points by weare138 6y ago

TL;DR: fix hiring (well he doesn't even say that, just "pick the right people" which sadly most of us have only some control over).

Fannon 6y ago
But how could "pick the right" people possibly work out for everyone? Maybe some higher paying / more prestigious companies can do that. But that would still leave the other companies with the original problem and not change anything about the industry wide statistics / problem? However, the author also points out training. So changing the quality of education and the culture around the people can drive this into a better direction.
- anotheryou 6y ago
  The two "under-performing" types I encountered where "hard to work with" and unskilled. Unskilled but smart is not a big problem as long es there are some more senior people. They might not get that much done, but they are still net positive :). And of course they improve if you can hold them for a longer time. People really hard to work with on the other hand are a tough nut and can hold back projects. I think this is often bad hiring. At least a company I worked for hired because they couldn't find anyone better (for the budget) and it turned out to be a big mistake. Either way, you have to live and calculate with what you have. If you do product work however I don't see why deadlines are all that important and would rather focus on the small, most impactful next iteration.
  - loopz 6y ago
    Hard to work with may dissolve if management set a good culture where everyone meet on even terms. Having a few hold all the keys to the kingdom scales badly.
    - anotheryou 6y ago
      Haven't made that experience. I worked in really good cultures where I loved the teams, but that can't always remedy the situation. It's just a drag on everyone: Nobody wants to work with that person, they fail to communicate important things, there are pointless discussions. Even honest communication, mutually agreed on workflows and so on can't always fix things.
  - jon-wood 6y ago
    If you’re doing software product work I’m totally with you on small impactful iterations. When you’re delivering a hardware product this is a lot more difficult to pull off. There are definitely ways to take an agile approach to hardware development, even if you’re working with an OEM, but the outcomes look a lot more like waterfall than your typical Agile with a big A people are comfortable with. The outcome of your iterations are long specification documents (which you’ve already got feedback on from your OEM), and a lot more detail than you’d typically go into development for on the software side since it has to integrate with the actual hardware.
    - anotheryou 6y ago
      Right, I also like waterfall for bigger projects with fix requirements at the end. In fact I also mix agile with waterfall. So much easier to keep adjusting your requirements for a few milestones ahead than to scramble together stories to fill the next sprint every other week.
ccortes 6y ago
I still don't get why most of the recruiting process is left to the HR department. I get they objective is to minimize your distraction as a manager, but it's such an important part of building a good team and it feels that in many cases you (the manager, not necessarily PM) contribute like 20% of the whole process.
- anotheryou 6y ago
  I recently was part of the hiring process for the first time and it was 80% the team, 10% me and 10% HR/boss doing the decision. The person we hired is absolutely awesome :)

Closi 6y ago

> [Research shows that] Only 58% of organizations fully understand the value of Project Management > Why do only 58% of companies value project management? Well, that seems to be taking the research totally out of context in the first paragraph. And then just rambles on about having great people, and having them really well trained in project management. Wow, who would have thought being good at project management and making people better at project management was the solution to getting better at project management!? "Is scope creep the problem? No, thats just a symptom of people again, and training. Did I mention I have a book?" Maybe I'm just cynical here, but there doesn't seem like too much insight here.

konschubert 6y ago

Software projects are development projects, not constructions projects. They are similar to the engineer developing the blueprint for a new machine, not similar to the mechanic assembling it.

ardit33 6y ago
That is a very good point. I think non-technical people can not understand the complexities that go with building new products.
choeger 6y ago
Maybe it becomes time to change that. Less innovation and more repetition could help here. I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. We could achieve such a setup by giving software a lifetime upfront and reimplement it after.
- pbourke 6y ago
  > I bet you, a company that picks a tool stack and develops several similar projects over several years will become better at it. At the end of your several years, your stack will be “outdated,” so you will need to exercise discipline to resist the pressure to keep up with the trends. I like your lifetime idea, though I foresee some hard choices around choosing that timeframe and sticking to your decision to reimplement when the time comes.
  - Findeton 6y ago
    Some things don't change that much. Good luck deprecating Postgres.
- pornel 6y ago
  Physical projects have a construction phase, because they don't have the luxury of zero-cost copying. If you want to construct two identical houses, you still need people to lay bricks twice. If you want two identical websites, you deploy the same files twice. By the nature of software the "construction" part doesn't really apply. If you only replicate already-designed pieces of software, that's more like creating accounts in SaaS or deploying code to new servers.

hungryforcodes 6y ago

He seems to be pushing his book and possibly at the end his school: "Years ago I wrote a book – IT's All about the People: Technology Management That Overcomes Disaffected People, Stupid Processes and Deranged Corporate Cultures – that focused on the human element in technology. The premise is as correct today as it was then." Projects are hard and deal with the unexpected. If you've never done anything like whatever you are trying to do before, you will encounter delays. These are really not failures -- in fact a lot of projects are "finished" with many additional "add on" pieces and enhancements scoped for future work. Tellingly, companies that do the same thing over and over again (video game companies come to mind), are actually pretty good at delivering on time and on budget. With a stable and experienced workforce, the right corporate culture and reusable work breakdown structures, it's all possible.

smarx007 6y ago
Seems like the author finally stopped using the word "suck" while talking about people in print: https://www.goodreads.com/review/show/300695296?book_show_action=true https://www.goodreads.com/review/show/300695296?book_show_ac...
- darkerside 6y ago
  This is an incredibly well written review. Much better than the linked article, which is derivative, vacuous, and full of typos. > Training should be re-invented around practice. Project management residents should learn how and what to do to manage projects successfully, and just like the medical profession, bad project managers should be washed out of their residencies. This seemed to be the only novel idea in the article, and it comes at the end, and is never explained.

mdorazio 6y ago

I spent a lot of years as a PM and PgM, and the general gist of this article seems to be that if you have better PMs your project outcomes will be better. I know HN loves to talk about how much the PMs they've reported to suck, but having worked with many clients on dozens of projects, it's rarely that simple. While bad PMs are definitely way too common, so are bad development teams. And remember that PMs are usually getting shit on from two directions at once (development teams and management teams) with often very little authority to actually fix things. It's usually bad management practices and attitudes that sink projects and make life hell for everyone, and the cause of that is usually lack of understanding and empathy for how software development works. The greatest PM in the world can't help a project if the executive sponsors keep changing scope and requirements or making ridiculous promises to clients to increase sales (and I've seen good PMs quit over this). We don't just need better project management training, we need better management training in general for anyone whose job is dependent on software. Also, companies need to actually be willing to pay for good PMs instead of pulling the cheapest contractor they can find and acting surprised when regurgitating the PMI handbook doesn't actually work.

loopz 6y ago
If management don't understand the projects, and they generally don't, what are they really managing? Oh yeah, get the pay but use position as shield and sword.. You'll see the few exceptions are acting more like a PM, on and off.
- rualca 6y ago
  > If management don't understand the projects, and they generally don't, what are they really managing? With the inception of Agile, by definition software projects are impossible to understand in the sense of having a clear idea regarding concrete goals and risks, technical designs, and timelines. Yet, you will need to manage resource allocation, plan tasks, eliminate risks, and coordinate between stakeholders. That's what a manager does.
  - loopz 6y ago

docflabby 6y ago

Something that always seems to get missed is successful projects are linked to motivation. If everyone in the project is motivated to make it a success it's more likely to be. Use an old technology none of the programmers are interested in and they go find other jobs or not work very hard as they put there efforts into their more interesting side projects.. As an example, projects linked to fulfilling legal requirements normally succeed because the motivation is strong - failure = fine/prison time. Most projects I've seen failure where senior managnent doesn't want the project anymore but need a way of getting rid of it while saving face. Classic way is to pass the project onto another department...

shuringai 6y ago

they had me on the first part then it became clear the article is just a book advertisement

dragonsky 6y ago

I've observed and participated in a reasonable number of projects, both IT and otherwise. In my experience there are two problems that seem to exit in every project that either failed or had to go on to life support: 1. The deliverables were not clearly defined and maintained. How can you deliver something if you don't know what it is? In many cases there is either not a clearly defined and understood deliverable. This leads to every project officer having a different idea as to what they had to deliver leading to disagreements and conflicts and allowing external manipulation and scope creep. 2. People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. How many times have you seen a project team employed to deliver "the new product", only to then have it handed over to the operational support team, who then have to try to work out what this monster is that they have been given and how they are every going to get it to work in the way it was originally specified. You see this a lot when you have a system replacement being designed and developed by an external team, then handed to the people who supported the old system. Who best knows the task the old system was designed to complete, who knows the edge cases and peculiarities that system had to handle, and in most cases, who came up with the work arounds that kept the old system working. If you are going to replace a system, and you are going to maintain your current team to support the new system, then get them working on the development of the new system. Not only will they be invaluable in identifying edge cases that the project architects may not be aware of, but as they are going to be the ones who will have to live with the new system, they will do their bests to make bloody sure that it's going to do what is's supposed to. Oh and make sure they are in a position to call out things that just won't work.

magicalhippo 6y ago
> People who have a vested interest in the successful outcome of the project are not directly involved in the delivery of that project. I see that a lot at work. I can easily spot the birth of a troubled project just by looking if the people who'll be using it is represented or not. In fact just last week I saved our customer a lot of money and pain by pushing on a team leader to get involved in their project to switch ERP solution. I was working on the integration between the new ERP and our program and noticed the users of our program were not involved at all, so leaned on the team lead to rustle her feathers. This team is small but performs an essential job for the company, if they can't do their job things grind to a halt. After the team leader got involved she quickly discovered another department had gotten a change in which would be a complete showstopper for her team. Undoing this change after it had rolled out would have been non-trivial. Fortunately it was still early days in the project. This is the most recent example, but yeah I see it all the time. The ones where the right people aren't involved invariably end up bad in one way or another.

deleted 6y ago

[deleted]

withPurpose9973 6y ago

“I wrote a book on how PM is hard. It starts by hiring the right people. Of course, I wrote a book detailing how all the people involved at scale keep screwing it up. Buy my book.” This a circular advertisement for a book. I am guessing it’s more to with how most organize socially for human emotional reasons first and tacitly don’t give a shit about ephemeral nonsense except to play “Society: The Board Game”.

aitchnyu 6y ago

My pet solution is to use traditional MVC frameworks like Django, Laravel, use Bootstrap stock themes for style, and sprinkle in specific JS wdigets as needed. This will (IME) make day to day work much less chaotic. The chaos of changing business requirements will be amplified when we reimplement API and React for every page and errant JS breaking even scroll. If I can dream, non-tech guys can only mention high-level goals based on data than interface. Instead of the mandate "in one day, reimplement snazzy chart from slick app...", tell "show top 5 contributors" and tech guys can provide an economical solution first and iterate on it later.

jack_riminton 6y ago

It's true that leadership is the key. Projects are successfully lead, not managed. This means leading those above too: getting more resources, communicating and managing expectations The nature of projects is that they're often one-offs or something that the company hasn't done before. So unless you're being very generous with time, scope and quality estimates you're likely to be way off because of optimism bias

hawktheslayer 6y ago

Reading this article calls to mind von Tiesenhausen's Law of Program Management: "To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right."

gonzo41 6y ago

I'm going to go out on a limb and say that smaller project are a possible solution. Do less and deliver something. I've just gotten off two, multi-year projects, the first crashed and burned due to a mismatch between business process, vendors and the skills in the organization to understand what it does and translate that into requirements. From the development side, we made a lot of stuff. Most of it was junk. The second project arrived at a point underdone. Unable to replace the existing production solution because of a lack of a burning deck. I'd put this down as a failure as well. Mostly on the strategic leadership side. In the meta sense these projects weren't that bad. People got money for doing them, and that money was spent in the economy. Maybe Amazon is onto something with their two pizza teams, and 7 page proposals.

mrich 6y ago
Smaller teams, and product management should be done by the development team. This will only work with at least some experienced developers on board who have shipped something before and had to deal with the results of that in production as well. For dedicated product managers the risk is high that the person does not know enough about the product or development. This is especially true in organizations where product management is an "easier" career path compared to development.

ngrilly 6y ago

Poor article in my opinion. The problem described in the article is very true. But the solution, “focus on people”, is mostly tautologic and doesn’t explain at all what makes some projects successful and not others. I’m disappointed.

yowlingcat 6y ago

A key elephant in the room in this article: if it's just about hiring the right people, why is that so hard? Because most companies treat technology as a cost center, not a profit center. Even for companies where that's the case, treating technology like a cost center is like treating legal as a cost center -- existential company killing risk goes way up if you don't pay for the real deal. And for companies where it isn't, you'll just flat out waste your money. Pay for a Yugo when you need a big rig and you'll get exactly what you paid for, which won't be what you need.

blackrock 6y ago

Maybe you should stop thinking your stupid L33T coding interviews will get you the best engineers. And actually interview your engineers for stuff that matters. Like how they achieve redundancy, resilience, and fidelity in their software development. And also, get some managers with half a brain, to understand that changes to the requirements can affect development efforts.

eecks 6y ago

From my experience it all comes down to budget. If IT is a cost, then the ideal thing to do is to deliver while minimizing that cost (duh!). When you do that you get solutions that are the quickest and cheapest thing at that moment. This actually has further impact on other projects because everything is done badly.

acalzycalzy 6y ago

They’ve been managing them since the beginning of technology

nix23 6y ago

Really forbes? https://en.wikipedia.org/wiki/Saturn_V https://en.wikipedia.org/wiki/Saturn_V

ksec 6y ago

My question is, I wonder how Apple does it. Or May be Netflix. I think that is the only two in FAANG that is any good in product / project at a large scale.

tnr23 6y ago
It's only Apple. The problem space of Netflix is easy.
sg47 6y ago
Apple brute-forces it. They announce or decide to announce a release and do what's needed to meet that date. Netflix relies on people being driven to do the right thing with the consequence that those that don't deliver will be shown the door.

bob33212 6y ago

Projects fail because you have misaligned incentives. The CEO gets a pat on the back when he announces a Technology Modernization project, The Executive team gets a pat on the back when they negotiate 20% off the Modernization Project with IBM. The IBM salesman gets his commission as soon as the deal is signed. Then when the project fails everyone blames someone else. If you want the project to succeed tell all those people that they will get their reward at the end of a successful project not before it has even started.

bobbydreamer 6y ago

Tech projects should be easy to manage buy it fails due to, 1. Because of time sheet. It's either not tracked or questioned or sometimes it's questioned too much. 2. PM is not technical and believes the story being told. 3. PM calls for a meeting and asks for status but doesn't go to each people to collect information who is delaying or is he waiting for someone else's input. Flow is cut somewhere. 4. With sprints, too many managers but all sprints are handled by few Dev's, DBAs and testers. 5. Project changed its course into a discovery journey and everybody is too focused on the side track. All this I have dealt.