As a former top-flight consultant who has been deeply embedded in IT software development AND product development orgs for over 25 years, I see many things habitually done wrong. I mostly bite my tongue and keep these observations to myself (ahem…mostly). The most common and destructive failure I continue to encounter is the misapplication of management style. Let’s get into this.
For various reasons, software development has long been overseen by Project Management. Since the 1970’s, every major attempt to reform software development with an iterative-incremental lifecycle, from Royce’s Waterfall to Boehm’s Spiral to Rational’s Unified Process to modern Agile, has run into the same brick wall: Project Management.
Project Managers will listen and nod, but ultimately continue managing the same old way. It does not matter what iterative-incremental approach is currently fashionable because project plans will be etched into Gantt charts, progress will be reported against plan milestones, unrealistic risk mitigation strategies will get briefed, and false estimates of earned value will be accumulated. Projects will be late, over budget, and unhappy. Products will suffer poor execution and missed opportunities for competitive dominance. With rare exception, this is how it has always been.
Stop it!
Project Management Unpacked
Project Management earned its place, I am not a hater. However, I believe one should avoid reaching for the wrong tool when a better tool is available. For software development, one should never reach for Project Management.
THE GOOD
Project Management is good for planning workstreams with dependencies, where the division of labor is substantially diverse. For example, a construction project has many workstreams.
Figure 1: Project plan from a real-world construction project
You might notice from this real example that the project management plan does not attempt to drill down work within a division of labor (e.g., pour concrete) to manage micro-execution. Pouring concrete consists of multiple steps with dependencies, but those are not explicitly managed because specialists will ensure the pour is done right. However, the work of pouring concrete requires different specialists than underground electrical, so those tasks are planned separately. When work requires transient specialists with different dependencies, it should be broken down for scheduling. However, work assigned to a single group with a common dependency framework does not benefit from recursive scheduling. In fact, it can be quite harmful.
Let’s frame this another way: one does not plan a construction project around itemized feature counts, one plans construction around the division of labor. For example, you won’t find “install bathroom faucet #3”, you’ll see “plumbing fixtures installation – 5 days”. Project management is ideal for variable capacity systems comprised of transient elements, where each element must be scheduled to arrive and depart on an orchestrated timeline to maintain velocity.
One would NEVER encounter project management on a factory floor where there are persistent stations, stable capacity, and a continuous production flow (i.e., no factory uses a project to build a car). A production line is not a project, it’s the thing you do instead of a project.
THE BAD:
Project Management generally faceplants in software development, where resource scheduling/sequencing is trivial. Software development is accomplished in the context of a stable capacity production system doing one thing in repetition, namely figuring out what features are needed and implementing them under a quality-control discipline. This is the exact opposite of a project, it’s a factory.
Software development follows this universal ‘factory flow’ sequence:
Figure 2:
Universal sequential flow of software development
NOTE: It is common for Agile (capital ‘A’) consultants to recommend skipping or redefining important elements at the head of this sequence, replacing them with magic. Do so at your own peril.
The stages concealing the most risk to budget and schedule are Principal Development and Final Development. These steps are not reducible on a project plan without itemizing features. Internally, they run a feature discovery and feature execution loop of unknowable duration. The loop can be managed, but it cannot be planned, a distinction with a difference.
Non-reductionism of this type is incompatible with Project Management. Undeterred, project managers have historically reduced these stages anyway. They start by generating poorly informed feature matrices, adding dependencies, constructing timelines, developing resource plans, and then managing ‘earned value’ by measuring time expended rather than monetizable completeness. Instead of building a plan around the division of labor (which works) they build a plan around features (which never works). Such plans always, and I mean always, fail.
Product Management Unpacked
Product Management exists in a separate universe from Project Management. It is neither a competitor nor a substitute. One does not reject Project Management to embrace Product Management (that’s the role Production Management plays).
A product manager is responsible for the overall end-to-end success of a product in the marketplace. The degree of success is estimated using various formulas where inputs are {time, money, property, people, reputation} and outputs are {margin, volume, differentiation, satisfaction, sustainability, reputation}.
Product Management consists of these four elements:
Figure 3 Elements of Product Management, paraphrasing Rob Wallace (Wallace-Church)
The important takeaway is that Product Management stays out of the minutia of sequencing timelines, dependencies, schedules, and milestones. Product Management is focused on the highest level, the challenge of creating something that is useful, attractive, and novel.
Product Management is a creative discipline, integrating deep consumer knowledge with the ability to conceive something new that will appeal to a target audience while preserving gross margins. Product Design is a direct spin-out of Product Management.
Product Management is not fundamentally incompatible with Project Management, but someone must be in charge. When project management calls the shots and product management is relegated to a humble staff position, the product outcome is compromised or totally failed. However, when a product manager is calling the shots and project management becomes a subordinative administrative role (i.e., project scheduler) then the chances of success are much improved.
Production Management Unpacked
Production Management is the least practiced topic in software. It does exactly what it says, manages production. Production consists of stations, processes, flows, inputs, constraints, faults, tools, and time. Time is the big one, by the way.
Every factory has a production flow, not a project. This is a key distinction. For example, one cannot manage automobile production using a project plan or Gantt chart. The same goes for software, but most orgs fail to see this.
Some terms:
In every system of production, the most important thing a manager can do is stabilize flow. In fact, the main challenge is to stabilize flow, everything else is gravy.
In a plant’s initial state, flow will be unstable. The rate of output varies day-to-day and week-to-week. Instead of producing a steady 15 units per week, production might swing wildly from 2 to 50. Depending on where the kinks are in the production sequence, some processes idle while others get overstressed, creating non-uniformity in the overall rate of production.
A good production manager will identify such kinks and straighten them out. The goal is to normalize productivity. It’s not about winning the race; it’s about achieving a steady pace.
In software development, the unit of production is a feature or product capability. These vary in size and complexity, so it might seem that a uniform Flow Time (the time it takes a single feature to get through development) is rarely achievable. However, this is only true when comparing single instances. In aggregate, these variances form a stable mean, in accordance with the Concentration Phenomenon (a random variable that depends on many variables, but not too many, it is essentially constant). Production flow can therefore be regularized around a sustainable mean with a reasonable standard deviation. This is accomplished by adjusting the production system to reduce process idle time caused by upstream supply disruptions. The remedies are numerous, including queue management, process parallelization, process simplification, cycle-time stabilization, work in process sizing, kanban signaling, etc.
The takeaway is that it takes a LOT of expertise in production system engineering to establish a stable capacity production system. This is true whether the items are cars or custom software applications.
Project Managers are rarely trained to do this and most lack the skills. If a project manager were placed in charge of a car factory, nobody would be shocked at the inevitable disaster. Yet, organizations place project managers at the head software teams every day, and then seem genuinely surprised by the disappointing outcomes.
To competitively differentiate in software development, start by treating software production like every other production environment. Software is not a construction project with come-and-go resources that must be scheduled. Software is produced in stable capacity environments with persistent stations and a continuous flow of work items.
Treat it as such and enjoy better results.
FINAL NOTE: Project Manager vs. Project Scheduler
One happy trend I’ve started to notice in forward-leaning tech firms is they are using Project Schedulers instead of Project Managers. These organizations are totally wiping out their internal Project Management Office (PMO), cutting the strings of power and influence that radiate from the typical PMO. It’s not that these orgs exist without project management, but they reduce it to what it always should have been – a relatively mid-level administrative support role. They call the role Project Scheduler. I think it’s genius.
Thanks for staying to the end, I hope it was interesting.
