The official position of project manager (PM) as it has been explained to me is one in which the PM may not have managerial control of project subordinates and must use persuasion and communication to keep the project on track and the team members delivering. The contemporary PMI definitions make the PM responsible for several project guidance and reporting deliverables, and providing these represents actual overhead costs. Although some will say the effort involved in being a PM is not enough to justify it as a full-time role, I would argue that it could be, depending on the project and complexity.
Resource Management
In my past experience with PM work, one of the things I've struggled with is when members of the team are expected to materially participate in the PM duties. If your projects are anything like the ones I've been on, then you're familiar with the corporate American tendency to want things as fast as possible. Especially with software, it shouldn't take long because software is just a bunch of typing and how hard can that be?
But as the blog has noted before, software is only easy if you want to produce garbage. It requires real focus and a mental investment to create effective software, and when the programmers have to also spend time delivering project management deliverables, the programmers are forced to spend less time on analysis, design, construction, and testing efforts. That often leads to frustration for both the developers and the PM.
It is not wrong to expect some developer input in PM deliverables, but certainly this is overhead that needs to be considered lest the staff feel they are once again forced to work unpaid overtime to produce something other than actual product.
PMs versus Developers, Users, and Analysts
The overhead of PM work distributed among the team can at least be managed. There's a more serious disconnect that can happen when it comes to the subject of determining project quality. Scott Ambler's written a little about this in his blog at Dr. Dobbs Journal.
To summarize, Ambler ran a survey that included questions about how project members define IT projects a success. Although the survey sample was modest (Ambler got roughly 600 responses) some of the results alarmed him. He found that:
"It appears that project managers are more interested in delivering on time and on budget than delivering when the system is ready."
He conceded that the sample size didn't include more business stakeholders and so the statistics might need to be taken with a grain of salt, but the general thought does make sense. The goals of the PMI would certainly stress "on time and on budget" as measurable goals. Software quality, on the other hand, is harder to measure. Because of that, it's also hard to estimate the effort needed to reach it in planning phases. The concept of quality is also subjective and that doesn't help matters.
Maybe Software isn't a Project
Here's another idea. Software is a living document. It changes over time and as long as people are using it and maintaining it, it's never done. Does that sound like something you can harness with a beginning, middle, and end?
George Stepanek, the author of Software Project Secrets (Apress ISBN10: 1-59059-550-5), notes that the formal project management methodology is not a good match for software development. Static phases like initiation, planning, and concluding are more a match for traditional waterfall software methodologies than newer "agile" methodologies. Although I'm not as down on waterfall as most are (all waterfall did was win WWII, send a man to the moon, and get the space shuttle into space, among other things), there's no denying that regardless of approach, software is a series of iterative feedback loops between developers and users that extends far beyond a stated project period.
Software Management and Project Management Must Coexist
Neither software nor project management are going away anytime soon. Software has become a part of our everyday lives and project management adds appreciable value in helping to "divide and conquer" the body of work corporations do. But developers and project managers have to continue to understand the disconnects between traditional project approaches and software development and also make strides in measuring software quality. If this does not happen, then the industry will continue to be filled with projects that are only successful on the surface. It will continue to be a place that graces a few with bonuses while leaving behind train wrecks for others to clean up in the late hours.
