Introduction
This is not really a diatribe against the idea of project managers, but rather a look at the automation tools, methodologies and cultural practice changes that could be employed to make software teams able to function without human oversight, or at the very least with such an oversight function being only a minor part in a team member's responsibility.
Note that this only applies if you are dealing with internal software development teams, because outsourced / contracted out operations involve two sides with differing objectives1.
Background
If you do a Google (or Bing) search for "What does a project manager do?" (after about the third page of links to rants and blog posts), you can find the following basic outline:
Typical responsibilities include:
- agreeing on project objectives
- representing the client's or organization's interests
- providing advice on the management of projects
- organizing the various professional people working on a project
- making sure the quality standards are met
- using IT systems to keep track of people and progress
- overseeing the accounting, costing and billing
This is quite a large list but by taking each in turn, I'd like to propose ways to automate or eliminate them.
1. Agreeing on Project Objectives
The need to have someone map out and agree on the project objectives, usually with a signed-off and unchangeable specification is a historical legacy of a time when those paying for the project had no realistic idea of what was possible and how much anything would cost. The project objectives would map out a set of realistic objectives that could be achieved within the available budget.
However in most industries, and especially in any industry where a company has an internal software development function, the clients/stakeholders have a significant amount of experience of past projects and of industry information which they can use to establish for themselves what is possible and what the required budget should be. Indeed, it is often the case that they have put together a cost/benefit analysis and maybe even pitched the project to senior management before any development team or project manager became involved.
Therefore, the project objectives should be agreed upon before the project becomes a "software project".
2. Representing the Client's or Organization's Interests
If a project is assembled by the business and the development team jointly pitching the project to senior management, then the interests of the business and development team will largely be aligned which reduces the need to have an individual represent the organization's interests.
To ensure the continuation of this alignment between the project goals and the business requires a rethinking of how projects are financed. Instead of having an up-front end-to-end budget agreed upon at the start, the business should provide an up-front "seed capital" budget sufficient to get the first release into production with ongoing capital being a function of the realized benefit of the project. This Darwinian approach to project management also ensures the most successful projects get the budget they need and small failures are extinguished before they become big failures.
3. Providing Advice on the Management of Projects
In this role, the project manager is a boundary or an interface between the business and the development team. They provide status updates and projections for deliverable and make sure the businesses are kept up to date with the project's progress. Typically, this involves collating information from the team on defects closed, features implemented and estimated time to complete and presenting them in a slide deck or dashboard for periodic review.
There are a large number of tools that can provide a live view of precisely this "slide deck" and make it public so that the business can always track the project - JIRA and Team Foundation Server being the most popular. Using burn-down charts and Kanban views can also give a more realistic view of progress and estimates for completion than any polling of the team members and most importantly of all, can do this without interrupting the development work itself.
4. Organizing the Various Professional People Working on a Project
This follows on from the point above. Truly "professional" people should have the discipline to self-organize and when a team is working well, the internal dynamics of the team will keep every member of that team on the right track.
When everything happens in the open (by having the burndown charts, quality metrics and Kanban boards publicly available), the amount of external organizing required drops off completely.
5. Making Sure the Quality Standards Are Met
There are two different categories of quality standard that fall under this heading: code quality and application test state.
Code quality is about ensuring the source code itself is easy to understand and maintain and follows "best practice" guidelines. The actual specifics of this best practice varies from language to language (when to deallocate objects, scoping variables) and from team to team (naming conventions, mapping code elements to source code files, etc.)
Application test state is about making sure that all of the code that goes into production is tested. This starts at the bottom level with developers having unit tests for their code right up to top level user acceptance tests.
Once again, this is an area where a number of software tools have been created.
6. Using IT Systems to Keep Track of People and Progress
This has been covered by points 3, 4 and 5. The key message is "published dashboards".
7. Overseeing the Accounting, Costing and Billing
If projects are funded using the "seed capital + % of returned value" model, then keeping costs down becomes a significant concern of the project team, and at the same time, the business has built-in protection against cost overruns and zombie projects.
History
- 23rd September, 2015 - Initial thoughts
Footnotes
1 Yes - they do. That is why contracts are written and money changes hands conditionally.
