Technical Software Project Management is Dead

I’ve manage projects, I’ve lead them, I’ve been a developer, I’ve tested, I’ve organized releases, I’ve done all the paperwork. It’s just that lately, that seems to be the role expected from the developer on any given project. Don’t get me wrong, project managers are great. I still have never hired, fired, had to argue for the budget. Yikes! All these things have nothing to do with actually building the software. However, try developing something with no money and no resources. You won’t get very far. A while back, I ran into a great article by Robert Bogue about software development roles –

Cracking the Code

It has a great layout of all the different roles and tasks in software development. Now I don’t prescribe to the notion that projects require to have all those positions separately staffed. There’s typically overlap, but I do think the roles outline tasks that occur on just about every project. I’ve begun to wonder if all these tasks are falling on the shoulders of developer and wondering why.

First off, let’s take a look at these roles. The diagram of roles –

Obviously, the developer is the developer. That hasn’t changed. In this day and age, the developer is often the lead and solution architect. There may be multiple developers on the team, but customers and management don’t care, pick one to get beat up in status meetings, they’re the lead. I do see architect positions around. I’m not sure what qualifies somebody as an architect. If you are the sole person on a project, I guess you are an architect. On a team of developers, the smartest one with the best ideas tends to become the architect. I think this actually works out well. Got ideas? Similarly, whichever developer articulates the best let them be the lead. They don’t need to be brilliant, just able to communicate to non-technical types.

Don’t even get me started on QA, deployment, and training. Who really has software testers these days? I don’t know if they exist. I’ve never actually met one. So, the role assignments are getting clarified-

1. Developer – assigned to the developer (obviously).
2. Development lead – the developer picked to attend status meetings with customers and managers.
3. Solutions Architect – the smartest developer (or only developer).
4. QA (testing) – the developers do the testing. I still propose that somebody other than the developer should officially execute the test plan.
5. Deployment tasks - give to the developer.
6. Training - that goes to the developer, too. If you’re good and thorough creating class material, you might be able to get somebody else to teach the classes.

What about the Analyst and requirements? Well, the developer is going to build it, so who better to write the requirements than the developer? This is one of the bigger mistakes I see, having the developer author all the requirement documentation. This leads to a system that meets the requirements exactly. Unfortunately, the customer does not get what he needs. Relating customer wants and needs into requirements that developers understand, requires a talent that not many people are gifted with. Even with Agile development cycles, which is geared towards changing requirements, good requirements can reduce the number of sprints and cycles.

They should have the vision of what the system should do. This should relate to problems with the business that need to be solved, thus justifying the development project. In reality, the subject matter expert is the customer who explains how his business is currently so messed up, that he doesn’t know what to do. He’s got a half-baked plan and lots of presentation material that convinces somebody to fund the project. The developer assigned, get’s to know the business, tells the customer what’s wrong with their process, how he can fix it, and how long that will take. Dreams meet reality. In my experience, the SME is somebody that knows the business, processes, and problems well. This is who the analyst should be talking to, this person knows what the real requirements are.

Now that we’ve gone through the other roles, we’re getting to the point of this post – The Project Manager. An excerpt from PMBOK-

"Project management is the application of knowledge, skills, tools and techniques to project activities to meet project requirements. Project management is accomplished through the application and integration of the project management processes of initiating, planning, executing, monitoring and controlling, and closing. The project manager is the person responsible for accomplishing the project objectives."

This means that the project manager’s name comes after the project name and before the milestone dates on the scorecard. They are responsible for getting the project from point A to point B. In my opinion, a good PM should –

1. Understand all the requirements, even though they may not have written them.
2. Understand the system architecture and technology being used, even though they did not design it.
3. Understand the tasks and their dependencies. This enables them to schedule tasks appropriately.
4. Know where all the project documentation, issue list, and code is.
5. Know where the test system is and what version of the system is on it.
6. Be able to run and demonstrate the system.
7. Understand the development life cycle and know where the project currently is at in the life cycle.
8. Be aware of the current unknowns and holes. These are tasks that aren’t really defined or tasks that don’t have a developer available.
9. Understand the above items well enough to make informed decisions about the schedule and priorities of the project.

I’m sure there’s more, but the list is tall enough. A good PM is a developer’s dream. Unfortunately, the person assigned the role of PM is becoming more of a project analyst –

1. Reports to management and customers what’s currently being done, who’s working on what, and what the current issues and grievances are.
2. Reports back to the team the milestone dates that customers want and functionality they want.

So, the PM is the unlucky soul that gets yelled at by management for missing dates and yelled at by the developers for giving them impossible goals. On occasion, you have the aggressive PM who yells at the developers and management. In either case, it seems, impossible goals lead to missed dates and a fair amount of yelling.

The iron triangle of features (scope), resources, and time can be ignored, but I’ve yet to see its laws broken. Tricking or breaking the iron triangle is not the point of this discussion, so let’s not dwell on it.

The point is what happened to the good project manager? Did they all run off and hide? Are they all taking extended Project Management Institute training? My theory is that they did not evolve. Perhaps some did, but many did not. The evolution of software development and the ever increasing pressure to get more productivity from less people is squeezing the project manager position into extinction. I’m not saying the role and tasks associated with project management are disappearing, what I’m saying is the developers and other team members are now doing those tasks. Let me explain some reasons why.

In the old days project managers typically came from the developer ranks. They understood the technology and how to get projects done using it. They could judge whether an architecture design was sound, if requirements made sense, how long that task would really take. Today, technology moves too fast. People that are not intimately involved with the technology being used can’t make good decisions on architecture, requirements, and tasks. Only the developers understand the technology, what can and can’t be done with it, and how long it will take. The PM fell off the learning curve. It’s really not possible for them to keep up.

Productivity in the world continues to increase. We hear of reports about the increase of goods produced by workers continuing to grow and grow. How is this possible? It’s possible with technology. Well, software is all about technology. New development tools and software are enabling developers to do more with less. Agile processes speed up the pace of development. I used to estimate that a project manager could manage no more than 2 significant projects at one time and still do a good job (reference the good PM list above). Today, project managers are assigned 5-10, or even more, projects at a given time. How do they do all that? How do they do it well? They don’t. There are new tools that help track issues, make schedules, and other management tasks. However, the people using these tools are more and more likely to be the developers, leads, and architects. This trend is not limited to project managers. Tools for testing, training, and requirements gathering are all enabling developers to do more. You could argue that these tools would also allow analysts, trainers, and testers to do more. I would agree. I would love to see that occurring. Unfortunately, I don’t.

In conclusion, the old position of project management is becoming a thing of the past. There will always be managers, customers, and developers, but managing projects is becoming a task that developers must do. Taking an excerpt from Robert’s article –

The Project Management role is the first role in the software development process that isn't on the main line. The project manager isn't a person doing "real work."