2

I work in a small digital agency where we have the following roles:

  • 1 Managing Director
  • 1 Partner
  • 1 Technical Lead
  • 1 Project Manager
  • 1 Designer
  • 3 Developers

Our day to day work is a mixture of planned projects, support & maintenance for existing clients, and pitching and scoping for new business.

Before our PM started we had very little process in place and little or no resource planning. The nature of the business makes resource planning difficult as we have a lot of support work and we frequently have jobs come in at very short notice with short deadlines which require resources being taken off planned project work.

As we were doing a terrible job of managing resources, we decided to hire a Project Manager. When he started he asserted his preferred way of working, which involved sending an email every morning which gave a list of tasks to be done that day for everyone except the MD. He would then ask that everyone email him an hour before the end of the day stating the progress of each if their tasks.

This approach soon started to grate with people, especially the Partner and Tech Lead. It seemed like micro-management to the extreme, and left no room for the general unscheduled tasks that crop up on a day to day basis.

For quite some time, most people would forget to send their update email the PM near the end of the day, and eventually he accepted that it might not be the most efficient way of working.

The main area of confusion is where the PM's duties should stop and the Tech Lead's begin. The PM has very little technical knowledge but assumes the role of assigning individual tasks to the Developers, Designer and the Tech Lead. This frequently leads to tasks being assigned to the wrong people, and also frustrates the Tech Lead as he feels this should be part of his role.

Would a PM normally be assigning fine-grained tasks to individuals in a small team, or do we have an over-zealous PM?

5 Answers 5

2

TL;DR

Would a PM normally be assigning fine-grained tasks to individuals in a small team[?]

Your question is non-deterministic. Project management is simply a discipline; the scope of the project management role is defined by each organization. Your organization should re-evaluate its management goals and restructure its development process accordingly.

Command-and-Control

The command-and-control style of project management is widely practiced, especially in organizations that embrace non-agile project management frameworks. If the role has been defined as an authoritative role, then a PM is often expected to assign tasks and "hold people accountable."

Whenever a PM is held accountable for doing things that rub the organization the wrong way, then the organization should carefully re-evaluate what they expect from the role and how they expect to measure the success of that role. Evaluating a PM based on the performance of team members is like asking for command-and-control behavior; if that's not desired, then senior management must restructure the team and/or the project management role.

Management Made a Choice

As we were doing a terrible job of managing resources we decided to hire a Project Manager. When he started he asserted his preferred way of working, which involved sending an email every morning which gave a list of tasks to be done that day for everyone except the MD. He would then ask that everyone email him an hour before the end of the day stating the progress of each if their tasks.

In other words, the organization had a problem, did its due diligence in hiring someone who espoused a philosophy that fit management's desired management style, and is now disliked for applying the controls that he was hired to enforce. This is not a recipe for success.

There are two choices here:

  1. Management got what it asked for, but it asked for the wrong thing.
  2. Management is getting what it wants, but the team is unhappy that things are no longer "business as usual."

I sincerely doubt that the PM decided that "it might not be the most efficient way of working." It seems more likely that he simply got tired of taking flack for trying to impose some structure on your team.

None of this is to say that there might not be a soft-skills gap here, or that there aren't other team-management methodologies that might be more effective in your particular organization. However, from the background you provided, it certainly seems like a leadership failure in the management ranks, rather than a failure on the part of the PM.

Process Slack and "Invisible Work"

It...left no room for the general unscheduled tasks that crop up on a day to day basis.

This is a symptom of your organization's business-as-usual mindset. If you routinely have "unscheduled tasks," then you either need to bake those into your estimates, or define a standard process for managing such tasks outside the project schedule. A project manager cannot manage tasks which are unscheduled, unreported, or unaccounted for.

While a good project manager will ensure that there is sufficient slack in the process to handle routine variances, invisible work is (by definition) unaccounted for and unmanaged. The fact that your organization doesn't make this distinction is a "process smell" that indicates something is fundamentally broken; expecting a PM to be responsible for the results of a broken process without empowering either the PM or the team to adapt the process is a recipe for failure.

Recommended Solution: Inspect and Adapt

There are a number of things that ought to happen at this point. To start with:

  1. The management team needs to redefine the role of the PM within the organization. This re-definition ought to include not only the responsibilities of the role, but also clarify how the successful execution of the role will be measured by management.
  2. Management needs to define a clear goal for the development team. There's clearly a reason why they thought additional process controls were needed; those reasons need to be made explicit for everyone in the organization.
  3. The entire team should re-evaluate their existing processes, and consider how to adapt those processes in the most effective way possible. This may entail a different project management approach, but it will also require some changes to business-as-usual for the team.

This dialogue is simply the start of the process engineering that needs to take place. Affixing blame for "things as they are" shouldn't be the objective here; the goal should be continuous process improvement.

1

I don't think I would necessarily describe your PM as 'over-zealous'. The PM has tried to instigate a system in an organisation that you accept was lacking in this respect. The system clearly has its problems, which, again, you say the PM has accepted.

What I suggest is that the whole team (but particularly the PM and tech lead) work together to understand what does and does not work in the current system and make changes accordingly. Ultimately the PM's responsibility is to make sure projects are completed on schedule and meet the requirements of your clients. If the PM consistently fails to assign tasks to the correct person then work is not being completed efficiently - this is one clear area for improvement.

The scope and range of responsibilities for a PM can vary enormously from organisation to organisation. In some places they can end up being glorified administrators, while in others they play an active role in product development.

You could consider looking at Scrum (or some 'lite' version of it that you can adapt to your organisation's needs) and turning your PM into more of a product manager so that they are concentrating on what the client wants/needs while leaving technical work to the dev team. However, to make this work the dev team are still going to need to track their work and commit to completing work on time (doesn't mean it will always happen, but it gives everyone more ownership and responsibility).

If the underlying problem is actually that your dev team resent being given deadlines and tasks after years of autonomous working then you also need to tackle this problem. Ultimately everyone is there to do a job. An inclusive approach will make sure that the system you implement works for the whole business but be prepared for some push back!

0

It would be hard to assess what the PM is doing in an unbiased way just based on what you wrote. I can imagine he grated on you, as well, and perhaps maybe you are a tech lead whose role is now a bit ambiguous with the PM's.

Notwithstanding all the soft skills you would want in a PM or any leader, much of what PM is, is about controls. For a company who, by your admission, was out of control, this person coming in putting in any type of PM methods would likely be received as "grating." Change is hard.

I won't comment whether I agree or disagree with his methods as you indicate here, but I would opine that I would be looking at the organization as root cause of the issues you now face versus what this PM is doing.

Your organization needs to evolve. You gotta let it happen. Watering down the authority of the PM so that things can stay largely status quo will pretty much seal your fate.

0

Before you put this down to an over-zealous PM, look for root causes. As Willl suggests, this could be a resistance-to-change question, stemming from the team playing loosey-goosey for too long.

You should also consider why the PM has taken the approach that he has. Is this how things were done at his last work? Is he acting on guidance from the MD? Are the leaders not doing their jobs when it comes to managing resources?

To resolve this your organization needs to clarify roles and responsibilities that will work for you. Even more importantly, you need to establish performance expectations and clear lines of accountability. It's nice to say that the PM is responsible for bringing a project in on time/budget/scope/etc, but if the team leaders are dropping the ball you can cycle through all the PMs in the world and you aren't going to get better results.

0

My take on this is that the PM is trying to establish a sense of discipline into a company that has previously had a "freewheeling" attitude. I don't think he is being too zealous - but perhaps his method is not appropriate.

For me, the role of the PM should be to know what is due to be done, to know whether it remains on target, and to understand and manage the risks around the project. There will be other duties too, probably around project finance and management reporting, and an effective PM will certainly help the rest of the organisation by handling that side of the work, letting them concentrate on what they do best.

You ask about the roles of the PM vs. the Tech Lead: Assuming the tech lead manages the developers, I would not expect the PM to be communicating with the developers directly - that should be the role of the tech lead. The tech lead should, of course, be able to explain what progress has been made at any point in time, but he should also have the autonomy to allocate work as appropriate within his team. In terms of allocating work to others, I would suggest that the PM discusses this with the individual rather than imposing his own thoughts.

I do wonder whether the issue is the level of control that is being imposed, or whether it is the means of imposing it. In a small company such as you describe, a daily email to and from the PM sounds very bureaucratic and impersonal. I would prefer to handle the communication face to face, because this allows a conversation to take place rather than just passing on facts and figures.

I would also suggest that the frequency of contact should perhaps be different depending on the levels of trust and the nature of what each person does. If a task will take a week, a mid-week checkpoint may be appropriate, but a daily check may be too frequent. On the other hand, for tasks that are only a few hours in duration, a daily check may be just fine. Horses for courses!

In summary, then, it feels as though the PM is trying to impose disciplines and make decisions for the right reasons, but is not using the appropriate interpersonal communication to achieve the desired outcomes. Get him to talk to people more, and get off his pedestal. But the rest of the team also need to change, and recognise and accept the authority that he was presumably given when he was appointed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.