How Project Management tools kill more companies than any other SaaS out there

Software projects and project management tools have always been a dangerous combination. Project management tools were originally made for creating big, expensive physical objects. These projects merited hiring professional project managers, and the nature of the projects left little room for ambiguity: Either 27 floors of steel are up, or not. In this world every measurement of task completion is represented by a physical object.

Contrast this with software development: If you use the same tools as people who build skyscrapers, you are locked-in to a largely "waterfall" model of development. That's way out of fashion for good reason. The plan is rigid and subject to misreported completion. Projects die with 80% of every task complete but with few of them actually finished, done, put to bed.

But if you use "swim lane" style tools, the plan's malleability is an invitation to make frequent changes.

The best I have been able to come up with is:

1. Use a traditional resource-loaded CPM chart to find places where the project is resource bound, find milestones that can be used to funnel multiple task completions to a choke point that must be completed before subsequent tasks are started, and get a best-estimate for total project completion. This is for planning only, not tracking.

2. Use a "swim lane" style task manager to run tactical resource allocation and keep decisions about resources fluid enough to not be bound to a rigid waterfall process.

3. Keep a versioned spreadsheet (Google Sheets is ideal for this) that tracks added and (ha!) deleted tasks and their resource and time estimates.

4. Use milestones as gates that must be crossed before earlier parts of the project can be confirmed as completed. If the milestone is not complete, the project is in a state of day-for-day slippage.

This keeps a project nimble, not to say "agile," it provides adequate discipline before you find yourself at the end of the project schedule and are surprised it didn't all come together in the last week, and it gives me the documentation needed to take to a client when change requests add up and a re-estimation is needed.

This is also very true of old school tools like Microsoft Project. The overhead for entire teams to learn to use the charting and other features is too much.

My experience has been that a spreadsheet containing all the tasks, issues and risks, with owners and dependencies identified is usually enough. Then it's all about the actual discipline of discussing them, saying "No" to lots of things, telling people when you're waiting on things for them, and focusing on the tasks at hand.

Execs frequently get too hung up on the tools themselves. I cringe every time I see MS Project as a requirement for a Project Manager. It tell me that either someone from HR wrote the requisition, or that the project is in trouble.

Absolutely, or there's a focus on process rather than real decision making. Either there's no clear leadership or people are passing the buck in lieu of making a call that might turn out to be wrong in the long run. When you're a small company that's suicide.

"stake holder" is not mentioned once in this article. PM tools, help with the communication that leads to trust between the doers, and those putting the cash up for it. it's either use PM tools, or suffer micro management hell and lack of focus until the $$ runs out.

I can sort of empathize, with having too much focus on the planning/pm process, I've been there, done that, it's a potential problem. But not a reason to disregard the tools or the need for them.

There's flaws in accounting processes too, but I believe sane people would all agree that accounting processes are needed.

If there are problems in the way you are measuring, deciding that measuring is bad is just silly.

Studies show that deadlines reduce code quality and increase overall time though - so the better solution is to modify the tasks so that "until 15 August" is not part of it.