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.
3 comments:
Well stated. Another aspect of this is within the work of the project itself. Star performers and type-A personalities like to go above and beyond, and sometimes that means spending a lot of time and effort on what amounts to gold plating.
If the scope was met with quality, there usually isn't much justification for spending another 40 hours. Usually there are many other important tasks already lined up to be worked on.
Redirect the top performers to deliver sooner with great quality, instead of adding their own scope which probably doesn't deliver comparative value to the stakeholders.
Josh Nankivel
http://www.PMStudent.com
The desire for Individual Autonomy can present challenges for a standard SDLC (or any standardized IT development process). Some team leaders want to do things their own way. Others are skilled at breaking rules to good effect.
The question nets out as this: "How detailed do we make our SDLC?" and then that is followed by "How strictly do we enforce it?"
These two questions can have a big impact on one another.
If we, say, standardize at the phase level but let the PM get creative within the phase, do we have enough control?
In my experience, most PMs want consistency in what they do. From project to project they produce similar products. The concept is to capture the essence of those products as a template and let them "taylor" it.
Post a Comment