Skip to content

Standard Operating Procedure

March 25, 2010

This week in my project management class, my project team had to present the “pro” side of a debate on the question of the value of companies setting standard policies and procedures for all projects.  And by “pro” side, I mean, we were arguing for the statement that “establishing standard policies and procedures for all projects across the company is a waste of time and money”.

The debate was initially a challenge for me, personally.  I came into it with a background in a company where the problem was a complete lack of standards and policies, with regards to projects.  With that experience, it would have been easier to argue for why standards are necessary.  However, part of the stated point of these debates, according to the professor, is to learn multiple sides on these issues so that we can be more effective project managers.  So getting assigned to argue the stance opposite to my initial mindset had the potential to be instructive in that regard.

In th end, I think our group made a moderately persuasive case for our side of the debate.  I think our presentation was weak in a few areas, but our case was really a simple one.  My part of the debate centered on the unnecessary “bureaucracy” that builds up around standard procedures.  You know the drill: pointless reams of paperwork that take up all your time and prevent you from focusing your energy on the task at hand.  They cost the company money, delay a project’s completion, and increase the risk of project failure.  At least, that was our assertion – and we did have some evidence to support it.

Naturally, there’s also evidence that without standard policies, projects suffer from scope creep, grow wildly out of control, balloon in costs and are never completed.  Unfortunately, the opposing team didn’t really spend time in their presentation talking about those points, or they’d have had a far more persuasive argument. We won’t be able to see the results until next week, but I have a strong feeling our team at least nominally “won” the debate.  It didn’t help that one member of the opposing team was a former member of the U.S. Army, and spent the majority of his speaking time singing accolades to the U.S. Military.  Now, I’m an “Air Force Brat”, as they say, and justifiably proud of the tradition of service in my family (even though I chose not to follow that route), and of the relative merits of our military.  But from a project management perspective, this guy spent entirely too much time waxing ecstatic and relatively little time dissecting the relative strengths and weaknesses of the military’s fabled discipline and how this applies to the topic at hand.  And for an audience of MBAs – most of whom have relatively little background or interest in the military – there were better examples.  It also didn’t help the opposing teams argument that at least one of their team members admitted during his part of their presentation to the need for flexibility in policies and procedures – which was central to our argument.

Our argument wasn’t against the need for policies and procedures, but against the need for standard policies and procedures that are universally applied across a company regardless of project type.  And we fairly well demonstrated that a marketing campaign project, and a technical R&D project, and a resource-intensive logistical project are all very different, and need different and flexible policies and procedures to govern their execution.  And in that way, we defined the nature of the debate and essentially owned it.

Looking back, then, I think I actually did learn something from this excercise.  I went into it very unenthusiastically because I thought my experience had already taught me the need for standard policies.  But it’s not the lack of standard policies and procedures that hurts projects in the company where I work.  It’s the lack of any policies and procedures.

Advertisements
2 Comments leave one →
  1. March 26, 2010 3:27 am

    Stephen,

    Nice post.

    I believe that policies, as well as other constraints imposed by the company should adapt to the project (within reason), and not the other way around. For example, imagine you’re working on a 1 week long project, and someone wanted to do a small change to the scope. Should you adopt the policy and go through a formal change request procedure (see controlling change requests), a process that may take days depending on the size of your company, or should you just informally accept the change and integrate it into the scope?

    Projects should not define policies, but policies should be flexible enough for all types of projects, otherwise, you’ll end up with too much overhead.

    • March 26, 2010 8:54 am

      Thanks. I definitely feel like that’s a big part of the lesson I learned from this particular exercise. Thanks for sharing your thoughts!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: