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.
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?
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.
If Agile didn't exist I think we would have just invented it.
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?
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.
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).
* 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...
> Know what you need to deliver
This is the hardest one (or more importantly, knowing what to say no to)
Business clarity is both wisely choosing, and convincing the team of the most lucrative ladder for the business to climb.
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).
Good PMs (either type) are worth their weight in gold, but are super rare, just like good developers.
I wish there was a Freakonomics or Algorithms to Live By for IE.
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.
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.
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
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.
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.
* 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 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.
It's probably best to pick and choose a few tools that are complementary and focus on the team building itself.
This is hard and unsexy work that often goes unnoticed, so people often don't do it.
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?
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 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.
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.
If the office doesn't already have processes in place, adding software won't fix that problem.
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
=)
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.
