from Hacker News

Every article that I read about managing a development team is geared towards a single company developing a product, where all developers are working toward the same goal of delivering said product in the best way possible. There is some really great information out there, but I can’t seem to find anything that’s geared more toward consultancy-based organizations. Here are some big differences that I see:

* We are working on projects, not a product. A lot of what we do doesn’t come down to what the end-user wants, it comes down to what the client wants (and sometimes those wants are really, really strange).

* Our projects can be wildly different from one another (though we stick with a standard stack as much as we can).

* The entire team isn’t working on the same project at the same time. We currently have 6 developers, at any point we might have 1-3 on the same project. That means that we can have 2-4 unrelated projects going on at one time.

* Our timelines and budgets are relatively fixed, and need to be provided prior to development and adhered to.

Different projects have different requirements and allow for different levels of flexibility. Some projects it might make sense to go with TDD and weekly sprints. Other projects might have an extremely short shelf life and just need to get out the door, so spending time on code coverage and refactoring may not be something that makes a great deal of sense. We have our own values and processes that we use for every project of ours, but the constant changes in our client’s needs make it difficult to form a solid repeatable methodology.

Can anybody recommend some reading material that’s more focused on project-based work rather than product-based? Any personal advice about managing a team where members are often working on different projects from one another? Thanks.