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.
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 :)
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.)
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.
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....
I think the point of the article isn't that PM tools aren't useful, it's that they shouldn't be the focus especially of a new team starting out. When starting something new, it's easy to get bogged down in the how, rather than focusing on the why and the what. I think analyzing workflow and project management is more successful when you have already worked on a team for a while and realize where your strengths and weaknesses are, so you actually have data to use to determine what project flow might be more efficient.
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...
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.
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.
>> 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.
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.
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.
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.
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.
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.
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.
"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.
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.
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.
"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.
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"
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.
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/ ), 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.
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?
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:
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.
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).
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.
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.
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.
Fully agree. We've built a simple team communication tool Weekdone (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.
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.
> 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.
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.
>a spreadsheet containing all the tasks, issues and risks, with owners and dependencies identified is usually enough. >telling people when you're waiting on things from them
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!
I'm happy to look at what you're doing, since I've spent a lot of time recreating this wheel. Unfortunately I don't see the email address in your profile.
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.
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.
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).
>> 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.
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.
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.
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.
> Small companies need lightweight tools to outline the promises they intend to fulfill for the business side in a given time period.
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)..
Well, I'm quite happy using 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.
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.
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.
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 :)