Yesterday’s post described the project management environments I encountered earlier in my career. The unifying themes of each environment are that the formality and intensity of project management techniques are proportional to the scope and scale of each project. The longer each project goes, the more people who are involved, and the more steps there are, the more effort must be expended to plan, track, and communicate. The project management environments in my most recent three companies shared some of the characteristics of those of earlier companies but differed in that the recent positions were usually less project-oriented and more product- and service-oriented, although all of my work involved developing and employing complex software systems.
American Auto-Matrix, Senior Software Developer, HVAC Industry, 2000-2002
AAM developed and sold a line of HVAC controls to third-party integrators. Its internal management structures were all product-based, though billing codes were sometimes issued for specific activities (e.g., specific R&D and troubleshooting efforts for individual products and customers). As such all management was based on continuous streams of income and expenses over the life of each product rather than on the activities associated with specific projects. This article provides a nice discussion of the differences–and the overlaps–between project and product management. Because of these differences I won’t describe the PM environment in terms of projects but of products.
Conceive: Each product was conceived in the context of providing additional capabilities to the product line as a whole, and in response to needs identified to address customer desires and the moves of market competitors.
Plan: Different managers oversaw the development of hardware, software, firmware, manufacturing, and marketing of each product. The company was small enough and the product line limited enough that management was conducted in matrix fashion by department, across all items in the product line. One of the things I looked at during my tenure was the matrix of features across most of the control components. I wanted to see how consistently they implemented different features and see if there was a way to standardize the firmware and software for each to make it modular across products. The hardware of used in each product was sufficiently varied to preclude such an approach at that time, though I believe that with the advent of more powerful yet ridiculously inexpensive processors that can be programmed far more quickly using high-level languages that such an approach could be effective used. We could even have used a team approach that standardized sections of even custom-developed assembly language firmware in a way that enhanced the sharing of knowledge and standardization of techniques. As it was each engineer worked more or less in isolation, maintaining their own firmware and software archives.
Develop: New products were developed in a project-like fashion and then maintained and upgraded over time. The company maintained backward compatibility to even its oldest products and even maintained the ability to manufacture its earlier products with minimal overhead. In terms of software, as mentioned above, the engineers largely worked in isolation. Only the PC-based HMI product called Auto-Pilot was routinely worked on my more than one person, and the team coordinated the sharing, modification, release, and archiving of versions on an ad hoc basis.
Qualify: Products were tested in-house, then at limited locations in the field, and then made available for general release.
Launch: New products were released with accompanying marketing support, training of the technical support staff, appropriate updates to the company’s website and printed materials, and so on.
Deliver: Control units were manufactured and tested in batches in response to order placements and to maintain an appropriate stock on hand. Most distributions were accomplished through third-party integrators.
Retire: All information and manufacturing equipment related to products that were phased out were archived. The appropriate modifications were made to the company’s website and printed materials.
Regal Decision Systems, Program Manager/Technical Manager, Software and Operations Research Industry, 2002-2010
Regal’s work was usually project-based but one major effort had many characteristics of an ongoing product and one was clearly managed as a program. Rather then try to break them all down as I have previously I’ll describe how each worked.
The program I ended up managing involved placing employees with various customer organizations in the Naval Aviation community. The day-to-day activities of the workers employed by our company and by three different subcontracting companies were all managed by the customer. We just tracked their hours, pay, and benefits. I had to handle monthly and yearly reporting, budgeting and invoicing, finding replacement employees, renewing task orders and partnering agreements, supporting and responding to customer evaluations, and so on. I also managed a satellite office along with its utilities, furniture, and amenities, the computers used by all employees under the NMCI program, raises and communications with the home office, transition of managers in the customer Program Management Activities and the NAVAIR contracts office, travel and expenses, security clearances and secured visits when applicable, and more. All told there were up to 35 employees working across four task orders.
The product/project hybrid I worked on was quite interesting. The company was charged with building a tool to simulate inspection activities at land border crossings, and the tool, which was continually enhanced over the course of multiple contract cycles. Individual analysis efforts were managed like projects (or task orders within contracts) and the simulation software was managed like a product whose cost was amortized over the individual analysis efforts within each contract period. Changes to the software were driven mostly by internally identified needs that arose from the analyses we preformed but occasionally were requested directly by the customer (which was the GSA, or the General Services Administration; DHS managed the inspection processes and GSA managed the properties themselves, sometimes in conjunction with private owners). The configuration management of the software was mainly done by the senior software manager, but the team may well have used a source code control system. Most analysis projects involved sending a team of data collectors to do discovery and collect data in the form of video, counts, drawings, pictures, and capture from automated reporting systems. Permissions and travel had to be arranged in those cases. I worked on the analysis of a new port built near Calais, Maine. That involved meetings with different architects and government offices, estimations of expected traffic volumes and composition, construction of multiple models based on alternative designs, reporting of results, and offering of recommendations. The projects varied in scope and scale as did the planning and the nature of the deliverables. Over time the GSA worked with Regal to define a formal analytical procedure and report format. I thought they made the process needlessly burdensome and complex but everyone else seemed satisfied with it. Additional products/projects were developed for land ports of entry in Canada and Mexico as well, and I led the discovery process on many of those trips and wrote the various requirement and technical documents.
The rest of the company’s activities were project-based. They had defined beginnings, middles, and ends and rarely extended beyond a single contract phase. I managed or co-managed a number of those efforts and handled much of the reporting, communication, customer interfacing, and requirements analysis.
RTR Technologies (split from Regal Decision Systems), Senior Process Analyst/Senior Computer Scientist, 2010-2015
RTR had two main customers, an analytical arm of Naval Aviation and the Department of Homeland Security. The occasional work I did for DHS was usually project-based and of limited duration. The project management was usually lax from both our side and from the customer’s side, which proved to be a problem more than once. Other parts of the company maintained more of a product/program relationship with DHS. Most of the work I did for NAVAIR, and the work I was mainly hired to do, involved performing logistics analyses for different Navy and Marine Corps aircraft. Most of the analyses involved configuring and running simulations of inspection, maintenance, and operational activities. As is the case with the border simulation software written by Regal, RTR’s Aircraft Maintenance Model (AMM) was managed like a product while analytical efforts were managed like projects. Project and product management was somewhat ad hoc here as well, and RTR’s senior manager help all financial information close to the vest. None of the project or product managers had a clear enough picture of how the projects were running with respect to cost. The company’s owners also took a long time to recognize that they needed to bill more hours to cut down the burden of overhead across the activities of a relatively small company. Some of the company’s software products were managed using source code control systems but other software components were managed by individuals manually in designated directories on different servers. All supporting documentation was managed manually, though phased updates were stored in a SharePoint system dedicated to each aircraft modeled by the AMM. The AMM software and procedural framework was also managed by a formal Configuration Management Board. The Board held formal meetings and tracked requests for modifications over time. The company always operated in an Agile, iterative format but began to formally adopt Scrum techniques piecemeal over time. I served formally as a Product Owner on on the the DHS projects. That was quite easy to adapt to because I had essentially been doing the same thing for years.
The takeaway is that I’ve seen most combinations and permutations of project, program, and product management methodologies over the years, and I have worked in many capacities within those frameworks.