Projects and Procedures in the Enterprise

At work recently (and in every other enterprise I have worked for) I have been noticing that policies and procedures reign even if the policy or procedure is completely wrong for a certain scenario.
I pride myself in being a very logical thinker and creating steps/procedures/functions to solve a problem is what I get paid for so when I see others using a procedure that is not fit for a particular scenario or developing a new procedure because it worked one time in a certain environment I cringe.

So I would like to take a moment and share with you a few tips on handling projects in the enterprise and avoiding policies/procedures that can hinder:

1. Start each project with a brainstorming meeting where you include all parties that could be involved.
Doing this will give you the advantage of nailing down procedures that will be involved and even flesh out other people that may need to be involved that you didn’t think about. Doing this will help reveal broken procedures or policies that will get in the way. having the meeting early will also give the people involved a heads up to when you will be making further meetings and will let them know when to schedule time to devote to your project. Come up with stages or phases during this time so that the parties involved will be able to put a name or number to their task. Given the time constraints I see everybody under these days the parties involved will appreciate the heads up.

2. Document as you go.
In programming this is essential and I would say this is essential in other areas as well. When creating code, procedure, new processes, or even documentation itself document it. This is always easier said than done but if you document as you go you will familiarize yourself with the subject matter and will be better prepared to dispute the nay-sayers and policy-spitters that come along during long projects trying to deter your efforts.

3. If you find a faulty procedure don’t abandon it go to the source and find out why it was created.
Many many times procedures are made by people who don’t have a clue about the effects of it but create them anyway to satisfy a need they have. So never abandon a procedure unless you first find out what need is to be satisfied. Most procedure writers will work with you to come to a common goal and some will even improve the procedure so that it better meets their need.

4. Don’t get pushed around.
People will doubt your systems and methods especially if you are in a position to create procedures that they must abide by. Always consider their needs but never change the end goal of a project or allow them to push your scope outside of your goal. Policy-spitters will also come along and tell you that you are stepping out of line. Be prepared to discuss the matter but be well versed in your goal and project so that they cannot push you into a position that may hinder production.

5. Send update emails.
Most people will not read update emails as they see it as a waist of time but it will allow the people who need to know what stage you are at. Put the stage near the beginning of the subject line as most users will see the subject and can decide if it is time for them to step in. This is where the defining stages point in #1 comes into play.

I wont guarantee that these steps will keep polices or procedures from getting in your way when working in the enterprise but I can assure you that by putting the effort up front to include as many players as possible and updating them along the way you will be able to reduce the problems you encounter.

Thanks
David Bates