When you’re new to the corporate IT environment, chances are you are picking up a lot of buzzwords in use by the more senior personnel in the companies you are working for. You will hear phrases like “how’s the SCAMPI assessment going?” or “can I have an update on the CMDB’s progress?” or “have we made progress in institutionalizing PRINCE2?” or “shouldn’t we choose Kanban over Scrum and plug that in to the AUP we are developing in order to get rid of the Waterfall SDLC we used for the past 20 years?”. It can all get complex quickly and just knowing what your colleagues are saying can be quite the learning curve.
When you are not new to corporate IT, you might already know or have heard about most of the common methodologies in use today. And still, sometimes you get gobsmacked by just another one being thrown around by the colleagues you work with at that moment. They have different backgrounds and have met some of the other more exotic methods living in the wild.
Fact is that, together with the IT development technologies (what with Struts, Hibernate, Spring, EJB, WPF, Ajax…), the amount of IT management methodologies has increased nigh-exponentially as well. I decided to do a quick look-up of the latter ones, so that I could categorize them and find out their origins. And although the approach and method to this “research” is far from scientific and its findings arguable, it still makes for an interesting take on the subject.
As mentioned, I squarely focussed on IT management methodologies, so I have not included the development technologies or, so to say, the technical stuff of which some examples are given above.
Below is how these management methodologies appear to have grown over time, with every methodology from before the 80’ies, included in the same subset.
Note that all methodologies from before 1980 are combined and that the oldest two are from before the sixties. As far as I could trace a defined origin – and for these two specific ones I am fairly sure, they are Bell Laboratories’ Systems Engineering from 1946 and the trusty old Waterfall model Herbert D. Benington came up with in 1956. The graph clearly points out that methodologies knew a sharp increase in numbers only fairly recently; that is over the last 20 years, which is entirely logical, since that is the limited timespan where IT really became integrated into most businesses as well as into society itself. Over the course of these two decades IT stopped being an elitist endeavor for huge companies or a hobby for the select few early adopters. So, it seems logical then that only for 20 years, methodologies have boomed.
Which methodologies exactly though? What are they defining? Could I categorize them, so that I could show you the process area these methodologies define? The answer is both yes and no. It actually proved quite difficult to do so, since several methods are multi-facetted; they have components for project management, as well as for actual development. They focus on IT strategy, as well as support. Lots of methodologies are hybrids, combining one or more process areas in their respective guidelines. Most hybrids were between project management and development though, so that is what hybrid means in the chart below.
The area’s I have used are:
- Development: which is used to indicate methodologies with a clear application development focus like JAD, UP, Scrum or Agile.
- Hybrid: which is used to indicate a marriage between a development methodology with strong hints of a project management methodology.
- IT Management: which means methodologies focusing around IT process areas outside of development and project management. The methodologies here define a broad spectrum of process areas and include certification reference frameworks like the IT ISO standards. One of the more widely known and used names here is ITIL, which could be seen as the prime example of an IT Management methodology.
- Project Management: which of course is the group which holds PMBoK and PRINCE2 among other, lesser known PM methods.
- Others: which combine all the rest of the IT standards you could get in contact with and which define only one specific area of IT business operation: e.g. risk management or procurement or portfolio management.
Given the above arguable and self-chosen seperation, the result looks something like the below. Again: this is my initial assessment, and you could discuss about RUP being PM, Development or Hybrid for example, but, like before, even without a thorough discussion, the image below can easily be used to discover trends in these methodology metrics.
What do we see?
We notice that methodologies have had a strong – PM slash development – focus early on. All the way up to the 90’ies most standards were focused around the process area of delivering projects. From the 90’ies onward, there has been a shift towards IT management methods, and clearly towards development, but also, and increasingly towards niche process areas like portfolio, risk or schedule.
If you indulge me giving my interpretation, Systems Engineering, PMBoK and even PRINCE2 all had their origin before the 80’ies. I think that PM methodologies actually have been quite good to start with. The reason could be that project management actually existed for far longer than Bell’s 1946 manual about it. Project management in a way “always” existed and the approach to delivering projects – be they in IT, or in indeed Cathedrals or Aquaducts – has always known similar approaches of planning before doing. When Bell formalized the process, it was nothing more than writing down what was common sense.
The increase in development methods seems to increase with the increase in global IT use and that seems fairly logical.
Yet we also notice that the number of IT Management methodologies has risen sharply. This can be explained with the fact that IT use has risen, that more and eventually all companies have adopted IT of some sort and have increasingly felt the need to structure supply and demand of IT to business. But, I do need to make a footnote concerning the category, since it’s the category where I hesitated most and still do about some of the methodologies in there. Is OPM3 (Organizational Project Management Maturity Model) a PM method or an IT Management one? I have chosen for the latter, since it is a model with which to assess your PM capability, rather than a model drawing the boundaries for your PM’s to run in. Same goes for P3O (Portfolio, Program and Project Management). You cannot call this a PM model, nor a Program Management model. Since the combination of portfolio’s, programs and projects run deep and wide through a company, I called it an IT Management model instead of an “other” one.
So you can argue about some categories and the contents thereof, but there are some clear trends to spot as well even with the relatively raw data I propose now. I do tend to keep the charts up to date and will intermittently post updates to it whenever I find new methodologies – and that’s almost weekly. Of course, if you have questions or comments, do feel free…
By the way: the initial slides are available on slideshare – not the best slideshow out there, but it’ll have to do for now.