[HN Gopher] A critique of project management software
___________________________________________________________________
A critique of project management software
Author : qudat
Score : 64 points
Date : 2021-09-02 04:10 UTC (1 days ago)
(HTM) web link (erock.io)
(TXT) w3m dump (erock.io)
| imbnwa wrote:
| PM software basically reflects the level of disinterest and
| demoralization in an organization.
| qudat wrote:
| Author here! Happy to answer any questions about the article or
| the product idea I'm thinking about building: wormhole.
|
| I'll be writing more articles about the product idea to make it
| more clear what I want to build. Happy to read any feedback or if
| I'm wasting my time!
| svilen_dobrev wrote:
| Can one say that circles are/can be used like tags, in a way?
| That is, Can one task belong to multiple circles? Think of
| aspects..
|
| it's something i have always been missing, the graph-like
| nature of all these things, always being bricked into some
| tree-or-list-like single-parent stiff structure..
| qudat wrote:
| With my current thinking about how circles can work, a circle
| can reference another circle. So in a way, one task (circle)
| can belong to multiple circles. It's similar to how Workflowy
| allows the user to mirror list items.
| mallahan wrote:
| It looks great - it seems to add dashboard functionality to the
| infinite nesting idea of workflowy.com which gets the nesting
| right, but is missing metadata & dashboard tools (and an API).
| qudat wrote:
| Exactly! This product idea is the brain child of Workflowy,
| Basecampe, and Clubhouse ... combining all the features that
| I love from all of them into one product.
| mch82 wrote:
| I'm curious why Microsoft Project is not included on the list
| of project management software packages? Skip the default Gantt
| view, but the Activity Network view contains a lot of useful
| features. It's based on the PERT technique that comes from
| Operations Research.
| qudat wrote:
| I'll add it to the list, thank you!
| roland35 wrote:
| Have you tried Wrike at all? Of all the project management
| tools I've used I enjoyed Wrike the most.
|
| What I liked most about it is that you can combine the same
| tasks together in multiple places... which helps me since many
| tasks don't always fit in a single hierarchy. I.e. a circuit
| board design could be in the "electronics" folder, but also
| could be part of a specific prototype build.
| qudat wrote:
| I have not, I'll add it to my short list of software to demo.
| Thanks!
| snovv_crash wrote:
| Wrike has a horrifically slow UI. It's impossible to run a
| sprint planning on it, or to quickly go through what's in
| progress during a stand-up.
|
| It's actually slower than JIRA, which is impressive.
| nkko wrote:
| I would say that the author is onto something here. There is
| obviously pain present. I have used Jira in various weird
| scenarios, most recently I have created a setup for accounting
| operations to track client work and repetitive tasks with some
| automation also. It forced Jira a little bit but at the end
| people are using it and appreciating it. The thing is that you
| just need to spend some time thinking about it from the user
| perspective. Having something flexible with unrestricted
| hierarchy and smart linking with some possibility of automation
| would be grand.
| 2bitlobster wrote:
| There is usually some point several times a year where things get
| hairy, and I need to do an analysis within a spreadsheet (ie sort
| tickets by effort + value to evaluate priority). Still haven't
| seen a tool that lets me quickly evaluate many tickets easily
| without config hell.
| qudat wrote:
| Totally agree and thanks for the feedback! I'll keep this in
| mind if I decide to build this product.
| robertq wrote:
| We use Redmine (https://www.redmine.org/) for issue management
| and bug tracking. Self-hosted, simple, can have multiple projects
| with user specific access, and there are free and paid plugins if
| you need Trello boards and Agile tracking.
|
| Some of our clients use MS TFS and it's a complicated mess
| dec0dedab0de wrote:
| My biggest problem with using these tools is mandates forced by
| someone in the company that no one on my team has ever met. As
| another commenter pointed out, I just want a big checklist, with
| sub check lists, and a handful of properties, that i can create
| update and delete at will.
|
| Instead of being a tool to help us do our job more efficiently,
| it has become a source of busy work, that requires extra
| employees to use properly.
|
| After switching to Jira it was so locked down with arbitrary
| rules that I need to take a break every time I use it.
|
| I'm seriously considering looking for a new job that doesn't use
| a corporately mandated system, or have daily stand ups.
| gego wrote:
| I totally feel you, I sometimes just set up a local Redmine or
| simple task list in the lan that really gets used while I make
| the entries in whatever our corp gods decree the flavor of the
| month...
| liketochill wrote:
| I've been using Redmine for nearly a decade. Download the
| bitnami VM with it preinstalled and away I go. I use it for
| all my time tracking to generate invoices, and project
| estimates. Then when working on the project I can put time
| against an existing estimates task or if I missed something
| in the estimate or something was added I'll create a new task
| for the extra.
|
| Works great and I love that the UI hasn't been redesigned and
| just works.
| vosper wrote:
| IME this is a problem of policy, not of Jira. Empower teams to
| administer their own Jira projects and it's fine. But if you
| lock Jira down and make people beg to some distant and aloof
| gatekeeper every time they want to change anything, then it's a
| recipe for frustration.
|
| Having IT own Jira administration is great for IT job security
| and terrible for everyone else.
|
| (Note: old Jira absolutely encouraged a one-size-fits-all
| approach to administration. Everything was done with the
| assumption that it would be cross-project, which created a
| morass of assigning things things. "New" Jira project are more
| self-contained, and so much easier to configure)
| robertlagrant wrote:
| Yes, this. I wasn't recognising anyone's problems with Jira,
| and this is probably why.
| ElFitz wrote:
| Yeah. Another of the issues is that it's picked by people who
| (supposedly) chose the right tool for them, without considering
| wether or not it was optimised for those actually doing the
| tasks.
|
| At least that's how I ended up with boards that absolutely
| didn't match my workflow and required me to copy / paste tasks
| from one board to the other to pass it off to the next step
| (QA), with QA feedback via Slack.
|
| That's not quite my ideal "single source of truth" regarding
| what I have to do.
| robertlagrant wrote:
| It's possible to misconfigure any tool, that's for sure.
| nradov wrote:
| A big checklist of planned changes can work fine for a small
| team with a single product. It breaks down when you have many
| teams working on a whole portfolio of products with
| interdependencies and external customer commitments. In that
| situation a tool like Jira or Rally is usually the least bad
| option (unless your organization is huge enough to justify
| building your own custom project management tool that precisely
| meets your needs).
| ethbr0 wrote:
| There are two things I've decided are true, regarding project
| management.
|
| #1 - "Those who manage best, manage least." Spend the minimal
| amount of time on project management. Even project managers
| should spend a minimal amount of _their_ time "project
| managing," which leads directly to #2...
|
| #2 - "Project manager is a task, not a job." No one in the
| company should be a "project manager," and nothing else.
|
| The rationale is that if project management is a job, project
| management becomes the sole work output. And optimizing for
| that output leads to all the worst excesses I've seen at
| companies. And consequently, all the shit products (or shit
| design choices within good products) listed.
|
| If you have a perfectly tracked project that took 100s of
| person-hours to generate and update tracking docs, what does
| that do for your end users?
|
| People do their jobs. Make sure everyone's ultimate job is to
| bring value to the company.
|
| PS: And to head off the complaint that this ignores project
| scale, your company is not IBM. You don't have the management
| problems 1960s IBM had. So stop using solutions to "How do I
| orchestrate the progress of 100s of developers all working on
| the same project?!" Because the number of projects that large,
| that can't be broken into subprojects, is very few.
| travisjungroth wrote:
| I've kicked around the idea that project manager should be a
| very low level job. Like first job out of college or maybe
| high school. The job would be: make sure the current state of
| the project is reflected in our software. No predicting the
| future (burndown, gantt), no changing the future (make sure
| it gets done on time) and no responsibility without authority
| trap. I think one person could support a very large project
| (or more smaller ones) this way.
|
| And why do it? So proper data is in the project management
| tool. Then people with the actual correct
| responsibility/authority/expertise can make good decisions
| based on good data.
|
| Also cuts down on interruptions. You go from quadratic
| communication (M stakeholders pinging N engineers) to linear
| (M stakeholders consuming 1 feed that's fed by N engineers).
| _In theory_ , everyone just keeping their tickets up-to-date
| would get rid of that need. History has shown that doesn't
| work. Also a sufficiently smart tool would cover it, but it
| hasn't been made yet. Maybe a 20-year-old who sits in on
| meetings, gets a notification for every PR state change and
| nicely asks people how things are going would do a better
| job.
| jrodthree24 wrote:
| This also applies to how we work too.
|
| Everyone is having a blast doing SCRUM until some manager
| decides it would be cool for them to keep track of how many
| story points the team completes as some sort of performance
| metric.
| qudat wrote:
| > Instead of being a tool to help us do our job more
| efficiently, it has become a source of busy work, that requires
| extra employees to use properly.
|
| Author here. I totally agree with you. We are currently using
| JIRA at Aptible and the general consensus is to use it as
| little as possible. I'd much rather have a system that is
| streamlined around delegating tasks to teammates and then a
| playground for the independent contributors to figure out how
| they want to break the tasks down.
|
| I'm definitely keeping your feedback in mind if I continue to
| build this prototype out. If you'd like to receive updates
| about my progress, signup with your email at the bottom of the
| blog article.
|
| Thanks!
| correstco wrote:
| I just logged into HN to mention Todoist.
|
| I have a hobby of trying out different project management
| software and I even went back to a pen and paper notebook for a
| while.
|
| But I've become a huge fan and advocate of Todoist. So
| lightweight yet very flexible.
|
| *sorry if this sounds like a marketing message. I don't work for
| the company or know anyone that does. I'm not invested in the
| company other than a happy customer.
| travisjungroth wrote:
| I've been a serious Todoist user for years. I even built an
| extension app[1]. Todoist wins on number and ease of
| interfaces. _Today_ I 've used it on a desktop app, web app,
| phone, watch and CLI. It totally loses on complex cases (many
| people, subprojects, dependencies, integrations). I've found
| that using it with just one other person (an assistant) is
| stretching it, and a team is right out.
|
| [1]https://habitsfortodoist.com/
| OJFord wrote:
| Didn't Microsoft buy it and kill it into Teams Tasks or
| something?
| apple4ever wrote:
| That was Wunderlist. I used that first, until they killed it.
| Then I switched to Todoist, so I second the OP's
| recommendation!
| [deleted]
| ziggus wrote:
| I'm confused: the list of 'project management software' is a list
| of task management software. None of those is for managing
| projects.
| ravenstine wrote:
| I've used Jira, Pivotal Tracker, Trello, Asana, Zenhub, and other
| project management software that was written internally.
|
| In my opinion, based on my needs on every project I've worked on,
| I've yet to use a project management software that did anything
| better than a simple Trello board or the like. At the end of the
| day, I want a list of tasks, a way to indicate the status on the
| task, a discussion section for the task, and to be able to close
| it when I'm finished. That's about 99% of what I need it for.
| Well, besides the fact that it also should provide insight to
| management.
|
| My issue with project management software that's more complicated
| than a set of to-do lists is that they seem to be designed to
| make you invest in that specific product. They are different
| enough from each other in terms of layout and workflow that they
| are unique yet those differences offer no clear value. Depending
| on which one you use, you have a "task", or a "story", or a
| "ticket", or an "issue", or something entirely unique if it was
| written by some clever person for internal PM software.
|
| Then there are concepts like "milestones", "epics", "iterations",
| and "sprints" (speaking of more concepts I've never needed). You
| might be "assigned" a task, or perhaps you are the "owner". It's
| all so tainted by Agile that we have to speak this goofy ass
| language which makes us feel more sophisticated than the rest of
| the world which... does the same thing using common verbage.
|
| Worst of all is these tools have barely any meaningful
| integration with source control hosting like GitHub or GitLab.
| Yes, they can do nifty things like show the title of the GitHub
| issue, but every place I've worked for forced me to ping pong
| between the PM software and GitHub/Lab and I always ended up
| having to manually sync things between the two. Or I would have
| to manually copy information between the PM software and whatever
| non-engineers were using, like Asana.
|
| Like, I really don't care that badly about having to sync some
| things by hand, but it's a nuisance when the tool pretends to be
| advanced by shoving a bunch of information, terminology, and
| processes in my face. Give me a tool that will stay out of my
| way.
|
| ---
|
| Oh, yes, the article.
|
| > The thing I really like about this idea is that the user can
| organize their hierarchy however they like. They are not
| restricted to what the software defines as an "epic."
|
| Yep, exactly. It should _get out of the way_ and not force
| organizations or individuals into hard and fast paradigms. Funny
| how we overuse abstractions in code but our project management
| tools are overly concrete.
|
| > Want to create a sprint? Create a circle and reference other
| circles within it. Want to create an epic? Create a circle and
| reference other circles within it. Want to view your circle and
| its children as a kanban? It supports that. Want to move circles
| around, such as nesting them or unnesting them? It's as easy as
| pressing "tab" or "shift+tab."
|
| Although obviously I'm not a fan of adding more neologisms, the
| way that circles work here definitely sounds appealing in terms
| of flexibility. In this case, it kind of makes sense since a
| circle doesn't necessarily have to represent anything in
| particular besides what the user wants it to be.
|
| > I want a project management solution that:
|
| > - Emphasizes team collaboration
|
| > - Is able to scale with a company's growth
|
| > - A playground for teams to experiment and build tasks
|
| > - Ability to capture OKRs (objectives and key results)
|
| > - Task management
|
| Most project management software claims to do most of those
| things. Not that you aren't right in wanting those things, but
| the possibilities circles have is the main selling point IMO.
| Aalk4308 wrote:
| Amen ravenstine. "A tool that stays out of your team's way" is
| quite literally the tagline of the Trello-for-devs product I'm
| working on (Constructor, https://constructor.dev/).
|
| As to the article, I agree with a lot of the author's points.
| The author talks about lack of features for collaboration. and
| I agree. What's wrong with the comment systems in Trello or
| Jira? I think it's that they don't model how people actually
| collaborate, which often goes something like this: (1) I have a
| question for someone else on the team, (2) that person answers
| or passes it to someone else who can, (3) repeat until I've got
| the answer, (4) reflect the answer somewhere (designs,
| description, etc.), (5) consider the matter resolved. Many of
| these might be going on in parallel, and the back-and-forth is
| often asynchronous. A single comment stream just doesn't lend
| itself to this kind of collaboration. Neither does Slack where,
| as the author says, requests for follow-up easily get lost.
|
| The extreme flexibility of the "circles" is interesting. On the
| one hand, it's nice to give control over to the users and let
| them model whatever use case they have. On the other, a tool
| that's too open-ended may overwhelm users with options when
| they should really be focusing on dev. (Of course, that could
| be solved with intelligent default templates, or something
| along those lines.) I'm curious to read others thoughts about
| that.
| qudat wrote:
| > On the other, a tool that's too open-ended may overwhelm
| users with options when they should really be focusing on
| dev.
|
| Author here. I agree. A big concern is I build this flexible
| system and a user jumps in to use it and sees a blank screen.
| No story section, no sprint section, no epic section. They
| get bewildered and end up not using it. Do you have any other
| thoughts on how to combat users being overwhelmed by a blank
| screen? I could have templates that people could "load" that
| would set a project up like a traditional project mgmt
| solution would?
| Aalk4308 wrote:
| Yeah, templates for "traditional" structures sounds
| reasonable. Or along the same lines, it might be sufficient
| to have purely illustrative versions of those setups
| ("here's how some teams have used this"), to get the idea
| across, even if they can't be "loaded" as a template.
| tyingq wrote:
| I agree that's there's lots of work that fits into a simple
| Kanban view well.
|
| I do, though, often see stuff managed using Kanban when it's
| pretty clear that there are dependencies making the work out of
| sequence and inefficient. It seems there are fewer and fewer
| people that can break out a Gantt or Pert chart and identify
| stuff like "the critical path".
| asplake wrote:
| > Difficult to couple OKRs with tasks
|
| Depends perhaps on what you mean by "task", but I don't get this
| one. Surely your OKRs are how you measure success of most of what
| you do that quarter, and there are only a few of them. What value
| does task-level tracking really add?
|
| I'd go as far as saying that task-level tracking may be of value
| to the individual, but progress generally should be tracked at
| the level of deliverables and outcomes. When I was a manager, I
| made a point of not looking at task-level data. To focus on them
| is a recipe for micromanagement.
| qudat wrote:
| Thanks for the feedback! The leaf of a circle heirarchy doesn't
| necessarily need to be a task -- that's just how many orgs
| operate. The theoretical OKR feauture-set of Wormhole could
| simply be a place for message boards, docs, and a way to
| manually add metrics. You could reference other circles inside
| an OKR circle if you'd like, but it's not mandatory.
|
| The main critique about OKR software that I don't like is that
| it's a separate system from where things get done. When
| thinking about a product team and having an OKR set, it's
| sometimes beneficial to think about what the team is doing
| every week that helps them achieve their OKRs.
| ravenstine wrote:
| Not the OP, but let's say an OKR isn't achieved; having insight
| into all the work that went towards that OKR might be useful in
| understanding either when the goal of the OKR is met or whether
| the OKR should be reevaluated. I'm not saying that's a common
| thing to do, but I could see that being a case where task-level
| information would be beneficial.
| apokapsa wrote:
| The most unique thing about the product is not being locked into
| a set hierarchy. Circles do not seem to contain child circles -
| they merely reference them
|
| This is great because you can replicate tags, folders or any
| other organization structure this way
|
| Other project management tools enforce a rigid containment
| hierarchy (projects contain tasks which contain subtasks) and
| allow flexible organization only through filters (which tend to
| produce flat and not tree-like output). Wormhole would let me
| create hierarchical views without copying content
| qudat wrote:
| Exactly! Thanks for taking a look.
| bobek wrote:
| You should fit Phabricator a try (there is a community fork at
| https://we.phorge.it ). It is fast, simple, yet powerful.
| Basically the best ticketing system, I've worked so far.
| gecko wrote:
| Is there a definitive fork yet? I've been waiting for the
| community to coalesce around one of them.
| qudat wrote:
| I'll take a look, thanks!
| PaulHoule wrote:
| The part about comments being weak resonate with me.
|
| Personally I like to generate a lot of documentation for my own
| needs. (Lately I started a diary of chocolate bars I eat, but
| there's a story behind that.)
|
| That's how I can pick up on Monday where I was Friday. If I get
| interrupted it's how I get back on track. It's how I can pick up
| the code I wrote six or eighteen months ago and repurpose it.
|
| I'd be happy to file my notes with the ticket, but this would
| drive my coworkers up the wall, so I don't.
| loughnane wrote:
| Many problems have come from people conflating "task management"
| with "project management".
|
| If you've got a team of people that need a lot of hand-holding,
| the two can be the same. In most cases though there is a lot of
| experience on the team. In that case task management too easily
| becomes micromanaging.
|
| What is needed instead is managing against milestones and
| trusting your team members to execute against it. Some team
| members can be trusted on certain tasks more than others, but the
| solution is closely monitoring those that need support, not
| forcing task tracking across the entire team.
| tyingq wrote:
| Project managers can add a lot of value by zooming out and
| finding dependencies that would slow things down. The less
| obvious ones, especially chained ones.
| pfraze wrote:
| This resonates with me more than the other comments. I've done
| a lot of self-directed work, and I've worked at web dev shops.
| In the latter, the only complaint I ever had about Jira was
| that it was slow. My PMs were my favorite people; they were
| like my "operator" while I was heads down (in the matrix). They
| helped deal with the big picture and talk to the client while I
| pushed through tickets. Jira was perfect for that because they
| owned it and I just showed up to click the buttons they had
| configured.
|
| In all my self-directed work with small teams- you're right, we
| just needed a task manager. The overhead of PM would have been
| a net negative. We basically just needed to track our own
| conversations with each other.
| jmfldn wrote:
| Jira in particular is everything I dislike in software. It's
| feature bloated, overly complex and yet, despite the overwhelming
| complexity, it's hard to shape to your needs very often.
|
| I want something much much simpler. Stick to the worse is better
| approach and adhere closer to the philosophy of doing one thing
| well.
|
| https://en.wikipedia.org/wiki/Worse_is_better?wprov=sfla1
| qudat wrote:
| > Jira in particular is everything I dislike in software. It's
| feature bloated, overly complex and yet, despite the
| overwhelming complexity, it's hard to shape to your needs very
| often.
|
| Author here. I totally agree with you. Not only that, we
| purchase the software because it sells us on being able to fit
| the needs of the organization but at the end of the day most of
| the companies I worked for only use sprints successfully.
| jrockway wrote:
| How do they make it so slow, is my question. I've seen my
| computer do physics simulations synchronized with 11 other
| players, updating my screen 360 times a second and my
| headphones 48,000 times a second. But then JIRA takes 5 seconds
| to say "you have 3 bugs open". How is it even possible? Like
| what code do you type in to make it run so slowly? It boggles
| my mind.
| hinkley wrote:
| Atlassian is a blight. Developers are supposed to be informed
| consumers of software. Yet Atlassian applies an information
| hiding strategy to UX which means that their tools often have
| features that you simply do not know about because your role
| doesn't allow that feature. How are we supposed to reason about
| the possible if people are hiding information? I have coworkers
| doing horrible manual processes or stuffing shell scripts into
| Bamboo tasks because they don't know they just need to ask
| someone else to push a button for them or add them as admin
| permissions on a project.
|
| It creates a class of salty user who go around doing things
| like calling you a blight in public.
|
| Know your audience. UX != DevEx.
| teachrdan wrote:
| I got a recruiting email from Atlassian once. I basically
| responded, "Have you ever used your product?"
| hinkley wrote:
| I've had one boss discover that "passionate" can be a bad
| thing when the passionate person is professionally
| embarrassed by the product they're working on.
|
| I hope not to do that again.
| 2bitlobster wrote:
| Totally agree. Enjoying Clubhouse.io for that reason.
| nickspicer1993 wrote:
| I'm hesitant to post the link as it's still very alpha, but I
| am developing a Jira alternative for exactly this reason! Check
| out https://tahsk.com and let me know what you think I'd love
| some initial feedback.
| politician wrote:
| Some initial feedback: Your homepage demo launches with
| someone entering Task #1. Task #1 isn't the problem, the
| problem is Task #5509 opened yesterday child of Task #803
| opened two years ago and subsequently deferred by people who
| no longer work at the company who pointed to a planned
| technology project that has since been cancelled.
|
| Everyone does Task #1 fantastically. Task #1 is easy, it's
| greenfield by definition.
|
| How does your solution scale to Task #5509 when things have
| gone pear-shaped and there are legacy considerations that
| demand consideration?
| nickspicer1993 wrote:
| Yes very true and thanks for taking a look! :)
|
| The idea here is the "Roadmap" view you're seeing only
| shows tickets which are not completed. You might have Phase
| 1 -> Bugs (e.g. #803) opened 2 years ago and not closed if
| you choose to organise them that way but the Task #5509
| comes, get completed then is removed from the view.
|
| Still playing with how to scale projects across multiple
| departments and show only the tasks your team cares about
| though, which would make that view even smaller. Right now
| I'm thinking either by being able to filter on any single
| Task or just use the existing Labels. Thinking about how to
| do this without bloating the language with Teams or Squads
| etc. though is interesting.
| gregmac wrote:
| It's unfortunate because jira _can_ be quite good: the key is
| minimal restrictions, and building out super-flexible workflow
| that allows almost any state transitions. It took me a couple
| years of using it with admin access to figure that out, though.
| It also took using something significantly worse to realize
| what I missed - and prior to that I was not exactly a fan.
|
| Jira's JQL is it's superpower, at least for finding and
| summarizing stuff, though it is better if issues are
| categorized well. The key to _that_ is making sure it 's not
| actively hostile to your users. Unfortunately the defaults and
| the way the admin tools enable BOFH-syndrome make this an
| uphill battle, which is why so many jira installs are bad.
|
| Now that said, the speed, stupid markup syntax and some other
| things still would make me do a good look for others prior to
| starting something on jira again. But jira _can_ be decent, and
| there is much, _much_ worse.
| politician wrote:
| Jira is expertly designed to do one thing well: close sales
|
| It ticks all of the boxes and more boxes than its competitors
| in customers' managements' requirements spreadsheet, it's
| priced to sell well, there is an ecosystem and a marketplace,
| and the sales demos show that all of this works smoothly.
|
| We should be praising Atlassian for following the UNIX
| philosophy, not condemning it.
| awinter-py wrote:
| also classic project management is very bad at expressing the
| overall spec of a new product, doesn't support the estimation
| process for complex things or ones requiring coordination, and
| aren't good at expressing inter-person or inter-team blockers
___________________________________________________________________
(page generated 2021-09-03 23:02 UTC)