These are my Three Principles of Pragmatic Process Establishment. From my experience, these are the only ways to successfully implement a process, no matter how much value it may add, or how simple it may be to follow. If these principles are not followed, neither will the process that has been put in place when it comes to the crunch.

Automate

Automation is the most desired and beneficial option. The benefits are obvious. If a process is automated the value-add from that process is gained, without extra effort from the team. For example, the simple process that developers should run the unit tests. The value is obvious. Errors are found earlier and higher quality code results. However, although this is a simple instruction to follow, running unit tests has blockers for many developers. Firstly, they take a long time to run. Secondly, not all are relevant to you. Thirdly, they may have environmental requirements you cannot or do not want to setup. This simple process also has a simple automation solution: have a continuous integration build server that runs all the tests for the developers on each check-in. All the benefits gained, and everyone will perform the process.

Another example is having developers log their time spent working against work items. Having developers do this is controversial (individual developers should never be measured, only the team as a whole), but the value is the schedule becomes very realistic and accurate based on actual burn-down rates. Time tracking is however, time consuming and error-prone. Developers tend to forget to record the time started, time finished and minus interruptions against each work item. The numbers are then fudged voiding all the value of the process. The automation solution utilized has been to use TFS Working On. The tool allows developers to very easily track their time, without wasting their time. The data is providing us with accurate reporting while dog-fooding our BI product.

Automated processes also have the benefit of accurate repeatability. If an installation package is fully created each build, the risk involved in following a multiple step process is gone. A typical Standard Operating Procedure (SOP) is usually a long manual process that is error prone, especially when under time pressure and reduces confidence in the end result, compared to an automated solution. Of course the negatives of this process implementation solution is that not everything can be automated, it may not work for all required cases or require ongoing maintenance, or may take a long time to implement.

Enforce

When Automation does not fit enforcement is usually the next best. The reason a process even needs enforcement is that it will most likely not be the easiest thing to do. There is much value in doing it, but not necessarily by the person doing it, or not at that time. The enforcement itself must be a physical enforcement, not a SOP document stating "thou shalt follow". By physical I mean generally technical. A document cannot be uploaded to SharePoint until it has certain properties set. Physical is like ballot papers must be folded, so they don't fit in the slot on the box, until they are folded.

In the development world check-in policies are one of the best examples of enforcement. Here you can define your coding standards, code reviewer, check-in comments and work item association for example. Having these particular policies helps maintain higher code quality and readability, easier searching of history, and better reporting. The danger of enforcement is going too far and having people overwhelmed with the number of hoops they have to jump through to get things done, making them feel inefficient and ineffective. Each process enforced must be reviewed occasionally to ensure it is still adding value, and if found to be less value than that of the time it costs, it should be dropped immediately.

Path of least resistance

When a process cannot be automated or enforced it must be the easiest way to get the task done. If not, it will require someone to be the Sergeant to enforce the process which itself is time consuming, error allowing, inconsistent and demoralizing. Essentially a path of least resistance process is very simple and value is seen clearly. It could however be artificially made the path of least resistance by making the other paths more difficult or less effective.

Using a wiki for team collaboration and information is a good thing and seems like a simple enough process to follow. However, most wikis require custom syntax for mark-up and uploading images is a pain. What I have seen happen is email is just used instead, since it allows simple rich text editing, inline images and the information is directly sent out to everyone right away. This is almost an acceptable process over the wiki, but distracting email threads tend to occur, important emails are overlooked and new employees cannot access the information. What we have implemented instead is Microsoft OneNote for our wiki. OneNote is a rich client application that automatically synchronizes all the content locally, is searchable including text in images, can show a list of recent changes if you want to follow what is happening and all sections show who modified it and when (still needs proper versioning though). It has become the easiest way to share information among the team, and is a great resource for new employees.

General Tips

Begin a new process with as little as possible. Do not start a new form with a large amount of mandatory fields. Grow them as the required. The process will have fewer blockers, less red tape with little perceived value, and get more user buy in.

Do not over analyze. Analysis Paralysis is state I now know I use to get stuck in. Do something. Keep it light, nimble and able to be adapted quickly as it matures.

Re-evaluate occasionally. Make sure you are getting value out of what the process is requiring people to do. If the cost is high and value is low, either look at how the cost can be reduced through automation or trim some of the fat of the process that is yielding low returns. If people are having trouble with the process, don't blame the people. Focus on smoothing out the bumps that are causing them to fall of the path.

Do not provide much documentation of the process. The process needs to be simple to follow and self documenting, i.e. each step points to the next. Documentation tends to be TAGRI and will either stop a process being nimble or quickly become out of date with the process. The best option for documentation if it is required is to have it automatically generated.

A good process will perform under pressure. Do not abandon it to save a penny now, because it should save you hundreds later.