Every profession has an origin story it tells itself, and most of them get sanded down over time into something cleaner and more impressive than what actually happened. Project management’s origin story is unusually humble, which is exactly why it’s worth telling straight.
In October 1969, a small group of people who did this kind of work for a living got together for dinner at a restaurant in Philadelphia. There was no grand founding vision, no manifesto about standardising a global discipline. There were people named James Snyder, Gordon Davis, Eric Jenett, Ned Engman and Susan Gallagher, who ran projects for a living and had noticed something: they didn’t have anywhere to compare notes with each other. A few weeks later, at the Georgia Institute of Technology, that dinner conversation turned into what became the Project Management Institute.
The stated purpose, in PMI’s own words, was to give project managers “a means to associate, share information and discuss common problems.” Read it again slowly. Not a means to standardise reporting formats. Not a certification pathway. A place to talk about problems and how people were solving them. That’s the entire founding thesis of the profession you’re in. It was built by people who wanted to get better at solving hard problems, together, because doing it alone was hard and lonely and nobody else understood the job.
I find something almost moving about how modest that founding purpose was, compared to what the profession eventually became. There’s no mention of governance frameworks in it. No mention of a thirteen-tab status template. Just a room full of people who ran hard things for a living, wanting somewhere to say “here’s what went wrong on my last one, has this happened to you.”
What happened between that dinner and now is not a mystery, exactly. It’s what happens to almost every discipline that scales. A profession built around shared problem-solving needs some way to teach itself to new members, and the fastest way to teach a discipline at scale is to codify it. Codification is genuinely useful. It’s also, almost by definition, a process of taking something that was fluid and personal and turning it into something that can be tested, certified and audited. Somewhere in that process, the codified version starts to feel like the point, rather than the memory of what it was standing in for.
I’ve sat in rooms with project managers holding every credential the profession offers, who could recite a knowledge area faster than they could tell you the last time they walked into a stalled project and got it moving through sheer force of relationship and judgement. That’s not their fault. It’s what the system trained them to optimise for. You get good at what gets measured, and for a long time now, what’s gotten measured hasn’t been “did you solve the problem.” It’s been “did you follow the process for documenting that you were trying to.”
I don’t think the answer is nostalgia for a dinner in 1969. I think the answer is remembering what the dinner was actually for. A group of practitioners who wanted somewhere to talk about the problems they were solving, because the solving was the hard and valuable part, and everything that came after was supposed to be in service of getting better at that, not a replacement for it.
Every framework this profession has built since started as an attempt to help people solve harder problems more reliably. Worth asking of every one you use: is it still doing that job? Or has it quietly become the job itself, standing in the place where problem-solving used to be?
References
Project Management Institute, official founding history, 9 October 1969, Georgia Institute of Technology.
Leave a Reply