Ceci n'est pas une project. pic.twitter.com/h5SUM5tC9o
— Jason Miller (@Lexwerks) September 4, 2017
I’m taking a class on project management for grad school. Our textbook is Project Management: The Managerial Process (7th edition, Larson & Gray, 2018) and while it is structurally laid out in a sensible-looking fashion, its actual content includes surprising claims like:
“one could eliminate the risk of choosing the wrong software by developing web applications using both ASAP.NET [sic] and PHP” (p. 217)
“The easiest way to add more labor to a project is not to add more people, but to schedule overtime… If people involved are salaried workers, there may be no real additional cost for the extra work… Sustained overtime work by salaried employees may incur intangible costs such as divorce, burnout, and turnover. The latter is a key organizational concern when there is a shortage of workers.” (p. 310)
In teaching professional practices, the first claim is wrong because instead of eliminating the risk, they’ve doubled it by spreading functionality across multiple technologies, either/any of which could fail (though neither PHP nor ASP.NET are even remotely likely to). More distressing: the process of interfacing those two competitive frameworks adds complexity and thus risk to the implementation the PM is trying to manage, and maintaining both of them after delivery requires somebody with a larger (read: more expensive) set of skills in a sustaining position. And that’s all before we even note how the major faux pas of calling “ASP.NET” “ASAP.NET” diminishes the PM’s status with the implementation team and makes them question why the PM is trying to make such a granular implementation decision anyway in blatant ignorance of what the team’s actual skills are.
The correct way to choose a technology platform is to look at what your very expensive technical team is prepared to support and then standardize on whatever they’re best at. Technical architects may sometimes push to standardize on a platform your team is not good at on the expectation that the amazing-ness of the platform will make up for the part of the team learning curve where everybody sucks and is unproductive–and they may be visionary and right, but make no mistake: they are trying to make a bet that is bigger than your project. Failing to expand the adoption of a platform, even a “best-of-breed” platform, beyond a single implementation leaves you with a one-off that requires unique (read: expensive) skills to support. It is a common antipattern to toss together a bunch of “best-of-breed” platform solutions and then be surprised when all your implementation team delivers are mutts. This may seem blatantly obvious but big companies with sprawling IT departments and a penchant for skunkworks routinely hire consultants like Gartner to remind them of it and MBA-level textbooks are still getting it wrong.
The real horror-show comes when Larson and Gray suggest scheduling overtime because that’s not even a thing. Sometimes the optimal time to do work is at unconventional times, and that changes when the scheduled work happens. Sometimes workers will put in overtime because critical tasks took more effort than expected, but that doesn’t go on the schedule. But when the salaried individual contributors work the scheduled hours and the PM then demands more of them, that’s not “scheduling overtime,” that’s “cheating the workers” and the paltry lip-service paid to “Ethics and Project Management” (p. 356) doesn’t even acknowledge it. Whether the motivation for cheating the workers is simply the PM not wanting to admit that they fucked up the schedule and so pushes the consequences of their incompetence off on their implementation team or a more active sadistic abuse of power, the notion that ethical behavior requires treating people equally (that is: as autonomous free moral agents) regardless of their social status doesn’t come up.
And why should it? The authors of this $200 book don’t consider the state of the workers–as they go through divorces, burn out, and leave the company on acrimonious terms–to be costs that the project should consider: they teach their students that those are “intangibles.” Except they’re very tangible to the real people who are expected to do the work, and those people will have tangible impacts to the project and to the company, and to suggest otherwise is not just shockingly inhumane but dangerously ignorant. In two quick searches we come up with the following information on tangible costs:
Divorce undoubtedly reduces a worker’s productivity. According to John Curtis of Integrated Organizational Development in Waynesville, N.C., the cost per worker going through a divorce is about $8,300, assuming an average wage of $19.50 per hour and a 50 percent to 75 percent drop in productivity. That estimate also includes days missed as the worker takes time off to deal with the legal, financial and psychological issues related to divorce. (Moskovitch, 2012)
Slightly more conservatively, Josh Bersin of Deloitte believes the cost of losing an employee can range from tens of thousands of dollars to 1.5–2.0x the employee’s annual salary. These costs include hiring, onboarding, training, ramp time to peak productivity, the loss of engagement from others due to high turnover, higher business error rates, and general culture impacts. (Altman, 2017)
Now, to be fair, divorces are going to happen anyway. Team members wandering off is going to happen anyway. But to willfully elevate the risks of these impacts that are not only expensive to the business but personally devastating to the individual employee by pretending that they are “intangible” so there’s no definite down-side to trying to cheat salaried employees out of their time spent on earth: that’s unethical. And to teach students that it’s okay to do is, in the Judeo-Christian tradition, evil (Luke 17:2).
But let’s pretend that you, as a project manager, have no ethical qualms about sending your team off on a death march. Even without refering back to Yourden’s book, aptly titled Death March (2003), I can tell you that it is a bad professional practice because overtime fucks up your ability to estimate future tasks–so you don’t want any of it at all and you really don’t want to be scheduling it. See, the key to making better estimates over time is maintaining a sustainable pace as was discussed in the original Extreme Programming Explained literature (Beck, 1999) so the historical pace becomes reasonably predictive of the future pace. The problem with overtime is that it quickly dips into diminishing returns:
When you work heavy overtime (paid or unpaid), you’re not as productive on an hour-by-hour basis as you are when you are refreshed and motivated. As the value of each extra hour of work diminishes incrementally over time, the team will reach a point where they’ll actually be more productive by working fewer hours, not more. (Mochal, 2002)
Most programmers are going to tell you that not all working hours are created equal anyway and that the valuable hours for working on deliverables are when they’re “in the zone” and the useless hours are when IT is virus-scanning, patching, backing up, and generally making their computer totally fucking unusable. Scheduling overtime is unlikely to give you more of the valuable hours, it just gives the virus scanner more opportunities to run. There is a sizable body of literature on the squishy human practice of increasing the value of time your information workers put in, from DeMarco and Listers’s Peopleware (2013) to Lopp’s Managing Humans (2016), and they tend to lean heavily on keeping–as telegraphed in by Mochal–your team “refreshed and motivated,” a point we’ll come back to in a moment.
But there’s a secondary effect to needing workers to put in overtime to hit deadlines, and that is that it quickly goes from heroic sacrifice to normal practice:
— Nati Cohen (@nocoot) September 1, 2017
So if you’re a professional engaging in professional practices, then your goal should be coming up with plans that are likely to work. If you’re not doing that, then you’re not good at your job because your job–your one job–is to successfully and reliably prophesy the future: “my team will deliver this glorious project that will fulfill that functional goal on a particular blessed date for a generous donation of some figure.” See? Prophecy.
A word on competitiveness in bidding from a construction worker I knew when I was younger: he was asked by a potential customer why his bid for a project was higher than the competition’s, to which he replied, “Well sir, I am familiar with our competitor’s work and I can assure you that you can pay our higher price and we will do the work right, or you can pay their lower price and then also have to pay our higher price for us to come in and do the work right.” He was never unemployed because he understood that his job was to prophesy, not to put out lowball bids.
So reframing “white collar office drone” to “apostle of the Invisible Hand specializing in prophecy” sounds cool, but the work of a professional prophet is precarious: as Dave Prior explains in Harned’s Project Management for Humans: Helping People Get Things Done (2017), the job is basically being responsible for things you don’t control and taking the blame for things that aren’t your fault. This is a major disincentive for me; I prefer to be as Athena was in The Odyssey: “She spoke in prayer, but was herself bringing it all to completion.” But the professional project manager prognosticates, running the same risks as the armies in The Iliad: they may ask for work to be done, and their request may be ignored. Or, as the World Economic Forum put it, “A growing number of people think their job is useless” (Bregman, 2017). To quote at length:
In a 2013 survey of 12,000 professionals by the Harvard Business Review, half said they felt their job had no “meaning and significance,” and an equal number were unable to relate to their company’s mission, while another poll among 230,000 employees in 142 countries showed that only 13% of workers actually like their job. A recent poll among Brits revealed that as many as 37% think they have a job that is utterly useless. … They have, what anthropologist David Graeber refers to as, “bullshit jobs”… the growing armies of consultants, bankers, tax advisors, managers, and others who earn their money in strategic trans-sector peer-to-peer meetings to brainstorm the value-add on co-creation in the network society. Or something to that effect.
This isn’t new, but it is accelerating as increases in human productivity reduce the amount of labor that a human must exert to survive. Historically, Goethe splits the engaged life from the alienated life in Faust; Marx talks about the industrialized worker’s alienation from the productivity of their labor; the 20th century saw a shift away from agriculture and into auto-alienated labor because, as Foucault described in The Birth of Biopolitics (1979), economic liberalism requires that “individuals are constantly exposed to danger, or rather, they are conditioned to experience their situation, their life, their present, and their future as containing danger” resulting in ridiculous notions like “Social Darwinism” elevating competitiveness to being a virtue (Davies, 2014)–with help, I suspect, from Calvinism and its Scottish offspring saturating the culture of Adam Smith and David Hume. The basic neglect of social cohesion as described by Marcal’s Who Cooked Adam Smith’s Dinner?: A Story of Women and Economics and Hochschild’s The Commercialization of Intimate Life and expanded to the conceptual loss of common goods as debasing our collective ability to address ethical questions in MacIntyre’s Ethics in the Conflicts of Modernity: An Essay on Desire, Practical Reasoning, and Narrative. So that’s a whole lot of de-motivation and it doesn’t help you get your team on task.
What can help you get your team on-task is focusing on what they need to engage and perform. Generally speaking, people want three things out of their career: autonomy, mastery, and purpose (Pink, 2011). Autonomy is the gritty details of the work they’re doing, and another reason why it’s wrong for the ignorant PM to step in and say they should be using both ASAP.NET [sic] and PHP. Mastery is their ability to improve on the skills they are autonomously deploying that makes a project interesting, and is why we automate repetitive ergo boring tasks. And purpose is the part of the job that turns their working week into part of their personal narrative. Yes, the abstract form of the project is always going to wash out to “the worker has their labor exploited for profit” but what the team really wants from the project–from their career, really–is a good story they can tell at a dinner party about what they’ve contributed not just to the company but also to the world. There are two riding effects from this: First, if the project doesn’t make for a good story, then it’s probably not strategically valuable and will not substantially advance anybody’s careers, including your own, so you should look for a better project. Second, be sure remind your team of the impacts of their successes because they do, in fact, have egos and want to be able to talk about their successes to their friends and family. (Never ever do what my old organization did and prevent the project team from seeing any of the business metrics related to their work: that’s active alienation right there and I’m not going to be rejoining that team.)
Here’s a particularly beautiful thing about treating purpose as the story of the project’s strategic worth: it becomes very clear very quickly which project sponsors are visionary and which ones are just posturing for political stature. See, the visionary sponsors will want to share their strategic vision with you because they want you to validate it. They don’t have an implementation team at their beck-and-call, they don’t know what’s possible, they need you to figure out how to make it work for them. And if their vision changes over the course of the project, they’ll be eager to explain that, too: the strategic value that the project provides is what the sponsor is banking their career on so they desperately want to get the story right, a key factor that makes them relatively easy to work with.
But there’s one other key element and the bit where people are “conditioned to experience their situation… and their future as containing danger” (Foucault, 1979) kind of telegraphed it in: people tend to want an iota of security and that’s why they’re on your project team instead of out freelancing. There is an increasingly anachronous expectation among people that loyalty is a virtue to rewarded rather than disregarded or betrayed by an organization, but it carries weight: “the biggest finding was that the number-one indicator of a successful team wasn’t tenure, seniority or salary levels, but psychological safety” (Looney, 2017). Now there are always going to be limits to how much safety you can extend to your team, especially in a toxic rank-and-yank environment where no matter how successful a finely-tuned high-performance team is, somebody is designated as a failure. But Looney’s two final points are always valuable practices: “Make your communication clear, and your expectations explicit” and “Make it obvious when your team is doing well.” If you think there’s a crossover from having a purpose here, there is: having a story about your project’s strategic positioning makes it harder to kill off when it’s meeting otherwise-arbitrary expectations and thus safer for your team to work on.
And this is where we get into the real project management, by which we mean risk management because “Risk management is project management for adults” (DeMarco & Lister, 2003). What DeMarco and Lister advocate for is an iterative form of project management that starts on the highest value portion of the critical-path functionality and radiates outward until the project is complete or until the diminishing returns from working on low-value functionality cause executive management to declare victory and move your team onto something better. As far as books of professional practices go, I strongly endorse Waltzing With Bears. By way of comparison, Larson and Gray advocate for a free-wheeling brainstorming of risks (p. 210) before turning around and admitting that in practice “over half of contingencies that occurred were not anticipated” (p. 226) with no mention of how many anticipated contingencies didn’t occur because brainstorming risks and guessing at probabilities is more of an astrology than a strategy. This isn’t to say that you shouldn’t identify and prepare for possible contingencies, but even an eerily accurate horoscope won’t provide you with adequate strategic guidance for your life. So: do identify and defend against risks as much as seems helpful, but–more importantly–strategically structure your project to prevent contingencies from emerging in the first place.
Now you may be thinking to yourself that this is silly: you’re in a highly matrixed organization and your job is just to crank out Gantt charts and call status meetings all day long so all the squishy human factors stuff doesn’t apply to you. Except it does. See, the dirty secret of a matrixed organization is that People Managers Are Useless. If you doubt this, just ask to see their training materials–ours didn’t even have required training for the past decade. But really, they’re useless because they don’t see the project work the workers are doing for the Project Managers and thus can’t reasonably evaluate their employees which is theoretically their most-important job. But that’s only half of the managerial failure story, the other half is this: 55% of IT projects are failing (Florentine, 2016). They don’t mention which Gantt-generators have a heightened correspondence with project failure; I would guess there’s no clear effect. But isn’t it nice to know that you can have most of your matrixed project management portfolio fail and you’ll still be more successful than average?
The problem is that a Project Manager who has more time to spend on treating their people like humans, who is more in-tune with the purpose of their project(s), who can reassure their workers that their labor is being exploited for profit so it would be idiotic to fire them, will also be able to tell the workers’ People Managers what a great job their folks are doing on the projects that really matter to the future of the company. And that’s good for the worker and that’s good for the People Manager and that means that those projects are going to get all of the valuable hours the workers have to give and your projects are going to get left with the scraps and have a higher-than-average failure rate.
You may have been prepared to usually fail, but are you prepared to only get an occasional and seemingly-accidental success? Do you really think you can build a career like that?
So that’s the big secret: the most successful project managers are going to be the ones that put effort into caring about their team so that the team focuses on delivering for that manager’s project(s) first, and this is even more true in a (stupidly) matrixed organization where multiple managers are competing for quality time from the talent pool.
Project work is people work, so project management necessarily includes a lot of people management.
For additional reading, I recommend:
- Project Management for Humans: Helping People Get Things Done (Harned, 2017)
- Waltzing with Bears: Managing Risk on Software Projects (DeMarco & Lister, 2003)
- Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, 3rd Edition (Lopp, 2016)