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.
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:
- Management got what it asked for, but it asked for the wrong thing.
- 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:
- 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.
- 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.
- 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.