Showing posts with label Process. Show all posts
Showing posts with label Process. Show all posts

Sunday, May 11, 2008

May 12, 2008 – Stop Wasting My Time

My brother-in-law, Paul, tells a story about a boy, Theo, who wass afraid of clowns. The tale follows Theo’s life from childhood to teenager to young man through to his old age. At different stages in his life he attempts to survive a circus performance but always ends up fleeing, screaming hysterically, at the sight of the clown. He tries therapy, hypnosis and other extreme means to cure himself. Finally he joins a religious order of monks known for their fearlessness and sharp comebacks in the face of danger. In the final confrontation with the clown, Theo is being chased, stumbles and falls down. With the clown standing menacingly over him, Theo finally faces his fear and yells, “I don’t like you very much!”

Quite pointless, eh? Paul can drag this story out for at least 15 minutes, adding more details and deeper insights. When he finishes you feel cheated out of a large portion of your time.

As project managers, we need to make sure that what we are asked to do has purpose. The Systems Development Life Cycle is a great example of this. As part of the Project Management Office, I expect pushback from the people using the SDLC. The majority of the templates and processes come directly from the teams, but if they don’t make sense we need to get them changed. In order to be successful, everyone needs to get involved in the following ways.

Know What. Keep an eye out for PMO announcements telling you what has been added or changed. When you start a new project or phase, browse through the processes, templates, best practices and lessons learned to make sure you have the latest and greatest. The temptation is to modify what worked for the last project, but great improvements may have been made since then.

Understand Why. I’ve been guilty of playing the PMO blame card. Early in my PM career I would ask the team or client to complete something “because the PMO requires it.” A great example is the Risk Assessment. If you are just filling in risks because you have to, you are missing out on a project saving devise. Telling the client / business that you have to have one to pass an audit may get you off the hook immediately, but it shoots an arrow into your support team. Eventually the client / business will think all PMs blindly do whatever is dictated. They then loose faith in the whole organization.

Use Them. Put the process to the test. Processes and templates generally aren’t built to gaze longingly at. They make really lousy wall hangings and lawn ornaments. They are intended to be used. Besides, the best and most constructive complaints come from those that have tried to use them, not those that ignore them.

Provide Improvements. The goal is to use the group’s collective knowledge and learning to continuously refine and replace what exists today. The PMO will be among the first to admit that the best answers come from the line. Toyota’s manufacturing success has at its core the right and responsibility of assembly workers to suggest ways to make it work better.

The users of the processes are the real owners, not the PMO. If a piece is broken, get it fixed. If it doesn’t make sense, find out why it even exists. If no one knows why, get the PMO to drop it until someone screams for it back.

In the end, no one wants to waist your time with pointlessness. Well, except maybe my brother-in-law.

Tuesday, January 9, 2007

January 9, 2007 – Evil Alter Ego #4: Mrs. Process

Fighting alter egos can be tough work. Like Dr. Jekyll striving against Mr. Hyde it can seem like a loosing battle. Especially when a particular alter ego seem so helpful in the beginning. Take the case of Mrs. Process. She starts by figuring out how things are done and documents the procedures. Working with others she identifies faster and better ways of getting things done and incorporates them. By performing audits and making sure that the procedures are followed she can spot problems before they become issues. The problem starts when she becomes inflexible and intolerant. As she turns over to the dark side her focus become the letter of the law. Forms become static and any alterations are denounced vociferously.

Don’t misunderstand me. As a former Software Quality Assurance Analyst and Project Officer I am a big fan of process. It is when we become slaves of process that this alter ego wins. It isn’t limited to QA people, either. Project managers can become mired in process. How do we stop this insanity?

Question the process. Processes are meant to speed up development by being consistent in the way tasks are performed. Over time they should evolve and improve. That doesn’t always happen. If a process you or your team is being asked to perform doesn’t make sense, question it. Find out the purpose behind it and determine if it is going to help or hinder you from achieving that goal.

Focus on purpose. Once you understand the spirit of the law make that the focus. If the process needs to be bent, bend away. Very few processes were intended to be rigid. Granted, if you are working with nuclear materials there are some specific process you need to follow. But when you are managing a project the letter of the law is not always required. Do what makes sense using the processes as guidelines.

Allow for exemptions. Sometimes it just makes sense to bypass a process. If you have a strict Quality Assurance group or are subject to Sarbanes-Oxley requirements it is important that you get permission, usually in writing, to do so. Corners can be cut, but you need to ensure that the project and company are not placed at risk by slicing too much.