
How Project Management tools kill more companies than any other SaaS out there - oellenbogen
http://lnbogen.com/2014/04/14/how-project-management-tools-kill-more-companies-than-any-other-saas-out-there/
======
awjr
This thing reads like some sort of marketing buzzword bingo and doesn't seem
to say anything at the end.

PM tools are useful. They are all about communication and the 'bigger'
picture. The issue I find is not so much with PM tools but when the 'truth'
they are saying (e.g. the project won't be ready for 3 weeks due to resource
constraints and the client has been told it will be next week) is not what the
management want to hear. It's very easy to 'blame' the tool.

I particularly like [http://www.ppmroadmap.com/](http://www.ppmroadmap.com/)
The focus of the tool is right.

For team 'management' I have used Trello, although I find Unfuddle
([https://unfuddle.com/](https://unfuddle.com/)) or Asana
([https://asana.com/](https://asana.com/)) more suited.

Using Trello is all about working out that Trello isn't the perfect answer for
software development and that there are more focused tools out there that help
you get the job done :)

~~~
exelius
I've used Jira's project management tools in conjunction with post-it notes to
great success. At a very large company with lots of interdependent projects.

At the end of the day you don't need software if you have good managers
(separate development managers and project managers if the product is big
enough.) I've seen huge programs managed with nothing but Excel, Powerpoint
and Post-It notes. You just have to retrain your executives to give you high-
level vision and not try to micromanage it (I know, it's harder than it
sounds.)

~~~
GFischer
My current manager uses Excel and I don't have the slightest idea of what he's
registering or communicating to anybody.

But, as you say, if he was a good manager, he would be communicating anyways.

If the management is not so good (or just not good at communicating?), I'd
rather have a good management tool :)

~~~
exelius
Right; project management is really more about facilitating communication than
anything else. Most projects have lots of domain experts who each have an idea
of how things should be done. A good PM's job is to facilitate the
conversations that need to happen to get everyone to agree on a plan, then
communicate out the plan of record to everyone. This has the bonus factor of
being able to peer-shame anyone who decides to deviate from the agreed-upon
plan; which is helpful because in most organizations PMs have no real power to
do anything.

And a management tool won't make a bad manager better, they'll manage just as
badly through the tool. It can actually make things worse if you're the
manager of a bunch of managers who all use the tool differently: your reports
from the tool will be meaningless at best. That's why my preferred approach is
to add project management to a workflow tool; not the other way around (e.g.
we don't make development leads enter their tasks into MS Project, we put the
project tracking info in Jira and manage it through there.) That way you can
drive data consistency through process consistency and not piss off your
developers by wasting time with multiple systems.

------
EwanG
PMP certified PM here - I think the main role of a PM at any company, but
particularly a software company, is as a story teller. By that I mean that you
are responsible to take the team's status, and put it in terms the
stakeholders understand (on the one hand) while taking the stakeholders' goals
and putting them in actionable terms for the team to execute (on the other
hand). Very few PM tools seem to facilitate this. Many of the corporate ones
(as mentioned here and elsewhere) focus on completion in terms of tasks and
dollars, and maybe resource assignment and forecast. That's because what folks
REALLY want to know - how close am I to getting what I thought I was paying
for - is hard to measure objectively. Both because the definition of "what you
thought you were getting" is usually squishy, and how close is "good enough"
is usually difficult to measure except in terms of whether there is money to
make it better or not.

Waterfall tries to address this by making the "what you thought" as rigid as
possible, but not surprisingly I can give you exactly what you asked for and
you will find it lacking. Agile says I'll give you "good enough" often enough
for you to decide when you're done as early as possible, but tends to be
difficult to time box. My .02 worth anyway...

~~~
exelius
This is a great response.

I feel tools are often an excuse for poor PMs to be lazy. A PM is probably not
going to be everyone's best friend -- your job is basically to facilitate
decisions by executive leadership and make sure those decisions are executed
on. You don't need a fancy tool for that; you need to communicate often with
everyone (which often means bugging development managers for reports when they
have better things to do.) Tools can help with this -- making the reports
easier to generate/consume, but at the end of the day this can be integrated
with whatever task assignment process the development group uses internally
(be that tickets, or post-it notes, or smoke signals...)

As for agile vs. waterfall, you're right. It's tough to get corporate suits
out of the "well when will it be ready?" mindset. The nice thing about agile
though is that you repeat the process much more frequently, so you can
actually start to improve that process and shorten your sprint times and do
more actual work in less time. Executives like to see that, so early in a
project it helps to focus on that as long as the product is making progress.

------
Zigurd
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.

~~~
slantyyz
>> you are locked-in to a largely "waterfall" model of development. That's way
out of fashion for good reason.

I once worked on a multi-million dollar "agile" project that went off the
rails until a decision was made to switch to a waterfall approach.

This is not to to say that "waterfall" is good and "agile" is bad.

If your methodology doesn't suit the culture of the people you have delivering
the project, you're going to fail no matter what.

The problem is that these pm techniques get adopted organization-wide by
executives who became "experts" by reading a few articles and books but don't
spend any time becoming experts at the type of people they have working for
them.

------
matwood
Focusing on PM tools is a symptom and not the cause of a failing company. When
a company is focusing on things like PM tools, they are avoiding working on
the project because they either a) do not know what to build or b) how to
build it.

~~~
JonFish85
Agreed, many times over! I'll go further and saying that I've seen some times
when a focus on purely processes & project management (not just the software)
can really bog down a team. If you're so worried about finding the "perfect
process", you'll never get anything done. Whether it's putting together code
style guidelines or information flow processes, sometimes it's best just to
move forward and use common sense. I understand that it can fall apart,
especially in a larger company, but in a startup environment, I find it
especially frustrating when a company has weeks worth of meetings to decide
the best way for a specific process to go. Sometimes things just need to be
done.

------
adrianmsmith
If your task is "deliver software with these 10 features until 15 August" then
you've got to know if you're on track or not.

\- You've got to know what the tasks are that still need to be done, and their
current estimates.

\- Given the people on your team, how long they work per week, what public
holidays there are, when they are going on vacation, you can work out how much
work capacity is available to you until the deadline.

How do these compare?

As the project progresses, no doubt slips will occur, requirements might
change etc. Continuing to model the set of tasks ahead of you allows you to
understand if the current plan will make you meet your target or not.

If you already know, two months ahead of the deadline, "we're not going to
make it", you can do something about it. Inform the customer. Hire more
people. Reduce the requirements. Schedule overtime. Etc.

If you don't know, then you're just driving blind. The 14th August will roll
around, and you'll notice "oh, the project's not done, and now it's too late
to do anything about it".

This is where tools can help you. Model all the tasks. Model all the expected
durations (range estimates ideally to model uncertainty like LiquidPlanner or
FogBugz does). Model when people are on holiday, how long they work per week.

Know as soon as possible when things are no longer on track, so you can take
action.

~~~
smileysteve
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.

~~~
SkyMarshal
Any chance you remember what studies? Would love to introduce them to my
startup.

~~~
smileysteve
I think I read it through HackerNews, pretty sure that Drive points out that
time constraints are not a motivator.

Here's a google.
[http://www.emeraldinsight.com/books.htm?chapterid=17055118](http://www.emeraldinsight.com/books.htm?chapterid=17055118)

Essentially, time constraints hurt autonomy and therefore creativity. If you
have a deadline, you are more likely to find the quickest way that works as
opposed to the best error free, scalable long term strategy.

------
tbatterii
"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.

~~~
AznHisoka
I'd love to see an actual stakeholder actually put up REAL cash for a project.
That's a real stakeholder, not an imaginary one.

------
rwhitman
I've worked with a lot of companies as a consultant (or founder or product
manager), and generally have to dip various PM tools and workflows regularly.
Every company is different and even using the same tools, can have completely
different workflows. Some are mildly efficient, some are a total clusterfuck
and some are just baffling that anything gets done. I have never seen a
company operate with a flawless workflow. Ever. The bigger the organization,
the more product managers you add, people stay equally confused. There's no
magic spell to be organized, you just have to accept that there will always be
a certain level of chaos in any given system and learn to mitigate it as best
you can with regular communication.

Basically the lesson I've learned is find a tool that's _simple_ \- as simple
as the size of your team or organization can stomach - and only level up when
you grow in scale. Heck, a spreadsheet full of tasks can be a surprisingly
effective task management system for most small groups. Something like Jira is
only necessary when you're operating at a certain size, so lay off it until
you're at the point you can't live without it.

------
ajsharp
Claiming PM tools "kill companies" is obviously hyperbolic, but I can
certainly agree that in the early days of a company, they're usually a
gigantic waste of time, effort and focus. Especially if implemented via
mandate.

Often there's a person (the PM) who has too much free time, and implements
said tool for a reason like, "let's use X so we can all communicate better!",
which of course really means, "I feel out of the loop and I want to know
what's going on all the time."

These tools are best used when they arise out of natural communication tension
amongst the team. Mandating everyone communicate and track progress in a
specific way, for the benefit of one person, especially if that person isn't
the CEO, is a giant amount of overhead to place on a small team. All you'll do
is slow down the team.

------
thecolorblue
"I believe that focusing your time around Project Management tools is a
premature optimization and probably #1 killer of many startups."

You lost me when you said probably.

I have been at companies where project management has not been a priority and
it was a nightmare. I understand focusing on the tools is a bad idea, but it
is dangerous to suggest that project management is not important. There is
even a chance focusing on the tools will make the entrepreneur think about how
they are being productive, which is the true problem these tools are trying to
solve.

~~~
marcosdumay
Well, I doubt it's one of the biggest 3 killers.

How does it compare to doing something nobody cares about, not releasing, and
not getting the word out?

I also can not understand how formal project management can do anything but
harm a startup. I can only imagine people saying things equivalent to "We are
going into uncharted territory, but this is exactly the path we are taking"

------
raverbashing
Yes

And not only managers are at fault for this. I've seen my share of absurd
amounts of wasted time because of "Clean Code" or "it's not OOP enough", etc

Developers are as good coming up with BS as managers

------
sklivvz1971
It seems obvious that a start up doesn't need an enterprise project management
tool. It needs something more appropriate, like Trello.

That said, whilst a start up can be built with rocks and paper, useful tools
are ... useful, and having top notch tools can be a competitive advantage.

~~~
EvaK_de
I totally agree: PM tools are useful in general, and the more the tool's
feature set aligns with your individual needs, the better. Hence it makes
sense to have a modular PM tool.

As one of the lead developers of Collabtive (
[http://collabtive.o-dyn.de/](http://collabtive.o-dyn.de/) ), I think we did
something right: Collabtive itself is a basic PM software - very accessible,
simple to use.

When your company and your projects grow, you can add modules like a Gantt
chart and project templates as you go. This way the software will adapt to
your growing need for overview and division of work.

------
at-fates-hands
One important point is to get a tool and be comfortable with it. If you wait
too long to get the proper tools in place, you'll be hamstrung when the
business finally takes off. My advice is to get your due diligence done and
move on once you've picked a tool.

I've seen the flipside of this argument. I worked at a huge multimillion
dollar company who didn't have any PM software in place. It was so bad because
the project managers were running the asylum. Some had super tight deadlines
and needed by 5pm TODAY. Others didn't really care about the tasks, or would
forget about them and then throw the developers under the bus. It was insane
what was going on, and it was mainly due to not having some kind of software
in place that keep track of the tasks and deadlines.

The company wasn't going to go out of business anytime soon, but with all the
business they had and more coming every month, how do you expect to have a
quality product when your project management is a joke?

------
wpietri
Having built entire products with a wall of index cards, I firmly believe that
fancy project management tools are generally an expensive distraction,
especially for startups.

Here's an uber-board that my cofounder and I built:

[https://www.quora.com/Startups/Which-is-the-best-To-Do-
List-...](https://www.quora.com/Startups/Which-is-the-best-To-Do-List-Task-
Management-application-that-also-has-Project-Management-features-tasks-as-
part-of-a-project/answer/William-Pietri?share=1)

In retrospect, it may have been a little excessive; I don't think the backlog
needed to be that large. But there wasn't a lot of harm having it, and it made
everybody feel better to know that their nice ideas were all in the backlog
somewhere.

~~~
GFischer
That's a really nice one, thanks for sharing :) and I really like your
philosophy too.

I agree that a physical artifact is good:) and easily customizable (no code
needed, cross-browser and everything :P ).

I wonder if some sort of screen could be a replacement (a screen showing a
Trello board?).

I remember seeing some guys having a physical gauge showing server requests,
and saying it was really satisfying and much better than having it on a screen
(can't find the link).

Edit: I found a similar one, but the original was better an in the context of
measuring a startup. [http://makezine.com/2008/11/18/net-data-
meter/](http://makezine.com/2008/11/18/net-data-meter/)

~~~
wpietri
Well said.

I encourage everybody to start with a physical board for a while. There are a
lot of subtle benefits to it.

For example, everybody learned how to work this by about second grade. So when
you say, "Good idea, add that to the backlog" or "If you're going to start
working on that, move it to 'working'", people know how to work an index card.
They also understand how to modify it. People will spontaneously start using
card colors, post-it flags, and marks on the cards to express things that are
important to them. And if somebody thinks a new column is needed, they can
just add it.

Another big advantage is that everyone can see what's happening. If
everybody's near the same physical board, you know when people are even
_thinking_ about the plan, because they naturally go and stand by it. A lot of
good conversation happens naturally that way.

Once people have gotten the magic of a physical board, I'm fine if they decide
that something digital really meets their needs better. But we as technology
people are inclined to go for a technological solution right away.

------
malanj
Sad but true. I've been part of startup teams who spent an embarrassing amount
of time choose, customising or changing project management tools. None of it
seemed to have mattered at all in retrospect. Now we start off with a
whiteboard and post-its, and when people work remotely we use the simplest
task tracker (like Asana) we can find. That solves the problem in the first 5
minutes of a new project, and leaves the team free to get things done.

~~~
hobs
Agreed, working for some medium sized software companies I have seen them
change their project management software 3 or 4 times and because they are so
process happy it takes them months to get their workflow the way "they" want
it, and then they start looking for new ones.

I understand a good PM tool is useful, and can make it clear what your next
objectives is, but it seems to me a lot of people like tinkering with options
over doing the work on the product.

------
jkaljundi
Fully agree. We've built a simple team communication tool Weekdone
([http://weekdone.com/](http://weekdone.com/)) and we're receiving daily
feedback from users to make it much more complicated and add features that you
describe. Our best practice suggestion that many startups use is to share just
5-7 key goals and achievements per week with your team mates. Something that
takes just 5 minutes to share and read. Those who follow that are happy.

Still many try to use us as a project or task management tool. The most
requested feature? Due dates and item due times - something we've said we'll
never implement. Same for projects and many other complexity features.

There's beauty but also usability in simplicity.

------
Pxtl
Nothing like a team of 4 people where one of them spends all his time managing
timesheets and charts.

------
mathattack
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.

~~~
dragonwriter
> My experience has been that a spreadsheet containing all the tasks, issues
> and risks, with owners and dependencies identified is usually enough.

My experience is that it usually seems _at first_ to be enough, and then at
some point you have too much information that needs to go in one cell, and
then cell-size limits bite you...

It may be that there are lots of bad project management tools out there and a
simple Excel spreadsheet is better than many of _those_ , but its still not a
_good_ tool for the use.

OTOH, I would agree that that the real meat of project management is "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" and that often too much focus is on tools.

~~~
mathattack
Yes - that's my point. An imperfect tool used by a team that's universally
following a "good enough" process is much better than striving for perfection
in either the tool or the process.

I've spent time in organizations that strive for perfection in either the
project management tool ("Well, let's just tweak the Access database some
more.") or the process ("We need to report on 50 metrics daily.") and wind up
much worse for wear.

I haven't found the cell limit size to be a problem. Perhaps because I don't
use Excel as a substitute for requirements document. I just it to keep track
of things, and a couple lines is usually enough.

------
josephb
I don't get the headline, it's the only place SaaS is mentioned in the whole
article.

Is there an assumption that all Project Management tools are SaaS?

To be honest the whole article seems a bit disjointed, it tries to be emotive
and just fails to present a clear message.

------
highmastdon
This might be a little off-topic: The thing I miss in almost every Project
Management Tool (SaaS or not) is the connection with the customer.

Say we are a company building software for a customer of us, we want the
customer to put in the request and we would like to tell an estimate time that
would be needed. This would also represent the cost of it. If he's allright
with the costs, he can accept it. In that way you can communicate clearly to
the customer how much he needs to pay, and we get to know what he wants. AND
you have a bases to stand your contract on. No more hassling about endprice.
Just print the sum of features and prices and you're done.

~~~
mratzloff
This vastly oversimplifies what goes into project and client management. It's
a feature that no one really wants on the business side of things.

~~~
noir_lord
> It's a feature that no one really wants on the business side of things.

Not to be obsequious but clearly at least one person wants it.

~~~
slantyyz
Actually a lot of people want it, especially the people who have to deal with
the customer.

The problem, as with most enterprise software, is that the desire for a
feature often doesn't match reality.

In my experience in services over the past decade and a half, most customers
don't use these systems when they're available. They log in a couple of times
at the beginning, and then they continue to rely on dealing with a person like
a project manager or account manager.

There are a number of reasons for this, such as the customer not wanting to
use a system to collaborate, the customer is already too busy with their day-
to-day tasks, etc.

~~~
noir_lord
I agree with you my point was actually about his assertion that no one wanted
it rather than that it would work.

I/We now use email for client reporting/change requests which I then file into
the bug system myself as many of our customers simply have no idea/want to use
a bug tracker.

I've yet to see one that works really well for end users (the best solution
I've come up to is to have the file a bug button on each page and I capture a
bunch of metrics about what they where doing when they pressed it) with a box
basically saying "Please describe the problem as clearly as possible" rather
than complex drop down driven forms asking for things like severity levels
(which most end users don't care about, anything that stops them doing what
they want to do gets marked highest _anyway_ ).

~~~
slantyyz
>> my point was actually about his assertion that no one wanted it rather than
that it would work.

I wanted to address his assertion as well, but thought it would be better as a
child to yours than as a sibling.

>> I've yet to see one that works really well for end users

Yeah, this bit is very tricky. I would make the argument that your current
approach might actually be one of the better approaches (at least from your
customers' perspective).

In a lot of the engagements I've been involved with, end users just want their
responsibility to end at "this didn't work", and for the
developers/consultants to figure out what the user did that caused an issue
themselves.

Reporting issues is _work_ , and end users tend to be already busy with their
own jobs. So the more work the end users have to do to report issues (i.e.,
filling out forms, taking screen shots), the more likely they are only going
to report what they consider showstoppers.

------
markbnj
I admit that my first instinct on reading a piece like this is to shout out in
agreement. But at the same time I know that instinct comes from having worked
on small teams, in small companies, for my entire career. I like small teams,
and I like small companies. I have a hard time fitting into big corporate
environments, and so I no longer try. I don't really know what works well for
people who have to manage really large efforts. I do know that for the small
projects I deal with trying to keep the tools in sync with the evolving
direction becomes a tail-chasing exercise. Of course, all this might mean that
I'm just lazy.

------
Dirlewanger
You'd think this would be common sense. The fact that it's an article and it's
getting traction here shows how many incompetent asses there are in the world
who thrive on micromanaging.

That said, facing the world with a dearth of any organization and direction
will leave you penniless in the long run. Small companies need lightweight
tools to outline the promises they intend to fulfill for the business side in
a given time period. If a few people are just going to have everything in
their heads, things _will_ go south.

~~~
skylan_q
_You 'd think this would be common sense._

The common sense is metric tracking when dealing with incredibly intangible
things in order to use data and statistics to make informed decisions. In my
experience, it's almost always a complete waste of time adding overhead that's
never recouped. It works best when you're producing X widgets where X is at
least 10. When it comes to building something that hasn't been built before or
doing custom work, most of that data can just be thrown out the window. A
pessimistic guess is almost always better than trying to infer meaning from
data into an existing narrative.

------
tmikaeld
Lack of focus, yeah.. now i'm reading at hackernews again, darnit!

------
ppadron
Well, I'm quite happy using Sprint.ly ([https://sprint.ly](https://sprint.ly))
to build our product. I think what makes it a good choice for software
development are the things it does not have, like custom statuses, custom item
types, time tracking. Also, it has sane defaults.

Their story format (As a ... I want ... so that ....) can be weird at first if
you are not used to it, but it really helps focusing on the real benefits of a
feature and segmenting your customers.

------
tn13
The tools are not as important as people who use them. I have worked with
teams who used nothing other than spreadsheet and whiteboard to track stuff
and still delivered good results.

------
michaelochurch
I think of PM tools like I think of guns. Guns aren't bad things, innately.
Police need them, in many places, for self-defense. Thousands of lives are
saved annually by avalanche shootdowns using very large guns. On the other
hand, I wouldn't want a gun to be in my place of work... especially not if
it's pointed at me by someone just waiting for my "velocity" to drop so he can
shoot me in the head.

I don't know that PM tools are inherently bad or even useless. I do know, from
observation, that most uses of them are negative. You don't hear talented
programmers jumping for joy when they hear that their jobs will depend on
their ability to haggle for story points. This stuff might turn 0.5x
developers into marginally employable 1.0x, but it brings the 10x way down.

Finally, this Tweet from @SwearengenCD:
[https://twitter.com/SwearengenCD/status/56070701622374400](https://twitter.com/SwearengenCD/status/56070701622374400)

"If God made the earth with a PM, we'd have 100 small piles of dirt, each
completed in a 4-hour coding increment, but no fucking planet."

------
ozg
someone spoke my mind.

