Generally, I agree with the majority of the points already made. But I would like to respond to a few things that I don't entirely agree with. Along the way, I think that I'll weave together an interesting answer to your question.
From Dave Markle's answer:
"Blindly following best practices is not a Best Practice."
Best practices are good ideas that work on most projects and most teams most of the time. Generally, they cover ideas that you would probably want to enact on a project, but there are also times when they are inappropriate.
An example of a best practice is "always use source control". The thing that you need to focus on, at least in this example, is not the use of source control, but the benefits of using source control, but also the costs (in terms of time, money, resources) that will be incurred, and then ask yourself if it makes sense to follow the practice or not given the project.
A few questions that you should be asking yourself about every best practice are things like:
- Are we doing anything similar to this practice or that contradicts this practice?
- What benefits does this provide?
- What downsides are there to this practice?
- Do we have the resources (people, hardware, time, money) needed to implement this practice?
If your client is not using Source Control, then yes, that's a big problem and IMO is a battle worth fighting especially since fixing the problem costs a client $0 (SVN).
The biggest impact of introducing practices (or processes) into a project late is on thrashing. Steve McConnell has an interesting article on The Power of Process. Introducing process late on a project has the effect of decreasing the amount of time spent in productive work.
Many best practices can be implemented by freely available tools. However, just because the tool is free does not mean that the process is free. If your team isn't familiar with the tools (or, worse, the practices itself independent of tools), then you need to spend time and money to train them so that they can be effective.
You need to consider the "big picture", from people to processes to business to technical perspectives when changing how a project functions, especially in the middle.
From teabot's answer:
Personally I have a set of practices that I like to work to and would hope to employ in any team in which I find myself. However, I do try hard to recognize the value in conforming to existing practices if they yield the results expected and required.
I agree with this 100%. It's not about conforming to best practices, but it's about delivering high-quality working software to your customer on time and on budget (or, if you want to be a little more pessimistic, which reducing time and money overruns). It's not about creating a checklist of practices and following them to the letter on every project.
From soru's answer:
If they are being followed and enforced, but are objectively stupid, try to get them changed. Otherwise, just quietly do the right thing.
I partially agree with this. I feel that project retrospectives (or, for longer projects, periodic project health status discussions) are very important. The idea is to let everyone involved in every aspect of a project have a say in the good, the bad, and the ugly. It's also important to not focus on the bad, but the good too. I think that a three tiered discussion is best:
- What is going well? Why is this working? Can we apply these to other projects?
- What is going OK? Is this sufficient? Is there anything getting worse, that might put the project at risk? Can we improve anything during this project or for future projects?
- What is going poorly? What impact are these having on the projects.
Capturing these and sharing them across the organization to other project teams should allow project managers, program managers, and other leadership to work toward process improvement and higher quality software.
