A PM's utility

Warning: This post is really an experimental one; just playing with some thoughts about the PM function. Not my intention to offend but the question is:

So how useful are PMs (Project Managers just in case you didn't know)?

Frankly I'm not very sure!

Of course it depends on the project. Not every project needs a BA or PM.

Everyone on a team should be thoroughly invested in 'caring' about the product, not just task-mastering so that things get done. PM activities are essential actually. But is a separate PM truly necessary? I think the best approach is to either hire BAs with PM experience or Developmental Leads with PM experience. That way PM tasks are kept to a minimum but also reside with personnel who are invested in the product.

In Six Sigma terms, the most useful ppl to have on a project are those who are adding value to the product.

A BA talks to the business and therefore represents and speaks for the business to the dev team. The BA represents the business so s/he wants to ensure a quality product.

The developers are developing the product and so will put care and precision into crafting something of quality.

In my own (and certainly limited experience) PMs engage in many not-required non-value-add activities. Is the customer willing to pay for communication or chasing down people to get tasks done? These are overhead tasks that are necessary but also don't add value. In six-sigma terms, these are NVA, non-value add activities and should be minimized. Hence, my call to eliminate the PM position in areas where you are able and to place only the least amount of PM activity with other members of the team who also engage in value add activities.

Let's look at wikipedia's definition of the activities a PM engages in:

1. Analysis & design of objectives and events
   
2. Planning the work according to the objectives
   
3. Assessing and controlling risk (or Risk Management)
4. Estimating resources
5. Allocation of resources
6. Organizing the work
7. Acquiring human and material resources
8. Assigning tasks
   
9. Directing activities
   
10. Controlling project execution
    
11. Tracking and reporting progress (Management information system)
12. Analyzing the results based on the facts achieved
13. Defining the products of the project
14. Forecasting future trends in the project
15. Quality Management
16. Issues management
17. Issue solving
18. Defect prevention
19. Identifying, managing & controlling changes
20. Project closure (and project debrief)
21. Communicating to stakeholders
22. Increasing/ decreasing a company's workers ...
    

In particular contexts, these activities make sense and in others they don't. If you're running an agile or lean software development project then a lot of these can be eliminated entirely and others can be offloaded to other personnel.

The gist of this post is to just get you thinking on the type of projects you're running and not to blindly throw a PM, BA, Dev Lead team together and expect to get the job done. You could be slowing the project down actually. The BA and Dev Team could run with the project a whole lot quicker than with a PM overseeing everything trying to get updates.

In my environment, what seems to truly work is:
1) Hire BAs who are comfortable with and can talk to both the business & development on an everyday basis.
2) Hire BAs with PM knowledge
3) Hire Dev leads with PM knowledge