📢 Announcement
How-To | Projects & Teams
Franz Gerhart
Prologue
Creating teams and projects is the foundation of Basecamp, undeniably! Doing so in a scalable manner requires discipline and guidelines, but no explicit rules!Â
Definitions
Team
A team consists of any number of individuals within a relevant department or corporate body. Teams share ideas, create documentation, schedule projects and handle perpetual tasks.
Project
A project is a finite task consisting of smaller tasks, ought to end at some point in time. For the avoidance of doubt, any customer facing task is a "project".Â
A team consists of any number of individuals within a relevant department or corporate body. Teams share ideas, create documentation, schedule projects and handle perpetual tasks.
Project
A project is a finite task consisting of smaller tasks, ought to end at some point in time. For the avoidance of doubt, any customer facing task is a "project".Â
Guidelines
Team
Creating teams is relatively simple compared to creating projects given that teams are people centric. You would create teams like Marketing, CRM, Controlling, ...., for any number of individuals that collaborate in a specific field.
One would also persist documentation, create to-do lists for recurring tasks, bugs or anything that doesn't fit the guidelines for creating a project.
ATTENTION, customer facing projects MUST NOT be teams, simply because "clients (by definition of Basecamp)" may only be added to projects.
Project
When creating a project make sure that you run the idea by the following guidelines prior setting it up and observe Case Type rules and suggestions on Naming Conventions as you go.Â
One would also persist documentation, create to-do lists for recurring tasks, bugs or anything that doesn't fit the guidelines for creating a project.
ATTENTION, customer facing projects MUST NOT be teams, simply because "clients (by definition of Basecamp)" may only be added to projects.
Project
When creating a project make sure that you run the idea by the following guidelines prior setting it up and observe Case Type rules and suggestions on Naming Conventions as you go.Â
- Does it "need to be scheduled inside a sprint" / "require the allocation of resources"
- Is it finite? I.e. is there a chance for it to end in the foreseeable future. Side-note: Don't be a jerk, don't create projects and keep them open by adding non-correlating task or petty stuff for the sake of pissing off the guy that has to maintain yet another to-do / project forever. People like to complete assignments, not maintain endless piles of crap.
- Is it sizeable enough? Side-note: Most tasks are sizeable enough to justify a project, even small things like catering for the upcoming weeks designs, considering that you have to develop the ideas, communicate them to the designer, review mock-ups, create banners, distribute creative materials ...
Edge Cases
Documentation
Is it OK to post documentation or files inside projects that may get archived eventually? Well, it depends!
If the is "IT - Setup & Configure a Backup Server", one might expect it definitely to result in a project. Would one also expect the team that is working on it to document the server IP, installed OS and packages, SSH credentials, hardware specs and other details to be stored inside a project that will eventually be archived? Probably not! Such documentation should go under a specific team such as "DEVELOPERS_" or "SERVER_".
Would you put the API documentation for integrating Google API under the relevant project? Maybe yes, considering that this project will take a lot of time and resources, plus it is not going to be a single file but more likely a ton of files. By the time this project is finished and archived, members of team will have gotten so familiar with the folder / file structure inside that project so it won't feel unnatural finding it there for future reference. Btw. Basecamp search is also finding stuff you are looking for inside archived projects.
Bug Fixes
Where should bugfixes go? Well, again it depends!
The websites is shit, fix it! That sounds more like 10 inter-dependant projects, ranging from design, UI, UX, WebDev, Server, Integrations, Payments, ....."
The button color for deposits is fucked up! Definitely go to "WEBSITE_" team and create a task under the Bugfixes to-do list!
If the is "IT - Setup & Configure a Backup Server", one might expect it definitely to result in a project. Would one also expect the team that is working on it to document the server IP, installed OS and packages, SSH credentials, hardware specs and other details to be stored inside a project that will eventually be archived? Probably not! Such documentation should go under a specific team such as "DEVELOPERS_" or "SERVER_".
Would you put the API documentation for integrating Google API under the relevant project? Maybe yes, considering that this project will take a lot of time and resources, plus it is not going to be a single file but more likely a ton of files. By the time this project is finished and archived, members of team will have gotten so familiar with the folder / file structure inside that project so it won't feel unnatural finding it there for future reference. Btw. Basecamp search is also finding stuff you are looking for inside archived projects.
Bug Fixes
Where should bugfixes go? Well, again it depends!
The websites is shit, fix it! That sounds more like 10 inter-dependant projects, ranging from design, UI, UX, WebDev, Server, Integrations, Payments, ....."
The button color for deposits is fucked up! Definitely go to "WEBSITE_" team and create a task under the Bugfixes to-do list!
Epilogue
Please bear in mind, at all times, that your partner in handling this well is LOGIC.Â
If you are being invited to share a folder structure with a company / friend via Dropbox, you know nothing about it and what you'd probably do is semantically verifying it's contents.Â
If the folder structure contains a file called "Accounting", you'd expect to find all kinds of financial information there, including accounts, balance sheets, audits, budgets, ....Â
It would be counter intuitive to find images of employees, statutory information about the company, agreements or procurement forms.Â
In other words, avoid being counter intuitive!
If you are being invited to share a folder structure with a company / friend via Dropbox, you know nothing about it and what you'd probably do is semantically verifying it's contents.Â
If the folder structure contains a file called "Accounting", you'd expect to find all kinds of financial information there, including accounts, balance sheets, audits, budgets, ....Â
It would be counter intuitive to find images of employees, statutory information about the company, agreements or procurement forms.Â
In other words, avoid being counter intuitive!