Unlimited isn't Supposed to be a Challenge
Disclaimer: I like Trello. It's a dang good piece of software that I've been using the free version of for years, well before Atlassian bought it out from Fog Creek Software (now Glitch.com). That said, this isn't intended to be an endorsement for Trello or Atlassian for that matter.
Even at its most basic (free) level, Trello has a lot of cool functionality that lets your team run wild with managing projects, setting up calendar events, making to-do lists, setting up workflows and so on. But here's the thing with Trello — when you buy into the Business Class level at $10 per user per month (paid annually), you gain a whole lot of new features.
In particular, suddenly you go from having a measly maximum of 10 boards to Unlimited boards! So exciting! 👏 Not just that, but you get a whole smorgasbord of new things to play with. Look at this outrageous list!
Ooo. Map view! Priority support even! Seriously, that's a lot to take in. But I digress.
What about those juicy unlimited features? Tempting, right? Think of all of the boards you could create or all of the files you could upload or the number of cards that you and your team could wash the entire world with! No idea, thought, or daydream would go unwritten.
Hold your own dang beer!
Trello isn't the only bit of software that offers unlimited whatever. Most software services out there offer their own flavor of unlimited feature types. "Unlimited" is often just a side-effect of running these types of services in the cloud.
For all practical purposes, there's no way any company — or even a lot of companies — is going to use up so much space or use so many features as to impact an online service like Trello, Asana, or Monday.com down even a little (assuming it's well managed high up in there in the clouds. That's where your money goes, by the way, into the clouds☁️⛅️🌩).
But that doesn't stop people from taking "unlimited" as a challenge. In the case of Trello, I've seen a few organizations and individuals who have a board for every imaginable process, project, and problem they can imagine. And within those boards, there are an unfathomable number of cards. If these boards and cards were real and not digital, city streets and interstate highways would be paved in them.
Unlimited doesn't mean, "hold my beer."🍺
Essentially, these organizations and folks are practicing a digital version of hoarding. There ends up being so much un-managed content that they have no idea what their next steps are supposed to be, or where they need to go, or what they need to do. They get so lost in the act of creation they forget they have actual work that needs to be done.
Sit a Spell, Would'ya?
For one company, I set up their software project management system using Atlassian's other big player, Jira, and its companions, Confluence, Bamboo, and Bitbucket.
We had a multi-billion dollar budget. Paying for all of the features we were using with the Atlassian suite was worth the money we were paying them so that our staff of over two hundred people could concentrate on their areas of expertise. Once I got the system up and running, the software development hummed along quite nicely... for the most part, but that's a story for a different time (to paraphrase: nothing ever goes as planned when implemented in reality).
Nothing ever goes as planned when implemented in reality.
Despite the large team, the even larger corporate sponsor, and the ability to create an unlimited number of Jira Projects, I restricted it to just nine projects. Why nine?
Because we had seven products, an R&D team, and a science team and that's all we needed. A bulk of the software developers and UI/UX designers were working on the seven products; each product had features to be built and deadlines to be met and were assigned teams. The R&D team did their own thing and I and the rest of management didn't want them polluting the other projects. And the science team rarely engaged anyone outside of their esoteric holdings on a faraway land; besides, they used Confluence way more than Jira anyway.
We didn't need more than nine projects, so we didn't create more projects than nine.
More precisely, I prevented anyone from trying to create more projects. I was the gatekeeper, following the rules and guidelines we'd established for the organization. Our goal was to foster cooperation and transparency. A myriad of unsanctioned projects and mismanaged documentation facilitated neither.
Your system should foster cooperation and transparency.
It's not like I didn't get continuous requests to set up new projects all the time, especially in the beginning as we were ramping up the organization as a whole. Devs, designers and project managers alike would ask, "Can you create a project for me?" It showed a fundamental misunderstanding of organizational logistics and management. It also showed how many folks didn't pay attention during our kickoff meetings for each major project.
In those early days, I had a lot of communicating to do, but the requests waned as I began to understand the details of their needs and adjust the existing projects accordingly, and as people could see the value of constraint.
Just because you can, doesn't mean you should.
To Project or Not to Project?
I always had a key set of questions to ask would-be new project advocates:
- Is the work to be done for this new project endorsed by upper management? That is, is it for a product we're actually going to make to sell? Something that the company is willing to put considerable time, money, and resources behind?
- Does the work being done have any dependencies on the existing projects? I discovered oftentimes people just wanted a workspace away from the main project they were working on. Developers in particular made this request a lot... I suspect it comes from the (very good) habit of branching code. The answer was inevitably yes, there was some dependency, so I'd point them to the appropriate project.
- Who is going to lose visibility into this work? The reason for this question was mainly for the sake of the project management office. Any extra, unsanctioned project in Jira meant an extra place to go scrounging around to find data. Far better to have all the details in one main project block, something that Jira excels at providing services for, assuming one understands Jira permissions, Agile development, and project management as a whole.
Is it sanctioned by upper management? Are there dependencies on existing projects? Will anyone lose visibility to data?
The only times I created a new project (before we hit our max of seven product projects) was when we legitimately had an actual product to begin working on. Jira project creation was part of the initial product plan, in fact. No one could actually begin full work until the project was created in Jira (along with Git, the physical labs, testing suites, document repositories, and so on...)
The Land of Unlimited Options is a Farce.
I attribute the desire to create projects and boards willy-nilly with the American culture of unlimited everything. Unlimited minutes, unlimited breadsticks, unlimited channels, unlimited fries, unlimited speech, unlimited options to make a fool of oneself (which, you know, happens to all of us from time to time. Don't beat yourself up for mistakes. Learn and move on).
But there is freedom in constraint. By purposely channeling your organizational efforts into a small set of projects, governed by a small set of rules and guided by best practices, you're forced into thinking creatively about how to manage a wide variety of situations. By purposely limiting choices, there are less decisions to make and fewer opportunities for things to haywire, giving you, and everyone else, more time.
There is freedom in constraint.
Systems can get complex very quickly. By controlling expansion, modularizing it, and planning how one sub-system might integrate with another sub-system, you and your peers (in project management, IT services, and other departments), can ensure within a reasonable level of comfort that if anything goes wrong, it can be easily fixed or unwound and more importantly, everyone on various teams can have a clear understanding of their small part of the big picture. You minimize the risk of losing visibility to critical information and maximize the workflow and productivity of the players in the system. A nice side-effect is that the system is easy to duplicate as well. You can take the same practices and apply them elsewhere.
You minimize the risk of losing visibility to critical information and maximize the workflow and productivity of the players in the system.
Who Should Run the Land of Projects?
You might think that project managers would be the ideal candidates for setting up a project management system. After all, that's their domain specialty, right?
Well, yes, it is their specialty, and no they are not the right candidates for setting up project systems — or resource planning systems, customer relations management systems, so on. Oftentimes, anyone who is a domain expert for what the system is used for is too close to the issues at hand to understand the sometimes very intricate relations between all of the parts of the system. Importantly, they are unlikely to see the external connections that may be needed and future problems that might arise, and thus not plan for such criteria.
In a large company, consider finding or hiring someone who is simply an expert in such systems setup and put them to work (yes, in case you're wondering, that would be someone like me). If you're hiring internally for such a position, IT and DevOps folks with good people skills are ideal. Don't hire someone just because they claim to be a domain expert; like I mentioned, project/program/product managers (even with a vaunted PMP certification) are rarely ideal candidates to set up a project management system, even one as rudimentary as Trello.
For smaller companies, on a limited budget, look for that person who likes to tweak settings on apps; someone who combines a knack for details with a bit of technical expertise. It's important that they get along with people as well, because there's a lot of communication and collaboration required to get a firm grip on how the broader organization works (or would like to work). Bring in someone to consult for a few hours, at least for the initial planning phases so you can get your victi... I mean employee headed in the right direction.
Getting Back on Board
Most software, at a particular level of pricing, effectively has "unlimited" versions of least a few features (if you can't ever hit a number limitation, then it's effectively unlimited to your organization).
Trello boards are unlimited, as are cards, power-ups, storage, and even members. That doesn't mean you should have the same view of those services the way a cow looks at an endless sea of tall grass. Just because you can create unlimited boards doesn't mean you should.
The key takeaway is that before you consider adding the Nth board so that your team(s) can fill it with X number of cards (for large values of X), consider how you could achieve the same goal in your current work environment. If, after a bit of serious consideration and analysis, you do decide to create a new board (or project or whatever), make sure that there was a rule that you followed to justify its creation. If there wasn't one, add it to your existing list of rules (and if you don't have a list of rules, make one).
Make sure you follow your company's rules of order and organization.
I think you'll find that, over time, your system will function more smoothly and people around you will be more productive — and you'll know this to be true because you'll be able to easily see the truth in the limited number of projects you'll need to look into. And as always, if you have any questions or you and your organization are suffering from an over-abundance of projects, reach out to me. I'll always make time to have a quick chat about what your situation is like.
ENDS🍺