10 ms·

Project Management Software Can't Save You

74 points by high_5 3y ago

chiefalchemist 3y ago
It can't. But it's not the software's fault leadership & management and their organizations still believe it can. Most don't seem to grasp there's a delta between saying you have a Proj Mgmt tool, and using it. Ideally, using it properly. A SaaS PM tool is not a substitute for actual management. The tool enables the management of projects (read: ultimately that's actually people). The tool does manage itself. And the tool doesn't mean staff can lead and manage themselves either. Like the article's writer I've traveled across a number of agencies the last 8+ years. It's rare to see the software used correctly. That said, it's also rare to see Project Managers and teams properly do PM. Half-ass'ing it is not the road map to success. It might feel ok in the immediate but the corner-cutting is self-defeating. Feels good + Faster !== More effective p.s. Recently, I worked for a client that used Asana. Kinda. Sorta. I logged any / all relevant activity in Asana. When I submitted my first invoice they asked, "Where is the detail?" I replied, "Invoices are the summary of the work. The blow by blow details were logged and tracked in Asana." They didn't get it. Hate the players, not the tools.
- stratigos 3y ago
  Agreed. A business/organisation needs to ask itself, "what truly is someone's motivation to be a project manager?"
  - chiefalchemist 3y ago
    But also to provide them with the authority to do that job. I've been on the wrong end of Project Managers who were closer to Account Managers (i.e., couldn't say no to a client). In fact, I once worked (contract) for an agency where the same person was the AM and the PM. No. Just no. That's like trying to combine oil and water. It doesn't work. And it didn't.
Rochus 3y ago
Previous discussion: https://news.ycombinator.com/item?id=37729065 https://news.ycombinator.com/item?id=37729065
datadrivenangel 3y ago
Business clarity is the only thing that can save you.
- ac2u 3y ago
  Amen, Project Management is helping a team climb a ladder as fast as possible while being aware of scope and risk (like bus factor). Business clarity is both wisely choosing, and convincing the team of the most lucrative ladder for the business to climb.
  - datadrivenangel 3y ago
    And the most common refrain is a paraphrase on "We don't know why we're climbing this ladder, but we're climbing it too slowly!"
    - yetanotherloss 3y ago
      I do a lot of consulting and it's pretty common that the main value we provide is giving a reality check on whether many of these ladders even need to be climbed because all the people involved are focused on how slowly they're getting up and not allowed to step back and see what's supposedly above the top.
- cooperadymas 3y ago
  That sounds great. Is it some sort of Agile tool, or what?
  - datadrivenangel 3y ago
    It's a new cert I'm selling. /s
stratigos 3y ago
No, it will not solve the problem of employee disengagement. Project Management is on the border of being a b.s. job to begin with. I suspect most PMs will be replaced with AI in the next 5 years. Given the low level of skill required to be a PM, and that no one in the universe is passionate about such a "trade," there is no tool that exists that will "save" an organisation. Figuring out the issue of employee disengagement in roles such as this will be of benefit, a tool is just a tool.
- AnimalMuppet 3y ago
  > Given the low level of skill required to be a PM... There's a low level of skill required to be a bad PM. To do it well is rare. It probably requires quite a bit of skill (if it didn't, it would be more common to see it done well).
  - ghaff 3y ago
    It's amazing how contemptuous so many people are about jobs that are different from theirs that they typically know little about.
    - datadrivenangel 3y ago
      Yup. A good project manager makes everything feel smoother and less chaotic, is absolutely worthwhile. Bad project managers just enable micromanagement and amplify the weaknesses of management.
  - fallinditch 3y ago
    I agree that PM software tools can create problems and unnecessary complexity, and tend to be used badly. I believe this is related to a parallel phenomenon in software development: when a 'time and materials' mentality pervades the organization this causes a cascading bunch of adverse effects of overly bureaucratic processes that attempt to estimate and measure everything in far too much detail. The PM software tends to enable and encourage this bureaucratic complexity. The PMs and engineers end up spending large amounts of time navigating the processes and working the PM software tools. Scrum standup meetings can become forums for 'working the system' rather than solving engineering delivery issues. This situation describes a disconnect between agile software delivery and 'time and materials' business. I suggest that organizations should work closely with their PMs to understand this disconnect, use estimation practices that are fit for purpose and not harmful to productivity, and design PM control systems that harness simplicity and truly agile workflows.
VoodooJuJu 3y ago
No, but it's a nice tool game that fools me and others into believing my job isn't bullshit.
Jtsummers 3y ago
> Also called the “waterfall” method, Gantt charts create a visual metaphor of tasks and their dependencies and contingencies so you can see each individual task in terms of when it should start and when it must be completed, relative to the overall project and the tasks coming before it. That's a strange claim. Gantt charts are not a method, so claiming that they're "[a]lso called the “waterfall” method" is bizarre on its face. Gantt charts are a tool. They're a visualization of a schedule: the items, their expected start time, duration, their relation to each other. It's useful for any project management team. You have N issues you need to resolve (Waterfall or not) and some can be done in parallel but others have dependencies? A Gantt chart can help you visualize how the work will play out.
- zabzonk 3y ago
  i agree - of all of the crap-fest of diagrams one comes across, i find gantt charts one of the least obnoxious.
- rqtwteye 3y ago
  After working in too many badly run "agile" environments I really want waterfall to come back. There at least you know where you want to be in a year and how different workstreams fit together. Of course you have to iterate on the plan and respond to changes but that's just common sense in my view.
  - s_dev 3y ago
    I read this and it's just insane to me -- would be like arguing for svn to come back instead of all this 'git' nonsense. The battles were fought and svn lost. Agile became adopted because waterfall is suited for construction projects or factory floors not software development. It accounts for the fact that software developers are very poor estimators (even the best software devs) determining how long things take to build or implement.
    - Shadowmist 3y ago
      Yeah, like construction is known for its ability to deliver on time.
watters 3y ago
It's almost as if the typical contemporary "knowledge work" shop has completely discarded ergonomics, industrial engineering, and library science as potential sources of wisdom about how to construct effective socio-technical systems because they don't have a clear, straight-line, first-order effect on profit.
- hiAndrewQuinn 3y ago
  It's astounding to me how much IE 101 info is just totally absent from software shops. I think it's because nobody who doesn't major in it really knows what industrial engineering is, or just how far the field itself can extend. I wish there was a Freakonomics or Algorithms to Live By for IE.
- klysm 3y ago
  I like the way you expressed first-order effect on profit. It’s difficult to convey such effects to people that don’t understand them.
eschneider 3y ago
Delivering projects on a predicable schedule is EASY. It just requires a few things: * Know what you need to deliver * Know how to build the things you need to deliver * Know how long it takes to make, integrate, and test the components you need to deliver. * Know what resources you have available and how you can distribute the components you need to deliver. * Work for people who aren't going to panic when you tell them up front how long a project will take and why. Surprisingly, the last item can be the hardest one...
- maccard 3y ago
  Disagree, > Know what you need to deliver This is the hardest one (or more importantly, knowing what to say no to)
  - eschneider 3y ago
    Figuring out what you need to deliver is often a subproject all it's own. I used to work at a place that did a lot of fixed-price consulting work and we were small enough that if we blew a bid badly, we were basically dead. We'd often look at the big picture of what the client wanted and offer to break that down into a detailed design and project plan which they could then pay us to implement or hire someone else to do. We used that as an opportunity to figure out what they really wanted/needed.
- wrycoder 3y ago
  And knowing your dependencies and resource loading.
- bluGill 3y ago
  The most important thing: having done hundreds of very similar things before. Any developer can tell you how long a house will take to build from the prints. Same for normal roads and so on. However if you have a custom bridge that has never been done before nobody can really tell you how long it will take or how much it will cost.
  - xnx 3y ago
passwordoops 3y ago
Had a boss when I was a PM somewhere jumping from tool to tool (Aha, LucidChart, etc) using that as a justification for why we didn't have a coherent roadmap. About a week in I finally couldn't take it anymore and blurted something along the lines of "tools are for visualization, if we can't simply put a skeleton of the roadmap in a spreadsheet then we don't understand what we're doing here." We did not have a good working relationship
- MilStdJunkie 3y ago
  Ah I had a really similar interaction with a vendor PM doing a rollout. It was just a bunch of open source kludge stitched together by a proprietary ERP, but there wasn't any kind of overarching . . design? Purpose? Resulted in a late closed door meeting with many payscales where I was told - confidentially, as if in an esoteric ritual - "You're going to need to evangelize System X to the Team" I still remember my actual words: "I'm a lousy preacher. I can't brag on something if I don't even know what we're doin'." Ah, that didn't go well. That vendor had juice all up in and over our org. Smothered and Covered. I thought to myself, I should have taken the collar. But other - more bright - friends of mine said nah - they were looking for scapegoats. So, maybe, maybe, pulling the yellow handle under the seat is the right move when someone forces evangelize into your job description. I waited too long myself, and that particular disaster farm is still a stain on my CV.
dasil003 3y ago
I would strike the word "software" out of the title. To get anything done requires the people with right expertise, clear goals, and roles mapping between them. At some scale communication and coordination becomes a problem, at which point [good] project management is useful. However one must always keep in mind that project management (and the accompanying tools) are not the work. All too often project management becomes the hammer to attempt to paper over gaps in expertise, goals, or role definition. At it's best, project management provides a lightweight layer that makes the overall status and details of a project clearly visible and discoverable by anyone at any time without requiring a meeting or interruption. At it's worst, the structure of what is captured is entirely divorced from both the ground level work and greater business objectives, and is either ignored by the team, or is used as shield to prove they are working hard even if nothing is getting done.
- diracs_stache 3y ago
  Who are you and how are you listening to my internal monologue
firefoxd 3y ago
A VP set a goal to improve efficiency by 10%. The jira team went to work and did their magic. When the fiscal year ended, we had a presentation where it was said that they exceeded expectation. We gained 71 days in productivity, or 19.5%. Yes, there were some changes to jira's workflow, but they completely ignored that the projects we worked on this year were much easier then the last. We built on top of the new system which we had built the year before. The team was more comfortable with the tools now. That's why we were faster. The jira team introduced more ticket statuses which they implied reduced the time tickets spent dormant. Long story short, the uptick in efficiency was a result of building a system then working on the system. But Project management software will take credit because they added some new statuses on tickets. When you keep your eyes on the metrics, you miss forest and the trees.
Joel_Mckay 3y ago
PERT is at its core a risk mitigation process. The node redundancy aspect allows culling unproductive teams, departments, and or entire divisions as needed. And yes, attempting to cost-optimize production of intangible assets is a fools errand. Things cost what they must relative to market conditions, and if something is indeed unfeasible.. no amount of marketing hype will change facts. "TPS Reports" and the meeting with Bob: https://www.youtube.com/watch?v=BTdOHBIppx8 https://www.youtube.com/watch?v=BTdOHBIppx8 =)
imchillyb 3y ago
Since when has PMS saved anyone? A tool is just that. There are varying degrees of tool use from incompetent through proficient. A bad project manager with great tools is still a bad project manager. A good project manager with bad tools is still a good project manager. The ones managing the project can and will make or break most projects. Don’t blame the tools and don’t look to the tools for rescue.
ElevenLathe 3y ago
I think the big problem with stuff like JIRA, Monday.com etc. is that the boss knows about it. Pretty much by definition, a tool that the boss controls will not be one that you have a free hand to optimize your work with. Even if it does help, you're no better off as an employee because that's just the new baseline, and the boss gets all the credit for having forced you to adopt it, rather than you getting the credit for being a diligent employee. Then there are other pieces of software that are really for ICs. I'm in SRE/DevOps type work so for me those are mostly open source things or little tools I've written myself. Chief in my arsenal is Emacs and especially org-mode. It literally does help me do things at work that I couldn't have managed without it: -> remembering to "circle back" on conversations where that was the agreed-upon resolution weeks ago (middle managers and VPs love to "circle back" on the same topic for years with no real decisions being made -- makes no sense but you usually get brownie points for "remembering"). -> keeping executable (via org-babel) notes of finicky operations tasks that haven't been automated yet -- and these notes are also gold if and when the time comes to actually do that automation, since they mostly consist of already-debugged code and notes about corner cases. -> keeping track of deadlines other people (including my boss) forget about. -> organizing my notes about what I worked on in a day so that I can easily fill out my JIRA-based TPS reports before our twice-weekly "standup" with the "project manager" who also covers 10 other teams and has no clue what any of them really do. -> planning around upcoming PTO/holidays/company events/product launches. If all of this stuff were seamlessly tracked by JIRA directly, I would get essentially no personal benefit from it. As it is, and because nobody has any clue about my org-mode system, I look like a hyper-focused and organized employee with a mind like a steel trap. Thinking about this often leads me to wonder if there isn't a market for "secret" productivity software for individual contributors: imagine a slickly-produced analogue of org-mode with built-in JIRA/email/Slack clients. Use your own personal productivity system locally and sync it to shared systems in exactly the way you want, when you want. The main obstacles I see to selling software like this are: -> Closed platforms like Slack don't want interoperability (though JIRA offers "personal access tokens" and you can probably get IMAP access for your corporate email if you push with the IT department) because their business model is about lock-in. -> People are generally not enthusiastic to shell out of their own pocket for work tools, and telling the boss about it to get reimbursed is sort of definitionally out of the question here. -> Corporate InfoSec folks aren't going to like any of this, probably even if it is a client-only executable and the data never leaves company hardware. -> Individual employees generally don't want to buy "erector set" software that requires tons of config, which this problem space kind of inherently requires. Maybe there are solutions to these problems. I dunno. I hope someone works it out, if only so I can be a happy customer.
didip 3y ago
Project management is hard because people are unpredictable. Each person heard the same thing and understood differently. It's probably best to pick and choose a few tools that are complementary and focus on the team building itself.
- datadrivenangel 3y ago
  People tend to be predictable in their unpredictabiltiy (at least on average), so you just do the hard work of overcommunicating and building enough effective progress reviews through the project. This is hard and unsexy work that often goes unnoticed, so people often don't do it.
vegetablepotpie 3y ago
> The MBA-brained idea that management is a skill that transcends individual disciplines is part of PM software’s pitch The part of the ‘MBA-brain’ that these tools take advantage of is that all you need are metrics, if you have the metrics you can manage. It’s a fallacy that that’s all you need. Managers need to understand the work they oversee. Without that, it doesn’t matter whether you use SPI, CPI, velocity, etc. If those metrics aren’t valid, and you don’t know it, you’re not going to make valid decisions.
glonq 3y ago
My boss and I have been working on projects together for almost 20 years. Here is how our [dis]functionality works: 1. He tells me how long the project should take and how much it should cost. 2. I agree not to laugh or to cry. 3. I develop the best thing that we can develop with the best team that I can muster. 4. The project takes twice as long and costs twice as much. 5. My boss agrees to not be too angry, too often. 6. Profit?
anticristi 3y ago
I feel offended that the author didn't bash GitHub and GitLab. The PM features are still small, but I can totally see how they will eventually become the next Asana or Jira to hate.
BariumBlue 3y ago
I've seen office leaders try to shoehorn project management software into their office. There were meetings of, for Jira/Trello, "how can we organize things", or "what's the best way to do this", ... but it all missed the fact that there already WAS no organization, no existing processes, just a wasteland of self-justifying your own work. You can't fit project management software onto an environment like that, and it all repeatedly failed, despite efforts. If the office doesn't already have processes in place, adding software won't fix that problem.
meow_cat 3y ago
I don't get the point the author is trying to make: * The article starts off by arguing that Gantt charts are for factories not for information work; therefore, software providing "bygone ways" of project management (such as Gantt charts) is bad. * Then it criticizes that software that masters multiple project management methodologies is also bad because SaaS companies are trying to make money by adding features. * Then, we find that the issue is that project management software is a simplistic UI in front of a relational database. They don't work because project management is not a problem that can be put into databases. * Then the problem is that the smartphone generation will never understand relational databases because they are used to smooth UIs, and the problem is that there is no undo button. * Next, the problem is that we aren't all thinking like managers, so PM methodologies... don't apply at all to us? * However the supporting example instead says that the problem is that we aren't all thinking like developers, and developers dogfooding their PM software is not necessarily a great selling point for everyone else (this is a take I find somewhat convincing). * Finally, the issue is poor planning, and no software will ever solve it. Maybe I am not commenting on the "most charitable reading" of this article, but it leaves me confused. The author is echoing a broadly-felt frustration with the world of PM tools. They further various criticisms of PM tools, but it feels like they struggle to find what their own criticism actually is.
- vegetablepotpie 3y ago
  The article hit all the main points I would use for a wholesale take-down of Taylorism and all the MBA BS that grew in its wake, but it's presented in a way that you already have to know where the author is coming from to know what they're saying. The key point the article missed is that "management doesn't know jack". The author should have opened with that. Everyone thinks they're boss is an idiot, but why is that? This is important because Taylorism was based on bifurcating the thinkers and the doers into managers and workers respectively. Managers would create the schedule based on their unique knowledge and insight, and workers would carry out their directives without skepticism or doubt. In reality, employees have unique knowledge and insight that management does not possess. Gantt charts, PERT, were all created based on the assumption of management expertise. Knowledge work turned this dynamic around explicitly. Knowledge workers, by definition, know more than their managers. How is a manager going to create a work breakdown structure and a schedule for work they don't understand? MBAs have the answer. The MBA perspective is that management its self is a discrete discipline that can be done in isolation from the work. A good manager, with the management skill set can just as easily manage a hospital, as they can an airport, a shoe factory, a fast food franchise, or a nuclear power plant. This is done through metrics. By measuring performance, the manager can know where and when to conduct corrective actions to satisfy metrics. The metrics are ultimately tied to progress on schedules, WBSs, Gantt charts etc. If these don't map to your projects, the metrics they generate are useless. They will guide managers to make misapplied corrective actions that miss the mark and prevent work from happening, rather than correct any under-performance. For project management tools, doesn't matter that the interfaces are nicer. It doesn't matter how they're implemented on the back end. It doesn't matter if the companies that make them also use their own products. The fact that your project doesn't map well to a prescribed schedule, or that you're laser focused on KPIs that don't matter. None of that changes anything. The core assumptions these tools are based on are wrong. They don't care, they just want your money.

74 points by high_5 3y ago

It can't. But it's not the software's fault leadership & management and their organizations still believe it can. Most don't seem to grasp there's a delta between saying you have a Proj Mgmt tool, and using it. Ideally, using it properly. A SaaS PM tool is not a substitute for actual management. The tool enables the management of projects (read: ultimately that's actually people). The tool does manage itself. And the tool doesn't mean staff can lead and manage themselves either. Like the article's writer I've traveled across a number of agencies the last 8+ years. It's rare to see the software used correctly. That said, it's also rare to see Project Managers and teams properly do PM. Half-ass'ing it is not the road map to success. It might feel ok in the immediate but the corner-cutting is self-defeating. Feels good + Faster !== More effective p.s. Recently, I worked for a client that used Asana. Kinda. Sorta. I logged any / all relevant activity in Asana. When I submitted my first invoice they asked, "Where is the detail?" I replied, "Invoices are the summary of the work. The blow by blow details were logged and tracked in Asana." They didn't get it. Hate the players, not the tools.

stratigos 3y ago
Agreed. A business/organisation needs to ask itself, "what truly is someone's motivation to be a project manager?"
- chiefalchemist 3y ago
  But also to provide them with the authority to do that job. I've been on the wrong end of Project Managers who were closer to Account Managers (i.e., couldn't say no to a client). In fact, I once worked (contract) for an agency where the same person was the AM and the PM. No. Just no. That's like trying to combine oil and water. It doesn't work. And it didn't.

Rochus 3y ago

Previous discussion: https://news.ycombinator.com/item?id=37729065 https://news.ycombinator.com/item?id=37729065

datadrivenangel 3y ago

Business clarity is the only thing that can save you.

ac2u 3y ago
Amen, Project Management is helping a team climb a ladder as fast as possible while being aware of scope and risk (like bus factor). Business clarity is both wisely choosing, and convincing the team of the most lucrative ladder for the business to climb.
- datadrivenangel 3y ago
  And the most common refrain is a paraphrase on "We don't know why we're climbing this ladder, but we're climbing it too slowly!"
  - yetanotherloss 3y ago
    I do a lot of consulting and it's pretty common that the main value we provide is giving a reality check on whether many of these ladders even need to be climbed because all the people involved are focused on how slowly they're getting up and not allowed to step back and see what's supposedly above the top.
cooperadymas 3y ago
That sounds great. Is it some sort of Agile tool, or what?
- datadrivenangel 3y ago
  It's a new cert I'm selling. /s

stratigos 3y ago

No, it will not solve the problem of employee disengagement. Project Management is on the border of being a b.s. job to begin with. I suspect most PMs will be replaced with AI in the next 5 years. Given the low level of skill required to be a PM, and that no one in the universe is passionate about such a "trade," there is no tool that exists that will "save" an organisation. Figuring out the issue of employee disengagement in roles such as this will be of benefit, a tool is just a tool.

AnimalMuppet 3y ago
> Given the low level of skill required to be a PM... There's a low level of skill required to be a bad PM. To do it well is rare. It probably requires quite a bit of skill (if it didn't, it would be more common to see it done well).
- ghaff 3y ago
  It's amazing how contemptuous so many people are about jobs that are different from theirs that they typically know little about.
  - datadrivenangel 3y ago
    Yup. A good project manager makes everything feel smoother and less chaotic, is absolutely worthwhile. Bad project managers just enable micromanagement and amplify the weaknesses of management.
- fallinditch 3y ago
  I agree that PM software tools can create problems and unnecessary complexity, and tend to be used badly. I believe this is related to a parallel phenomenon in software development: when a 'time and materials' mentality pervades the organization this causes a cascading bunch of adverse effects of overly bureaucratic processes that attempt to estimate and measure everything in far too much detail. The PM software tends to enable and encourage this bureaucratic complexity. The PMs and engineers end up spending large amounts of time navigating the processes and working the PM software tools. Scrum standup meetings can become forums for 'working the system' rather than solving engineering delivery issues. This situation describes a disconnect between agile software delivery and 'time and materials' business. I suggest that organizations should work closely with their PMs to understand this disconnect, use estimation practices that are fit for purpose and not harmful to productivity, and design PM control systems that harness simplicity and truly agile workflows.

VoodooJuJu 3y ago

No, but it's a nice tool game that fools me and others into believing my job isn't bullshit.

Jtsummers 3y ago

> Also called the “waterfall” method, Gantt charts create a visual metaphor of tasks and their dependencies and contingencies so you can see each individual task in terms of when it should start and when it must be completed, relative to the overall project and the tasks coming before it. That's a strange claim. Gantt charts are not a method, so claiming that they're "[a]lso called the “waterfall” method" is bizarre on its face. Gantt charts are a tool. They're a visualization of a schedule: the items, their expected start time, duration, their relation to each other. It's useful for any project management team. You have N issues you need to resolve (Waterfall or not) and some can be done in parallel but others have dependencies? A Gantt chart can help you visualize how the work will play out.

zabzonk 3y ago
i agree - of all of the crap-fest of diagrams one comes across, i find gantt charts one of the least obnoxious.
rqtwteye 3y ago
After working in too many badly run "agile" environments I really want waterfall to come back. There at least you know where you want to be in a year and how different workstreams fit together. Of course you have to iterate on the plan and respond to changes but that's just common sense in my view.
- s_dev 3y ago
  I read this and it's just insane to me -- would be like arguing for svn to come back instead of all this 'git' nonsense. The battles were fought and svn lost. Agile became adopted because waterfall is suited for construction projects or factory floors not software development. It accounts for the fact that software developers are very poor estimators (even the best software devs) determining how long things take to build or implement.
  - Shadowmist 3y ago
    Yeah, like construction is known for its ability to deliver on time.

watters 3y ago

It's almost as if the typical contemporary "knowledge work" shop has completely discarded ergonomics, industrial engineering, and library science as potential sources of wisdom about how to construct effective socio-technical systems because they don't have a clear, straight-line, first-order effect on profit.

hiAndrewQuinn 3y ago
It's astounding to me how much IE 101 info is just totally absent from software shops. I think it's because nobody who doesn't major in it really knows what industrial engineering is, or just how far the field itself can extend. I wish there was a Freakonomics or Algorithms to Live By for IE.
klysm 3y ago
I like the way you expressed first-order effect on profit. It’s difficult to convey such effects to people that don’t understand them.

eschneider 3y ago

Delivering projects on a predicable schedule is EASY. It just requires a few things: * Know what you need to deliver * Know how to build the things you need to deliver * Know how long it takes to make, integrate, and test the components you need to deliver. * Know what resources you have available and how you can distribute the components you need to deliver. * Work for people who aren't going to panic when you tell them up front how long a project will take and why. Surprisingly, the last item can be the hardest one...

maccard 3y ago
Disagree, > Know what you need to deliver This is the hardest one (or more importantly, knowing what to say no to)
- eschneider 3y ago
  Figuring out what you need to deliver is often a subproject all it's own. I used to work at a place that did a lot of fixed-price consulting work and we were small enough that if we blew a bid badly, we were basically dead. We'd often look at the big picture of what the client wanted and offer to break that down into a detailed design and project plan which they could then pay us to implement or hire someone else to do. We used that as an opportunity to figure out what they really wanted/needed.
wrycoder 3y ago
And knowing your dependencies and resource loading.
bluGill 3y ago
The most important thing: having done hundreds of very similar things before. Any developer can tell you how long a house will take to build from the prints. Same for normal roads and so on. However if you have a custom bridge that has never been done before nobody can really tell you how long it will take or how much it will cost.
- xnx 3y ago

passwordoops 3y ago

Had a boss when I was a PM somewhere jumping from tool to tool (Aha, LucidChart, etc) using that as a justification for why we didn't have a coherent roadmap. About a week in I finally couldn't take it anymore and blurted something along the lines of "tools are for visualization, if we can't simply put a skeleton of the roadmap in a spreadsheet then we don't understand what we're doing here." We did not have a good working relationship

MilStdJunkie 3y ago
Ah I had a really similar interaction with a vendor PM doing a rollout. It was just a bunch of open source kludge stitched together by a proprietary ERP, but there wasn't any kind of overarching . . design? Purpose? Resulted in a late closed door meeting with many payscales where I was told - confidentially, as if in an esoteric ritual - "You're going to need to evangelize System X to the Team" I still remember my actual words: "I'm a lousy preacher. I can't brag on something if I don't even know what we're doin'." Ah, that didn't go well. That vendor had juice all up in and over our org. Smothered and Covered. I thought to myself, I should have taken the collar. But other - more bright - friends of mine said nah - they were looking for scapegoats. So, maybe, maybe, pulling the yellow handle under the seat is the right move when someone forces evangelize into your job description. I waited too long myself, and that particular disaster farm is still a stain on my CV.

dasil003 3y ago

I would strike the word "software" out of the title. To get anything done requires the people with right expertise, clear goals, and roles mapping between them. At some scale communication and coordination becomes a problem, at which point [good] project management is useful. However one must always keep in mind that project management (and the accompanying tools) are not the work. All too often project management becomes the hammer to attempt to paper over gaps in expertise, goals, or role definition. At it's best, project management provides a lightweight layer that makes the overall status and details of a project clearly visible and discoverable by anyone at any time without requiring a meeting or interruption. At it's worst, the structure of what is captured is entirely divorced from both the ground level work and greater business objectives, and is either ignored by the team, or is used as shield to prove they are working hard even if nothing is getting done.

diracs_stache 3y ago
Who are you and how are you listening to my internal monologue

firefoxd 3y ago

A VP set a goal to improve efficiency by 10%. The jira team went to work and did their magic. When the fiscal year ended, we had a presentation where it was said that they exceeded expectation. We gained 71 days in productivity, or 19.5%. Yes, there were some changes to jira's workflow, but they completely ignored that the projects we worked on this year were much easier then the last. We built on top of the new system which we had built the year before. The team was more comfortable with the tools now. That's why we were faster. The jira team introduced more ticket statuses which they implied reduced the time tickets spent dormant. Long story short, the uptick in efficiency was a result of building a system then working on the system. But Project management software will take credit because they added some new statuses on tickets. When you keep your eyes on the metrics, you miss forest and the trees.

Joel_Mckay 3y ago

PERT is at its core a risk mitigation process. The node redundancy aspect allows culling unproductive teams, departments, and or entire divisions as needed. And yes, attempting to cost-optimize production of intangible assets is a fools errand. Things cost what they must relative to market conditions, and if something is indeed unfeasible.. no amount of marketing hype will change facts. "TPS Reports" and the meeting with Bob: https://www.youtube.com/watch?v=BTdOHBIppx8 https://www.youtube.com/watch?v=BTdOHBIppx8 =)

imchillyb 3y ago

Since when has PMS saved anyone? A tool is just that. There are varying degrees of tool use from incompetent through proficient. A bad project manager with great tools is still a bad project manager. A good project manager with bad tools is still a good project manager. The ones managing the project can and will make or break most projects. Don’t blame the tools and don’t look to the tools for rescue.

ElevenLathe 3y ago

I think the big problem with stuff like JIRA, Monday.com etc. is that the boss knows about it. Pretty much by definition, a tool that the boss controls will not be one that you have a free hand to optimize your work with. Even if it does help, you're no better off as an employee because that's just the new baseline, and the boss gets all the credit for having forced you to adopt it, rather than you getting the credit for being a diligent employee. Then there are other pieces of software that are really for ICs. I'm in SRE/DevOps type work so for me those are mostly open source things or little tools I've written myself. Chief in my arsenal is Emacs and especially org-mode. It literally does help me do things at work that I couldn't have managed without it: -> remembering to "circle back" on conversations where that was the agreed-upon resolution weeks ago (middle managers and VPs love to "circle back" on the same topic for years with no real decisions being made -- makes no sense but you usually get brownie points for "remembering"). -> keeping executable (via org-babel) notes of finicky operations tasks that haven't been automated yet -- and these notes are also gold if and when the time comes to actually do that automation, since they mostly consist of already-debugged code and notes about corner cases. -> keeping track of deadlines other people (including my boss) forget about. -> organizing my notes about what I worked on in a day so that I can easily fill out my JIRA-based TPS reports before our twice-weekly "standup" with the "project manager" who also covers 10 other teams and has no clue what any of them really do. -> planning around upcoming PTO/holidays/company events/product launches. If all of this stuff were seamlessly tracked by JIRA directly, I would get essentially no personal benefit from it. As it is, and because nobody has any clue about my org-mode system, I look like a hyper-focused and organized employee with a mind like a steel trap. Thinking about this often leads me to wonder if there isn't a market for "secret" productivity software for individual contributors: imagine a slickly-produced analogue of org-mode with built-in JIRA/email/Slack clients. Use your own personal productivity system locally and sync it to shared systems in exactly the way you want, when you want. The main obstacles I see to selling software like this are: -> Closed platforms like Slack don't want interoperability (though JIRA offers "personal access tokens" and you can probably get IMAP access for your corporate email if you push with the IT department) because their business model is about lock-in. -> People are generally not enthusiastic to shell out of their own pocket for work tools, and telling the boss about it to get reimbursed is sort of definitionally out of the question here. -> Corporate InfoSec folks aren't going to like any of this, probably even if it is a client-only executable and the data never leaves company hardware. -> Individual employees generally don't want to buy "erector set" software that requires tons of config, which this problem space kind of inherently requires. Maybe there are solutions to these problems. I dunno. I hope someone works it out, if only so I can be a happy customer.

didip 3y ago

Project management is hard because people are unpredictable. Each person heard the same thing and understood differently. It's probably best to pick and choose a few tools that are complementary and focus on the team building itself.

datadrivenangel 3y ago
People tend to be predictable in their unpredictabiltiy (at least on average), so you just do the hard work of overcommunicating and building enough effective progress reviews through the project. This is hard and unsexy work that often goes unnoticed, so people often don't do it.

vegetablepotpie 3y ago

> The MBA-brained idea that management is a skill that transcends individual disciplines is part of PM software’s pitch The part of the ‘MBA-brain’ that these tools take advantage of is that all you need are metrics, if you have the metrics you can manage. It’s a fallacy that that’s all you need. Managers need to understand the work they oversee. Without that, it doesn’t matter whether you use SPI, CPI, velocity, etc. If those metrics aren’t valid, and you don’t know it, you’re not going to make valid decisions.

glonq 3y ago

My boss and I have been working on projects together for almost 20 years. Here is how our [dis]functionality works: 1. He tells me how long the project should take and how much it should cost. 2. I agree not to laugh or to cry. 3. I develop the best thing that we can develop with the best team that I can muster. 4. The project takes twice as long and costs twice as much. 5. My boss agrees to not be too angry, too often. 6. Profit?

anticristi 3y ago

I feel offended that the author didn't bash GitHub and GitLab. The PM features are still small, but I can totally see how they will eventually become the next Asana or Jira to hate.

BariumBlue 3y ago

I've seen office leaders try to shoehorn project management software into their office. There were meetings of, for Jira/Trello, "how can we organize things", or "what's the best way to do this", ... but it all missed the fact that there already WAS no organization, no existing processes, just a wasteland of self-justifying your own work. You can't fit project management software onto an environment like that, and it all repeatedly failed, despite efforts. If the office doesn't already have processes in place, adding software won't fix that problem.

meow_cat 3y ago

I don't get the point the author is trying to make: * The article starts off by arguing that Gantt charts are for factories not for information work; therefore, software providing "bygone ways" of project management (such as Gantt charts) is bad. * Then it criticizes that software that masters multiple project management methodologies is also bad because SaaS companies are trying to make money by adding features. * Then, we find that the issue is that project management software is a simplistic UI in front of a relational database. They don't work because project management is not a problem that can be put into databases. * Then the problem is that the smartphone generation will never understand relational databases because they are used to smooth UIs, and the problem is that there is no undo button. * Next, the problem is that we aren't all thinking like managers, so PM methodologies... don't apply at all to us? * However the supporting example instead says that the problem is that we aren't all thinking like developers, and developers dogfooding their PM software is not necessarily a great selling point for everyone else (this is a take I find somewhat convincing). * Finally, the issue is poor planning, and no software will ever solve it. Maybe I am not commenting on the "most charitable reading" of this article, but it leaves me confused. The author is echoing a broadly-felt frustration with the world of PM tools. They further various criticisms of PM tools, but it feels like they struggle to find what their own criticism actually is.

vegetablepotpie 3y ago
The article hit all the main points I would use for a wholesale take-down of Taylorism and all the MBA BS that grew in its wake, but it's presented in a way that you already have to know where the author is coming from to know what they're saying. The key point the article missed is that "management doesn't know jack". The author should have opened with that. Everyone thinks they're boss is an idiot, but why is that? This is important because Taylorism was based on bifurcating the thinkers and the doers into managers and workers respectively. Managers would create the schedule based on their unique knowledge and insight, and workers would carry out their directives without skepticism or doubt. In reality, employees have unique knowledge and insight that management does not possess. Gantt charts, PERT, were all created based on the assumption of management expertise. Knowledge work turned this dynamic around explicitly. Knowledge workers, by definition, know more than their managers. How is a manager going to create a work breakdown structure and a schedule for work they don't understand? MBAs have the answer. The MBA perspective is that management its self is a discrete discipline that can be done in isolation from the work. A good manager, with the management skill set can just as easily manage a hospital, as they can an airport, a shoe factory, a fast food franchise, or a nuclear power plant. This is done through metrics. By measuring performance, the manager can know where and when to conduct corrective actions to satisfy metrics. The metrics are ultimately tied to progress on schedules, WBSs, Gantt charts etc. If these don't map to your projects, the metrics they generate are useless. They will guide managers to make misapplied corrective actions that miss the mark and prevent work from happening, rather than correct any under-performance. For project management tools, doesn't matter that the interfaces are nicer. It doesn't matter how they're implemented on the back end. It doesn't matter if the companies that make them also use their own products. The fact that your project doesn't map well to a prescribed schedule, or that you're laser focused on KPIs that don't matter. None of that changes anything. The core assumptions these tools are based on are wrong. They don't care, they just want your money.