Morey's Law #17 - Round 2

Two weeks ago I shared Morey's Law #17:

Professionals Are Predictable, But The World Is Full Of Amateurs

Image Courtesy of Stuart Miles at FreeDigitalPhotos.net

I shared a story about a co-worker whose lack of planning became an emergency for me and my project. What I didn't share was how to mitigate this Law. My intent with these lessons learned are not only to provide examples of when things can go wrong, but also to show ways that you can mitigate the impact, or hopefully prevent the Law from impacting you. 

This particular Law is a little more difficult, because this can be caused externally or internally. The internal impacts are typically easier to mitigate. If you have proper change control and risk assessments in place and you take the time to get to know your team, you should be able to spot the amateurs and figure out ways to prevent them from causing crippling issues. 

As is typically the case, the external factors are more difficult to predict and thus more difficult to plan for / mitigate. In the case of Jason, two weeks ago the strongest answer actually comes from upper management. 

The Project Management Institute espouses that projects should be managed by a Project Management Office (PMO), with a Program Director (or something similar) at the top. His / her job is to coordinate activities across projects and help solve conflicts between projects. If two projects need the same resource, then the Program Director will determine which project has the priority and work with other managers to determine resource availability and how to recover the projects that are impacted. 

Regrettably, in many locations a PMO does not exist. Projects have a tendency to work in a vacuum. Even if the PMO does exist, who's to say that it is properly managed? So what else can you do?

When I worked in a highly matrixed organization I made it a point to have conversations with the resources assigned to my project; not just about MY project but also what other work they may be required to do in the same time frame. I would use that information to determine whose project would take priority, as well as determined if I needed to talk with management or another project manager about his / her upcoming needs for the resource. I often found that by being proactive with these conversations I had enough notice to determine if there would be a conflict and start negotiating how to minimize the impacts to my own goals. 

This particular issue can happen in highly projectized organizations as well. Resources that are directly part of your project, which you have managerial control over can often get pulled because they have specific expertise. This can be even more difficult to predict than in a matrix organization, if for no other reason than you tend to expect conflicts in a matrix organization.

In one particular example, I was leading an engineering design team through the feasibility and detailed design of an offshore drilling platform. As we progressed, I had 3 critical engineers pulled off the project at random intervals because they were knowledgeable about the equipment on another project taking place in New Zealand, and apparently the rig manager was new (potential amateur, at least for the short term). These resources were never gone for very long and didn't even travel to New Zealand, instead conducting conference calls and troubleshooting from the Houston office. But their engagement as troubleshooters for the New Zealand project put them behind on my project. 

In this case, there were two things I did:

1. I worked with upper management to try to determine how frequent we could expect these interruptions, and gain visibility of when the project would finish. I also talked with them about strategic significant of the two projects and determine which had the priority (the New Zealand did because it was actually drilling, as opposed to ours which was still being designed on paper). 
1. I did manage to get upper management to agree to a maximum amount of time for which my team members could be pulled per month. 
2. I took that information and built contingency into my revised project plan to cover for their sudden departures and returns. It pushed my project a little further out on the schedule, but management understood once I could show what the impacts were. 
1. I also advised upper management on the impacts if / when my team members started creeping up on the allotted time. 

As a bonus, something I should have done but didn't think of at the time: coordinate education sessions with my engineers and the people on the ground in New Zealand to help mitigate the number of "emergencies" requiring my team's attention. A lot of the time the issues would have been basic, if the team on the ground had known design and engineering history of the project. Instead, they moved forward with a "best guess" and got themselves into more trouble rather than less.

Two final thoughts:

1. Just because a person is an amateur in one area doesn't mean he / she isn't a professional in another. I wouldn't want my software designer (in most cases) to snake my toilet after a family reunion during Thanksgiving, nor the plumber to write code for my next software implementation. 
2. Most amateurs don't want to cause problems, and in many cases would like to become professionals; it's just that no one has showed them how. If you identify amateurs within or around your project or team then before cutting them out take the time to see if they are educatable / trainable. Build programs and education sessions for their growth. In the short-term this can be painful and difficult; but in the long run it will prevent more pain, and improve communication and understanding across the team. 

To wrap this up, when you find yourself at the mercy of amateurs, find ways to mitigate the impact by building contingency into your planning, communicating across projects to ensure your resources, and educate amateurs to prevent mistakes (and grow them into professionals). Remember, we were all amateurs once. You become a professional by education and experience.