Project Methodology in 2020 (Part I)
Here we are in 2020, and in the world of projects, one thing we know is everyone wants to be Agile. Some organizations are even guilty of the excessive and even just plain vacuous use of the term, as if it is a religion, as in: “you are not Agile.” In these firms, you could take this phrase and substitute the word “Agile” with “a true Christian,” and I suppose you’d have a religion.
Beyond this faddish phenomenon, is a true business problem that many organizations, and even experienced project managers, are trying to address: traditional project management methodologies are too cumbersome to get much work done efficiently or effectively. The challenge for most organizations is how to switch things up so that project delivery can be improved, and for that Agile methodologies seem to be the wondrous hammer that makes everything seem like a nail. It is just, unfortunately, not all that simple, and saying the words “Agile. Agile. We are Agile,” does not magically transform what we you are actually doing.
Given all of this, I’ve decided to begin this three part series on Project Methodology. This Post is Part I.
Project Methodologies — How it all began
In the early 1990’s, after decades of stumbling progress in improving project management methodologies — specifically brought to light by the difficulties experienced on large software projects — some of the early software engineering methodology pioneers began a conference series to discuss where Project Life Cycles and their related project management methodologies were headed.
I remember entering this scene around 1992, just in time for The Second Annual Conference on Software Methods . I believe the conference took place in the spring of 1992, but I do not have an exact date since this was before much event archival information was stored on the internet.
The conference took its specific name from the recognition, at that time, that the overly structured, and seemingly more and more rigid, big Project Methodologies (definitely with a capital M) were not helping our information technology practices with timely and quality project delivery. So the idea was that one could build a “toolbox of methods” (little m), as Tim Lister put it, to address Software Development projects.
The conference — packed with actual software industry thought leaders, not just software tool vendors — was unexpectedly interesting and thoughtful, especially for a meandering kid in his mid-twenties, which is what I was at that time. It mostly pointed to how far we still had to go to get software engineering project practices up to the caliber of other engineering project practices (more on that and John Zachman’s framework, below).
Perhaps the most memorable part of the whole conference occurred on the first day when Microsoft presented their “methodology.” I wish I still had their PowerPoint deck on the topic. I kept it for many years (in those days, conference organizers often produced hard-copy binders with copies of all presentations for all attendees), but I seem to have finally recycled it. This methodology consisted of the following components: (1) “hire smart people” and (2) test the living crap out of whatever you produce until there are “no known crashing bugs.” Translating this a bit, this means that Excel didn’t have to work as specified, but as long as it wasn’t crashing, the system was ready to ship without hesitation. The “specification” Microsoft had in their methodology was a Microsoft Word narrative document that the “program manager” was responsible for writing. This “spec” would be reviewed with the team and also there would be occasional “Bill G Meetings” (referring to Bill Gates), but the team hoped to minimize these because “Bill G” would scream at people with comments like “that is the stupidest (expletive deleted) thing I’ve ever heard.” Basically these reviews, in which they would debate the narrative “spec,” were their entire methodology.
This is really what Microsoft — in 1992, by far, the most dominant computing vendor in the world — presented to us at the Second Annual Conference on Software Methods.
At lunch that day, Tim Lister referred to Microsoft’s methodology as the “Fahrenheit 451 Methodology,” referring to Ray Bradbury’s popular science fiction novel of that same name. In Bradbury’s novel, books were being burned, and so an effort was begun for citizens to tell each other the stories contained in these books in order to (in a sense) preserve the books. In Lister’s view, Microsoft’s methodology was no more effective than this desperate, dystopian effort right out of a science fiction novel.
And then there was The Zachman Framework: essentially a meta-model (model of models; or model that guided modeling). For me this was the breakthrough of the whole conference. It wasn’t because of what the framework was, but more because of what the use of it uncovered: in John Zachman’s seminal talk (you could also call it a sermon) at the conference, he described how so many other industries addressed engineering and engineering projects in an effective way, but certain types of projects, especially software projects, seemed to really be several steps behind, from a maturity point of view. The Zachman Framework was able to clearly and simply articulate the fundamental problem of the way certain types of projects (again, especially software projects) were approached. The lack of architectural clarity (as Zachman might put it) in how these projects were approached resulted in poor methodological structures and decisions.
So this is how it all began. And this is how — in the mid-1990’s — we realized we had a long way to go in terms of the interplay of how project management methods and software engineering methods connected.
Why not RUP?
Several years later (the early 2000’s), there was a lot of excitement about Rational Unified Process (RUP), which was viewed by many veteran information technology project managers and architects as truly different, in a good way. It seemed comprehensive and yet scalable to the type of project endeavor. There was even some initial thinking that the RUP “framework” could tackle any engineering project, not just the software engineering projects where it had its roots.
Over time, it became clear that RUP, as an overall framework, made a lot of sense, especially when organizations needed to deliver on mission critical or higher risk projects, but it was also an unwieldy and overly prescriptive process.
In the end, RUP really wasn’t able to make a real difference for most organizations, and broad support for it died under its own prescriptive — and documentation obsessed — weight.
So what about Agile?
There is a lot to be said about Agile, which we will cover more extensively in Part II of this series (Speaking of Agile). A few years ago, there was a point where an extreme frustration with heavyweight project methodologies, which felt cumbersome and ineffective, fueled a quest by many organizations to find a better way to deliver projects. Agile emerged as a potential way out of this mess, and for some software developers, it also provided an excuse to do anything you wanted (I am still wondering why there hasn’t been an actual Cowboy Programming Method listed as one of the actual Agile methods, but I suppose early versions of Extreme Programming — a specific Agile methodology — were the next best thing).
As with RUP, there has been an attempt to roll-out Agile principles for business and other engineering projects beyond software (see Harvard Business Review’s article on Embracing Agile, for example). What is less clear when organizations adopt Agile project methods is whether there are rigorous practices and standards actually put in place: Agile began as a “manifesto” of principles, and its founders seemed fairly reluctant to put in place more tangible standards, although there are certainly guidelines for each Agile methodology. This makes it fairly challenging to implement a robust, Agile-based project methodology for every type of project in a given organization.
And so the quest for the right enterprise, scalable, and implementation-ready project methodology goes on….Stay tuned for Part II of this series: Speaking of Agile.
If you enjoyed this article, sign-up for the BlueNotes Newsletter to get similar thought leadership and information delivered directly to your email Inbox every other Monday.
