PM doesn't agree with company-wide rule - what should they do?

Question

Consider a PM who has his own strong opinion how project management should look like. Now, the organization he works for takes a bit different, more loose and more flexible, approach.

A couple of examples: PM would like to see daily reporting while organization enforces weekly reporting on project teams or PM expects all the dates, even those with low priority, would be kept, while managers in the company often react to changing situation sacrificing some of low priority tasks in order to adjust to new high priority requests from their customers.

Now, PM tried to discuss with senior management about how he'd like projects to look like but they turned his request down leaving much flexibility to project teams.

What should PM do in such situation? Should he accept the way things look like?

Answer 1

IMO - if you want change, you're going to need to sell the team, not the company on the idea. If other PMs in the company are content with the current system, then there's not going to be a large buy in from above for change, since the whole company isn't having a problem.

But if you've seen merits in a more formal approach, then I think the best strategy is to sell the people working with you on the approach. If there's an impact to not doing daily reporting, or not tracing low priority tasks, then describe the impact to the teams. And be up to a negotiation or to hearing why what you ask for is unacceptable. Look for small steps, not big ones.

At least in my company, there's a few in PM-type management that have a particular way of doing things. It's specific to the individual and not particularly linked to corporate process. They get what they want because what they want gets results. While it's not official process or anything, most teams working with these managers are willing to bend a little, because when they do, the project overall is better. Sometimes these practices do make it into corporate policy, when they are shown to be a good way to solve an overall problem.

Answer 2

IMO - The PM should accept things relatively as is. I am assuming a PM for a software project.

If the PM expects formal status reports daily they is being a little obsessive. However, a daily stand-up status meeting at the start of the day may be appropriate. This meeting should just cover status changes and blockers. The PM should work on removing the blockages.

As yet estimating software development is not an exact science, the PM should be reasonable and accept the normal variances. It is relatively common to delay lower priority tasks to complete the higher priority tasks. If you are working in a zero defects environment, then expect unscheduled delays. (Zero defects will likely save time in the end.)

If the PM is dealing with task which can be accurately estimated, and no blockers occur, then expecting the tasks to be completed may be more reasonable. Try to keep the overtime to a minimum in any case.

Answer 3

In my experience, if you can show value to others for changing, they'll at least give something a try. Working through the process of seeing value from other points of view can always help to weed out the 'I wants' from the 'this would be of values'

From your examples, I sense there are I wants in the mix and you are not selling value.

Answer 4

My opinion is that the pay-cheque counts.

The first thing that counts in a company is results. Of course quality is important in order to get recurrent business, and therefore it is important to have pretty good processes and not let too many things slip away. But in the real world you always have to balance expediency and quality for most efficient results. Results that keep the shareholders happy, results that keep the customers happy, results that keep the staff happy (in that order for most businesses - though this depends on who the top person is).

That said, like bethlakshmi and others say, if you can demonstrate value in the changes that you propose then get buy in, step by step, and bring it on.

My experience is that if you don't have support from above you still have a few routes to try.

1. Do it for yourself anyway (bottom-up approach). But beware, you are on your own and it could backfire. So make sure that if your actions involve other people, that those people are Ok with it first. You must get at least reasonable levels of buy-in from all involved.
2. Do nothing, keep the status-quo (get to know your world before you swim out of sight of the coastline). You now risk to do a job that you don't like. But this can buy you time, if circumstances don't get in the way. Use that time, though, to build alliances, to build your credibility, to adopt other ways of doing things in order to get into the politics and systems of the place.
3. Build a solid business case for it that clearly demonstrates the benefits (top-down approach). This theoretical approach must be backed by significant experience though, from you or someone else, so long as they will respect the recommendations. Must be based on solid evidence for it to convince higher management.

You can blend from one solution into another or chop and change. Your choice. If you get results or a message that they value, you will get noticed in a good way.

Every project manager has their own style, especially in a large corporation. Each must work in a way that they feel comfortable working. So what suits you might not suit another and vice-versa. Those styles can be quite different, and so long as the general philosophy goes in the same direction and that everybody is happy with how they interact with one another, everything should be smooth.

At the end of the day, though, no matter who is right in principle, you can't and should not try to fight the tide. If the company is overwhelmingly going in one direction, you can't go in the opposite and expect to remain in your role. You must accommodate yourself with the broad direction that the company is taking, go with the flow and stir or veer in smaller ways in your direction of choice. You can't just do an about-face. Even if you feel that the about-face is absolutely required, you have to respect how the company got to be where it is today, who leads it and how they lead it. If you don't, you're in the wrong job and it is only a matter of time before you or they tire and look for alternatives.

Answer 5

I wrote a blog a month or so ago (The Stealth Gorilla) on the concept of rolling out change in a change adverse group. The basic concept revolves around a personal mantra of mine "First get it done, then figure out who owns it." and I've successfully used the tips I laid out in the blog.

Essentially you start by doing it. It's a lot of up front work, but people start to see the value and adoption follows. In the case of the daily status, use your feet and go out and talk with everyone. Then publish a status report based on the information you collected. Once the value is shown, you can start changing it. Start by sending out the status report and saying "Did I miss anything", then sending yesterdays and saying "anything changed? Are you still red on the DB integration."

This only works once you've built trust. You can't do it on day one. My own preference is "Do no harm for the first 90 days." Spend your first three months with a team building trust. Then start introducing new ideas.

Best,

Answer 6

In my opinion there is no single best approach to project management. There are projects and teams where daily reporting brings best results but there are some, where results of such approach would be poor. It is the PM duty to fit the best approach to a specific project.

If projects in your organization don't need such a rigorous approach (important: and it is proven in battle) there are two options for PM: stay or leave the organization. If PM chooses to stay (which means he accepts loose and flexible approach) he should learn how to manage projects in such an environment. Another question is: how should he do it?

Answer 7

There are a couple of ways that I would look at this.

1. If the PM is setting more rigorous standards than the company norm, that's within his right as the manager of the piece of work, and he can ask this from his team if he thinks it helps him to deliver. If they don't like this, they have to justify to him why it's a problem - and at the same time, he should be explaining to them why he wants what he is asking for. Hopefully they can reach a common understanding and agreement. The bigger problem would be if he was looking for less rigorous standards than the company requires, as he is then reducing, rather than increasing, the quality standards.
2. The reporting and quality requirements should be defined at the outset of the project, and agreed by the key stakeholders. If the PM has proposed a level that the project sponsor/ executive doesn't like, then the PM has to fall into line. But if the sponsor/executive is OK with the proposed reporting, the PM can drive forward his own standards.

These two perspectives are not necessarily mutually exclusive, and ultimately the company culture will have as big an impact as the rules that are written down (assuming that they are!), so there is no single right answer that will always apply.

It would be good to imagine that the PM might be sufficiently open-minded to try new ways of operating, as we are all capable of learning new techniques. Flexibility can be a virtue, and ultimately I believe that using the right approach to meet the circumstances will deliver a better result than always approaching problems in the same old way. There's an old saying that if the only tool in your toolbag is a hammer, every problem starts to look like a nail. Maybe this project manager needs some new tools!

Answer 8

The main question is: how is the current organisation working? If projects are done in budget and time without teams going crazy, I see no need for a change.

On the other hand, if major issues in the workflow exist, it's probably a good thing somebody is trying to improve the process.

Major rule: Don't change what's working, don't repair what's not broken.

Answer 9

but they turned his request down leaving much flexibility to project teams

It means that he is not a project manager, but a project coordinator (according to PMBOK). The management doesn't provide necessary authority to the person to manage the project. It means that it's not a project management any more. If the person is interested to stay a coordinator - let it be this way. Otherwise it's necessary to discuss authority problem with the management first. Project Charter is where such questions/concerns are raised and baselined before the project starts.