How Project Management tools kill more companies than any other SaaS out there
lnbogen.com
lnbogen.com
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/ The focus of the tool is right.
For team 'management' I have used Trello, although I find Unfuddle (https://unfuddle.com/) or Asana (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 :)
1)If the projects are not finished at the deadline, we don’t have to blame the tool as you said.
2)Also Oren says that focusing is the key and gives us some advice. Ok.
I think he is right but maybe the head title doesn’t match a lot with the content.
“The light importance of PM in Startups (initial phases)” or “Startups: things to focus in before PMing” would be better. IMO.
BTW, awjr thanks for those tools and I sign up in SoftwareLeadWeekly , let’s see!
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.)
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 :)
Of note just because they use a pm tool, if they like keeping things close to their chest you can end up with a drip feed affect, with them only adding things to the tool when they think you are ready for new work.
This can then cause issues where the work they released needs further requirements capture....
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.
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...
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.
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.
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.
- 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.
Here's a google. 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.
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.
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.
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.
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.
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"
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
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.
As one of the lead developers of Collabtive ( 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.
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?
Here's an uber-board that my cofounder and I built:
https://www.quora.com/Startups/Which-is-the-best-To-Do-List-...
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.
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/
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.
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.
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.
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.
I'm working on something a lot like this right now that does all the coordination by e-mail. I would be grateful if you dropped me a line so I can get your feedback when it's up and running. E-mail is in my profile!
Thanks!
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.
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.
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.
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.
Not to be obsequious but clearly at least one person wants it.
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.
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).
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.
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.
This is an excellent summary of the problem. The only thing I would add perhaps is an easy ability to look back and see how much reality diverged from the plan, so you know where you planned/estimated correctly and where you need to make adjustments (and why)..
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.
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.
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
"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."