There is more than one way to organize projects. Organizing starts when you give the project a name. What's in a name? A lot! The name of the project changes the way you approach work on a project, and that approach can have a positive or negative effect on your productivity.
How You Name Your Projects Affects the Productivity of Your Website Development Business
What is a project in a web development business? It's a group of work units (tasks, tickets) belonging to a single website that your client has hired you to develop.
The most sensible and the most productive way to organize work on a project is this one rule:
one client domain = one project
So if our client's domain was example.com, we'd name the project example.com. If the client hired us to work on a completely different website on subdomain.example.com, we'd name that project subdomain.example.com which would coexist with example.com.
The most important part of this simple naming convention is that everything we ever do for that client on that domain stays within that same project named example.com. Take a look at the image of the way we organize our projects and I'll explain the benefits of this approach in a second:
What you see here are the simplest possible rules to organize work in your web(site) development business:
A client equals a billing contact: a company or an organization receiving your invoices. ACME Ltd. is an example of a client which you name 'ACME Ltd.' in your customer database. You don't bill Joe Schmoe within ACME Ltd. for your projects, so you don't name your client 'Joe Schmoe' (although Mr. Schmoe is the guy who hired you for this project).
You create one or more projects under one client, meaning that one project have have only one client (but one client can have more projects).
All work that has to be done for a project is converted to tickets and assigned to any one project. A ticket is a unique object within your project management system. The same ticket cannot exist within multiple projects at the same time (but you can arbitrarily move it between projects).
Following the 'one client domain = one project' rule, we complete a website for example.com and launch the website. When the same client hires us again to redesign that website two years later, we do not create a new project called example.com - redesign - we simply create a new set of tickets under example.com. When that same client hires us to consult him about social media a few days after the website is launched, we do not create a new project called example.com - consulting or example.com - social media.
Like I said: all work for one project stays within the original example.com project. The new set of tickets that your team works on today will not stand in the way of the old tickets you've resolved in the past. At any given time you should only see open tickets by default. Work happens in waves: today we're developing a website, in a few months we'll add a new application to the existing website, in two years we'll redesign the website - no need to have multiple projects for work on the same client domain.
Benefits of the 'one project per domain' approach
First, the whole team always sees everything that is being done for that project, at a glance. When I log into Simpfinity (our web development business management app) and view an individual project, I can read the last conversation with that client on this project. It doesn't matter if that conversation happened yesterday or three years ago. I can see whether the client has paid all her bills. Because Simpfinity treats sales leads as projects too, I can see if we ever discussed working on that project in the past (this historical sales information can be crucial to landing a project). I can see what my teammates are planning to do on this project (I see a list of open tickets), and all teammates can see what the whole company is working on for this project. I can have a birds-eye overview of the whole project.
Imagine what would happen if we split work for that domain into multiple projects: some information would be lost, or people would have to get outside their work area (outside of a project view) to hunt that information down - and nobody does that. Most people are focused on their own tickets, one project at a time. Also, the application would have to support crazy and complicated features such as grouping of individual projects just so you could see all the work for one domain in one place. It's so much easier to just create one project per domain.
Second, this approach is elegant and lowers our business overhead because it follows the actual behavior of clients in real life. Almost all clients we've ever had only had the resources to run their projects one by one. First they hired us for website development for one domain; then we worked on internet marketing for that website; a few months later we started consulting them for something else for that project. Clients don't have the time to run three completely different things consecutively for the same project, so there is also no pressure for us to create three separate projects for the same domain. Fewer projects, less overhead. Lower the overhead, higher the profit margins.
At last, our team can focus on the client and his big picture, and not on their individual tasks. Picture everybody working in their own private bubbles, within confines of single tickets they've been assigned: the company can gets into all sorts of troubles working like that (decreased client satisfaction, decreased employee satisfaction, decreased quality of delivered services). But, if developers see what sales is selling, they can jump in with their feedback; marketers can improve software features that the dev team has been working on. Collaboration happens, company culture happens when people take interest in their colleagues' work. A well designed project management application can speed up this process by making everybody's work very visible to everybody else.