A client of mine recently posed this situation/question to me: “When I was just beginning and even now as I mentor new PM’s, I constantly see a battle between the PM best practices and a company’s maturity/ capability to practice it. It would have been very helpful when I was starting out to know where I could let things go a little and where I could not. Finding the right balance between those best practices, the teams’ capabilities and the company’s desire to cooperate can really help the project. Otherwise, you get into a control battle and that doesn’t help the project at all. So if you were to manage a project and the company had little support or time for the PM practices, what tools/ techniques would you shed, and which would you keep?”
A very good premise and question. I think the first thing I would do is assess my company’s project management maturity. Now by ‘assess’ I don’t necessarily mean hire a company to come in and perform surveys. In general that’s not a bad idea. But budget-wise, it may not be practical and I’d much rather see a company do it that not even if the method used is sub-optimal. So a company needs to gauge itself on (at least) these parameters:
-Monitoring and Controlling
There are a myriad more but you get the idea. So, for example, in scheduling proficiencies, what is the level of same among PM’s? Do they use a scheduler such as Microsoft Project or Primavera? If so, are they trained? Is the scheduling software/method used uniformly across departments or does one department use Project, another Excel, another Word and Outlook? (Don’t laugh. I’ve seen it happen). Once you can establish the current level of project maturity across the organization, you will have a baseline from which to measure.
So let’s say that this particular company is at Level 1 project maturity which we can define as, “No formal standards, processes, methods, or procedures, or staff to constitute a project management discipline. Standard technologies and reporting are sporadic.” Now in this organization, we can probably assume that the level of, say, scheduling sophistication is pretty low. And that if anybody is actually using a real scheduler, they are probably the outlier or learned it from a book.
So now we go back to the original question which was, “and the company had little support or time for the PM practices, what tools / techniques would you shed, and which would you keep?” For me it’s a no-brainer. I would want all of my PM’s up to speed on a good scheduler, perhaps the use of the work breakdown structure and able to communicate well via email, voice mail, meeting minutes and the like. So if in this particular company I had, say, three PM’s not well-versed in these items, the first thing I’d do is either get money to get them trained, buy them books or train them myself. I am a firm believer that if you’re doing any level of sophisticated scheduling you need a sophisticated scheduler. I’m personally very conversant with Microsoft Project. And absent any other company dictum, I’d get my three PM’s up to speed on it and provide them support. I’d also teach them the work breakdown structure and advise that we were now going to use it on all projects. Lastly, I’d make sure they understood how to run a meeting, how to publish an agenda, how to write meeting minutes, how to communicate to stakeholders, etc.
While I think there are other important tools (change control, risk management) I believe that using a scheduler, WBS and better communications will instantly raise the maturity level of the organization, even if only incrementally. I further believe that all the PM”s must be singing from the same hymnal. Creativity is fine if you’re playing the piano. But project management is a fairly rigid discipline whose best results can only be found using tried and true methods.
Lastly, if the organization isn’t willing financially or otherwise to make these investments in PM’s, then I’d be thinking hard about working someplace else. Because then their commitment to project management is not really sound and you will only fail over and over again.