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
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.
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.
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.
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.
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...
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.
This is the crux of all(?) of it. If the software/system wasn't new/unique, it would've been copied from something that already existed. This doesn't apply in the real world where making the second copy of a bridge is almost as expensive as the first one.
Software is a mechanism that can copy its self infinitely and in multiple forms with limitless layers of abstraction [1]. If you need to make new software, by default you are making something new/unique, otherwise you're reinventing the wheel.
I have been involved in several rewrite from scratch projects. The following projects are always more expensive than the original (probably less than the original counting all the maintenance - but a lot of weird bugs will take years of maintenance to clean up and that was done in the original so it is hard to count that). However once they are done the result is a lot more maintainable, and has a much better UI of a form that would be hard to retrofit to the old. Normally they are written in a better language an the original. (C++ with const correctness is better than C++ without!)
One key takeaway is we as an industry do not enough rewrites to get good at doing them. (I'm not sure that is a bad thing)
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.
Sometimes it's enough to "know what you need to deliver in order to make more decisions/do more planning" but your scheduling and planning horizon really doesn't extend beyond that checkpoint. If you're planning/scheduling that way, you're basically 'doing agile'.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
> 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.
Gantt and PERT based project management tools are just a way for handling task dependencies and resource constraints.
They can be used with any methodology - waterfall, Spiral, etc.
Most of the “modern” methodologies like scrum are too short cycled to handle complexity well. It seems that the classic techniques like PERT have been forgotten since my PM days. Very useful for something like building a house.
Part of the problem: I haven’t been able to find a decent FOSS replacement for MS Project, which is pretty expensive and not open source. Any ideas?
What's your workflow in MS Project? I've talked a lot about PM software with non-IT people who have needs that don't fit into the issue-tracking systems I know, so I'm interested to know what you use in MS Project. From my outside view it looks like just one big Gantt chart.
I start by building a Gantt for the top level. Sometimes, I'll just build a Work Breakdown Structure (WBS) (the first two columns, e.g. 1. Survey 2. Foundation 2.1 Excavation 2.2 Concrete Forms etc. and put the task duration in the third column.)
Then I start adding links to task predecessors. If that starts getting messy on the Gantt, I print out a PERT network, tape it together, hang it on the wall and start brainstorming with a felt tip. Enter any added links into the project.
At this point, run a Critical Path calculation (longest path through network from start to finish), which gives you the slack on the CP relative to your must finish date. Hopefully, there is some. If not, look for parallelism opportunities.
Once that's all planned out, some PMs check to see if they have enough human resources to accomplish the tasks, especially the ones running in parallel. Enter the resources, and the software will commit them as early as possible. If there aren't enough, it will push out the critical path.
Issue tracking is pretty orthogonal to project management, unless it identifies unplanned tasks out of the expected workflow. Issue tracking is usually much finer grained than project tasks.
For software, consider this: you want to do an initial system integration acceptance test with the customer next week. You just started the project. What needs to be done to pass that acceptance test? That's your first Gantt/PERT/CPM. You revise it for every integration test as the project develops, sometimes totally. In the old days, we'd call that a Spiral methodology. Top down, but keep re-visiting the top level on a scheduled basis at formal Project Reviews with the customer and negotiating any changes.
For a house, you are just starting. You want a certificate of occupancy in two months. Do you have drawings and a building permit? What needs to be done? Is it even possible? (Changes and delays will kill you, but it's always wise to move as quickly as possible!)
This workflow rocks and is basically the same one I try to use whenever I'm shoehorned into project management. I'm always the weird guy with the index cards and tape and string. (:
> Issue tracking is pretty orthogonal to project management, unless it identifies unplanned tasks out of the expected workflow. Issue tracking is usually much finer grained than project tasks.
FWIW, I tend to punt on even having an issue tracker at all. I find that it winds up being a depository for people to dump things that seldom get looked at, and absent tools to trim and prune the issues for me, it turns out that bubbling these things up as failing integration or acceptance tests is often a better use of time.
Dude, thank you very much for writing in such a detailed way. Allows me to peek into how people with experience think and learn. Very insightful. Again, thank you.
Sorry, I cannot make any recommendations. I took myself out of any PM responsibilities (or related) a while back because I hated the politicking and other issues so I haven't explored the options. When I was doing that work we used MS Project and some homegrown tools. I get paid well to make software systems and have less stress now.
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.
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.
Agile (acknowledging the broadness of the category) doesn't account for poor estimation in any way. Agile methodologies simply refuse to answer "when will it be done"-related questions. Even with perfect estimators, it's an intractable problem when you can add new features of unknown complexity to the backlog at any time.
Waterfall is suited for projects where the outcome is known (e.g., guidance software for fancy new jet, embedded software, etc.) where establishing a deadline is necessary and possible because the desired feature set is fixed (at least in theory) and changes are locked behind a (likely multi-year) requirements and design process with contacts and lawyers.
Agile is better suited for exploration of a product space or implementation of projects where agility (surprise, surprise) to changing/unknown client needs is paramount. Clients don't know what they want till they see what they don't want, so agile is great for that type of build. The web-facing world loves agile, because the "end" goal is usually, "make money so we can hire more developers to build more website [whatever that means] to make more money to hire more developers...".
There are means of mitigating bad estimation (e.g., Spolsky's "Painless Software Schedules" and particularly "Evidence-Based Scheduling".), but you can't account for a 50 hour feature added 19 weeks into a project. Agile (acknowledging the broadness of that category) alone doesn't do anything to mitigate either bad estimation or surprise features, it simply trades "known deadline, fixed features" for "unknown deadline, flexible features".
At a certain point all software needs to be maintained. Interfaces change, the environment it operates in changes, etc. You can handle that with a level-of-effort support contract. At what point do you say "it's done!" have the development team move out, and have the support people come in?
You could say "requirements are satisfied", is the threshold but those always change on a project. You need to predict what you need in the future. No one is good at that, but the fact that some may be lucky does not imply that it's possible. Doing it right in a schedule based environment means contract renegotiation. This could be expensive and many times its easier for the customer to bypass management and convince the engineers to take on more scope for free. This happens all the time, project managers need to be vigilant! But vigilance does not build value, it just creates avenues for conflict.
Regardless of what your methodology is, every successful project will become a "unknown deadline, flexible features" product at some point in its life-cycle. Why are we bifurcating that stage at an arbitrary point based on faulty assumptions made months and years in the past? What agile does is it moves the arbitrary bifurcation point to t=0 and avoids classes of zero-sum customer-management-worker conflicts.
> Agile methodologies simply refuse to answer "when will it be done"-related questions. Even with perfect estimators, it's an intractable problem when you can add new features of unknown complexity to the backlog at any time.
I'm unconvinced. If new features of unknown complexity are getting added to your product backlog with the expectation that estimations are done against them and not that exploratory work is planned and undertaken instead, that's a problem with the culture and not with the process.
Scrum in particular (according to Coplien et al. at least) is meant to handle prioritization of work as a conversation between the people who want stuff built and the people actually doing the work to get stuff built. The only thing it recommends—not even prescribes—as it relates to estimation uncertainty is embracing the framework to chart a new course more easily when the facts change.
A big pattern that is prescribed (though perhaps only implicitly via reiterating that the product backlog is strictly in delivery order when work starts) is that the product backlog is append-only when you don't want to trigger more planning and, as a direct consequence, draw up a new refined product backlog for everyone to work from. If you need to reorder your product backlog items to add something in the middle, that's a signal that the facts have changed, and the plan needs to be redone. That isn't prima facie all that different from a more traditional project management method.
Agile only aims to make planning suck a little less to change by baking certain touch-points into the process so that someone can pull the proverbial andon cord unceremoniously.
> Agile is better suited for exploration of a product space
More apropos this, if you've ever heard of a spike solution, that's agile's attempt at controlling for uncertainty when it isn't exactly clear how to do something or how long something will take. It necessarily triggers additional planning, and the product backlog item for it is a clear display of the uncertainty inherent in delivering that helps determine where in the ordering that work should fall.
Likewise, if you generally know what the roadmap looks like and have confidence that it won't change, the uncertainty is still in the humans doing the work. I've always put vacations and bereavements and on call shifts and other kinds of fixed-date "generally not available for product work" things into the product backlog, and having that visible to everyone with stake in the work is always valuable.
On waterfall vs agile, both don't work without significant flexibility and fuzzying the game on the dev team's part.
Waterfall as it was done in early 2000s was mostly a high level plan and smaller unofficial iterations on the ground. We knew we need to test, and sometimes partially release stuff in advance to have an idea of what's actually working and what's half baked.
The same way successful agile projects are almost always done with unofficial rough planning and dependency graphing checked ahead, and smaller iterarion following the big picture from there.
On both methodologies, religiously adhering to the mantra is suicidal, and I don't see agile being significantly better except if all you care about it getting paid iteratively -- which is a noble goal for a consultant.
Perhaps the point that bears reiterating is very few shops actually followed hard line waterfall planning (nor agile, for that matter).
Most commercial developers are using git as if it was svn with some local caching, and other small features that could be added to svn (at some cost). They call their svn central server github. Very few take advantage of what makes git different from svn. Svn lost, but the reasons were not always good (I never used svn so I cannot comment in detail, but the VCSs I used before git are still the same workflows most use with git)
For most developers, agile means being coached daily like in a sports team. Most folks just want to know what to do, work on it, deliver and repeat.
Instead of empowering developers it allows managers to micromanage with a daily feedback loop.
To the extent that a project involves implementation of existing code / modules / software and other activities that are not greenfield developments, though, the software-development-estimation-ability is not relevant as an argument against these methods, though. All training, activities, budgeting, hiring, etc. "knowable" activities around developing a project can also be managed in that way, and particularly if you're doing agile, you have a cadence against which you can do long-term planning of non-development activity.
Bad management can corrupt any methodology and then use it as an excuse later. Waterfall can't save you from this one. At best, it will hype you for flexible which will be agile 2.0 with a green leave on the genitals.
That’s my point. Any method will get corrupted by bad players. My comment was on a lot of agile environments that have turned into micromanagement machines that discourage any kind of long term thinking. If you only look to the next scrum you are pretty much guaranteed to create massive tech debt in the form of many quick fixes.
Well, let me tell you how waterfall will turn into a constant micromanagement hell where the long term plan will be reevaluated every couple of weeks to realign it with the latest available info.
My point is that the uncertainty in a project is a constant and every methodology which tries to change it can only hinder the work of a team.
The best we can hope is that we know what we don't know and have enough robustness to handle what we don't expect.
It's all about Power. In an organisation, the person making the "biggest decisions" (largest budget, biggest plan, further in the futur) is the facto at the top of the hierachy and calling the shot. SCRUM is all about making sure developers are not involved in long term planning and allowing non-technical people to be in charge.
Part 1 of the 2 part Senior capstone project for the software engineering program I attended required students to create a a full project management suite of Gantt charts, UML diagrams, etc and approval from your advisor before continuing with actually building software in part 2.
Naturally, I built the software package, then wrote my charts, and the 2nd semester did nothing. It was a complete joke.
I think the author conflated things or interviewed poor project managers, or something something bad journalism/wired/etc
The Gantt chart is from Gantt’s method that I think were pretty much all waterfall projects as he practiced 100 years ago making factories or whatever.
But the chart is used everywhere and is super common in agile tools just to sequence stuff and demonstrate your start to start and start to finish, etc dependencies. It’s a common test to see if things targeted will fit in a sprint.
It’s funny when an article’s author doesn’t even read the Wikipedia article on things which makes you wonder what his method is for writing these. Is he randomly inserting terms?
Gantt charts are also instantly understandable by leadership types, people in Sales/Marketing, etc. The same can't be said for a lot of the other cool-kid artifacts flying around these days.
Gantt charts are indeed a tool and like every tool one has to be careful to apply it in the right situation.
The problem with some (many?) project managers is that they don't make that distinction. They just try to apply the same tools to every situation. Gannt charts for example are relatively useless to model processes that involve a lot of unknowns or branching paths. And of in such a project they are relied uppon they can become actively harmful.
But this can be the case for literally every other PM tool.
Tasks however are often interconnected to multiple other tasks and often can be a bit unpredictable. So the Gantt chart model ends up being deceptive in both its simplicity and predictability.
The Gantt chart can track dependencies, including multiple dependencies. The issue is whether you've discovered all of your task interdependencies or not and whether you add them to the dataset when you find them missing. If you haven't and you don't, you'll be screwed no matter what tools or techniques you use.
It's also possible, and sane people do this, to use ranges instead of fixed times for your durations. This helps to discover risk (particularly of exceeding a deadline).
> If you haven't and you don't, you'll be screwed no matter what tools or techniques you use.
Discovering all interdependencies and details takes much more time than completing a significant amount of the tasks. So again, the diminishing returns of project planning/guessing/tracking vs completing the work.
Good news! It can be an ongoing thing. Tag your issues, tasks, whatevers as you discover missing connections and reevaluate your plan on an ongoing basis. It's not a commitment, only fools commit to plans with incomplete information (and no plan has complete information, unless you can see the future).
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.
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.
> 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).
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.
I see many people in "product" management roles that are actually project management roles. Often people in these roles lack both domain and technical knowledge, but like to organize stuff, often in ways that are nonsensical to those doing the work. The result is usually... not good.
Good PMs (either type) are worth their weight in gold, but are super rare, just like good developers.
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