Just north of us is an Amgen manufacturing plant. There is an opening for a senior project management for their control systems projects. The job description outlines the usual technology background, work experience in the pharmaceutical environment and FDA regulatory experience (cGxP and 21CFR Part 11). No mention of PMP or other PM certs which is common (no mention) here in our high tech market place.
What struck me more from the posting was the similarity between this position and the roles played in our aerospace PM and Planning jobs.
It is assumed the "customers" know what they want, can recognize the solution when it appears, and have criteria by which to judge the attributes of the solution. For the pharmaceutical software control systems it is ANSI/ISA-S88 and S95. I have some background in the process control area, but it occurred long before these standards came on the scene.
Now just because there is a standard for development and integration of software control systems, it doesn't mean there are fixed requirements, easily planned projects or simple process steps on the way to success. In the aerospace world Systems Engineering process steps are well documented and deployed across the board. Earned Value and other project management processes have similar penetration. Every planner must know the details of EVMS, IMP/IMS, Contract Performance Reporting. Every Systems Engineer must be capable of managing requirements, flowing those requirements to the various subsystems - this is the role of systems engineering - and assuring that those requirements result in a full tested, operational product.
So why is it so hard for software development to have an on-time / on-budget / on-performance project management process? It turns out of course that the pharmaceutical and aerospace software development projects have problems with cost/schedule/functionality as well. But they are not the same problems.
In the absence of some guiding plan on "what and when" and maybe "how" a software feature will be delivered, software projects have not means of projecting the future - "when will we be done, what will it cost, how do I know it works?". What this seems to say is there is no theory of how software projects should be managed. There are theories for managing construction projects. The Lean Construction folks have one. There are theories for managing spacecraft development projects. NASA requires a contractor to describe how the Program Management processes will be used - the Systems Engineering Management Plan (SEMP) is a deliverable.
I started a paper long ago with the concept that project management in general could be understood as a "control system." I got diverted on to other topics - Systems Engineering mainly. But it may be time to revisit the idea that many of the failures in software project management come from the lack of an understanding of the underlying processes, how these processes interact to create trouble for the project and how these troubles can be avoided.
This is the role of a system engineer in the spacecraft business. There is no similar role in software development project management.
