Reforming Software development department

Gain is the word you are looking for.

The 'on his own bit' is killing you.
Standards, get together and come up with a framework jointly, apply and evolve them for new developments. Try and assign two people to a task, one very familiar to review and help, the other to do.

Applying them to existing software, is something they are going to have a look at on a case by case basis.

Don't get bogged down with foolishness like where the braces go, or how many spaces to indent.

Naming conventions, templates, frameworks and stragegies (eg avoiding side effects, are the key.

At the moment you don't have a department, you have several people under one on an org chart, that's where I'd start.

I agree what Tony said about standards, templates and documents.
Your problem lies here: if your projects are so small, that only requires one developer ("one man show"), then the best way the developer handles the project from A to Z.
If you try to split the work between people (like developers and people handling the customer), it will be a disaster due the overhead.

So your job is to figure out how to do one-man-show with quality.

First, you need templates and documents. Do not expect the developers to produce large documentation, focus only on the minimum.

Second, train them. Explain the documents and how to use them. Train them how to avoid usual mistakes. Probably they are eager to learn from an experienced person how to handle certain situations. Probably they failed in the past because of the lack of experience.

Third, change the people. It is not easy. Even after the best training, when the developers go back to work, they will do everything the same way.
So take your best developer and your best project, and with strong hand coach him to use your templates and methods. Make this project as an example for the department. After the guy understands the way and follows it focus on the next developer.

Fourth, establish audit. The develoeprs should know that the project is not their private issue.
It is good for them because if they are sick or want to go to vacation, somebody else can step in. Slowly begin to intoduce the audit.
The fact that somebody else checks the project will improve the quality. The goal of these "audits" should be mentoring and help (giving advice), not the punishment.

The steps to be taken will differ based on the precise position within the company. I say this because a title like "Senior developer / Project Manager", especially in a company where each developer handles his own projects, does not sound like it carries the authority to direct the work of other developers; I would expect a title such as "Software Manager" or "Member of the PMO" for such a role.

From my assumption about the current role, I would suggest a three part approach. One, personally implement what one feels are appropriate standards for one's own work. Two, discuss areas of concern with like-minded peers and develop some voluntary work standards. Three, identify those in a position to make department-wide changes and recommend, and volunteer for, a study group to determine department standards.

The desire to try and improve conditions is a good one, but one must also recognize the boundaries of one's sphere of influence.

magic wands, and all other the only way way to do is X. If it were that simple, no one would get in this sort of mess.

It's all bollocks, the 'team' is where it is, through aggressive neglect, incrementally improve. Don't look at each step as low hanging fruit, but as another stone in a solid foundation.
Look for where you are solving the same problems time after time, being slapped in the face by the same gotchas, the mind numbingly boring stuff you always want to fob off on the less alert. Engineer them out, bit by bit, app by app.

I recently attempted something similar at my own organisation. Beyond the excellent advice that the others have already posted I would add that what my project teams most wanted to know is: what constituted the minimum standards?

Defining what constitutes the minimum standards for the types of work products produced, amount and type of documentation and performing reporting and communication should be defined.

I ended up producing a high level "policy" document in conjunction with my teams as to what the minimum standards for a project would be. That was of course backed up by resources such as templates, good examples, checklists etc... Many of which were not already available but I put together.

We also initially set up a process of gating at either key milestone or phase end points where I was involved to ensure consistency, quality, and that we really were meeting our time and budget constraints.

So what is currently working is providing that guidance as to the minimum standard and giving the teams the freedom to work within that to define their own plans and more detailed templates etc... while still ensuring a level of management oversight.

I would also suggest that you treat what you are attempting to do "reforming the software development department" as a project in itself, with a plan and clearly defined goals.

I am web developer , project leader and facing same problems for managing my department...so lets discuss how to overcome and manage these this things...
waiting eargerly.......