Project Management Software Can't Save You
wired.com
wired.com
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.
I wish there was a Freakonomics or Algorithms to Live By for IE.
* 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...
[1] factoryfactoryfactory.net
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)
> Know what you need to deliver
This is the hardest one (or more importantly, knowing what to say no to)
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.
* 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.
Business clarity is both wisely choosing, and convincing the team of the most lucrative ladder for the business to climb.
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.
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.
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
=)
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?
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!)
> 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.
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.
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".
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.
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.
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).
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.
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).
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.
Also task discovery amidst execution.
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.
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).
Bad project managers just enable micromanagement and amplify the weaknesses of management.
Good PMs (either type) are worth their weight in gold, but are super rare, just like good developers.