Process and Language
Software Development: I've long thought that most project management strategies thwart the purpose they are designed to serve. I've lived through a CMMI (Capability Maturity Model Integration) at a previous company. The extra process overhead literally doubled the development time, and on the day we junked the CMMI we'd achieved at least a Level -2 on the Capability Immaturity Scale. We moved on to the RUP. When the change management system became so elaborate that developers bled from the eyeballs, we moved to Extreme Programming.
I left them. I took a dream job at a company with a loose and free-flowing process where the style and content of "deliverables" was sort of ad-hoc and personality-based. Having a bad process wasn't great, but having *no* process was worse. Later I worked at a university where we used MIT's Discovery process for requirements-gathering. As a framework, I thought Discovery wasn't half bad, though the Alphas in the organization tended to over-focus on the process for political gain. About halfway through one of our first Discovery projects, MIT declared that the process didn't work and they were abandoning it. The politicos in my organization immediately stopped name-dropping the letters MIT in every Discovery presentation. It was funny. I wonder if they've abandoned the whole thing yet.
An oversimplified view of the problem with all of these processes is that they impose an elaborate special language to describe the details of each stage through the thing, most of it encrypted in acronyms. Project managers like to throw acronyms around (they have this in common with the U.S. Government, especially the military). I think it makes them feel like they are doing something more "technical" -- a phenomenon I've seen described as "the professionalization of being human" (see also the weedy growth of dense new terminology in the social sciences and education). Problem is, everyone in the organization has to learn and adapt to this new forest of acronyms to navigate the process successfully -- all of this *on top* of the specialized languages you have to learn and use to do your actual job. If you don't use and respond to the acronyms, you can be seen as an obstructor. (The nice thing about the Discovery process was that it went easy on the acronyms. Sort of.)
Things get really bad when a new process becomes popular and the project managers switch to a whole new set of acronyms. Usually this is the same series of concepts, slightly tweaked and resequenced, with the letters rearranged. It's fair for the producers of the product to question the need for this ever-changing layer of overhead. If the last process wasn't working, what makes you think this new one will?
Automated processes and homegrown processes are a different story -- but that's for another day.
I left them. I took a dream job at a company with a loose and free-flowing process where the style and content of "deliverables" was sort of ad-hoc and personality-based. Having a bad process wasn't great, but having *no* process was worse. Later I worked at a university where we used MIT's Discovery process for requirements-gathering. As a framework, I thought Discovery wasn't half bad, though the Alphas in the organization tended to over-focus on the process for political gain. About halfway through one of our first Discovery projects, MIT declared that the process didn't work and they were abandoning it. The politicos in my organization immediately stopped name-dropping the letters MIT in every Discovery presentation. It was funny. I wonder if they've abandoned the whole thing yet.
An oversimplified view of the problem with all of these processes is that they impose an elaborate special language to describe the details of each stage through the thing, most of it encrypted in acronyms. Project managers like to throw acronyms around (they have this in common with the U.S. Government, especially the military). I think it makes them feel like they are doing something more "technical" -- a phenomenon I've seen described as "the professionalization of being human" (see also the weedy growth of dense new terminology in the social sciences and education). Problem is, everyone in the organization has to learn and adapt to this new forest of acronyms to navigate the process successfully -- all of this *on top* of the specialized languages you have to learn and use to do your actual job. If you don't use and respond to the acronyms, you can be seen as an obstructor. (The nice thing about the Discovery process was that it went easy on the acronyms. Sort of.)
Things get really bad when a new process becomes popular and the project managers switch to a whole new set of acronyms. Usually this is the same series of concepts, slightly tweaked and resequenced, with the letters rearranged. It's fair for the producers of the product to question the need for this ever-changing layer of overhead. If the last process wasn't working, what makes you think this new one will?
Automated processes and homegrown processes are a different story -- but that's for another day.