Developing Formal Policies and Procedures

Is it just me, or is there an aversion to writing things down (project plans, installation directions) in the modern workplace? The manual I received with my BlackBerry barely covered how to turn it on. Getting the BlackBerry Integration Server and BlackBerry Enterprise Server to work became my responsibility. Some of it I easily figured out on my own, but some of it required me to search BlackBerry Forums for multiple partial answers, figure out which part of each was actually correct or applicable for me, and then put together a solution. It was very time consuming.

Coincidentally, I've been developing a presentation on operating Project Management Institute communities. The question of when to write down formal policies and procedures came up. It seems like the answer I derived would be valuable for project managers to apply, especially for long term projects or operations.

First, I had to examine why I would want to write something formal. Writing down formal policies and procedures simplifies governance. Operations are carried out in a consistent and repeatable manner (sounds like maturity, doesn't it?) and team members are provided with guidance when someone with critical skills or knowledge is unavailable. Formal written policies and procedures also keep teams from re-inventing the wheel. Maturity is built and the control of internal processes is strengthened. Work is done more effectively and efficiently as the act of writing strengthens and enhances memory.

Now I'm not saying that for a small project, volumes need to be written. Start off with a basic set (project charter, basic plans) and build as you progress. Project risk management should help identify areas which could benefit from written policies and procedures. Perhaps you are an operation bound by Sarbanes-Oxley. As you move between project phases and re-examine your risk assessment plan, more documentation may come to mind.

Think about how my BlackBerry experience might have been different if there was a more comprehensive guide. The setup and initial use might have been more productive. I would save time by knowing what to do. I would probably learn more and use more features, which could lead to positive outcomes such as more software sales, discovery of other time saving features, or an ability to share knowledge with others. So next time you start a project, think about what would be useful to write down and follow. And if you are managing operations and not projects, then it may be even more important to efficiency and internal controls to write some minimal policies and procedures.