Processes exist for a reason. I think we all know that. Nobody can acurately say that processes are bad. They can be taken too far, tho, which is why agile processes have grown so rapidly in the software development arena. Personally, I think a lot of that has to do with trying to get away without documentation, but that's a different issue. Honestly, agile processes don't have anything to do with the level of effort put into documentation. Anyway, all of that's besides the point. I read a post, If Not Agile, Then What , by Rockford Lhotka a while back and I've been meaning to remark on it. Over the years, I've put a lot into defining and working to better development processes. This came from being in a process-heavy organization. At the same time, I've always appreciated the fact that the processes in place were more than I thought necessary. There are certain architecturally significant steps I believe are important for any development project, but the level at which they should be achieved can vary a great deal.
Rockford talks about how nobody follows any process 100% and no process was built to be 100% followed. Well, those aren't his words, but it's the basic jist of it. One thing I've always wanted to do was create something like a step-by-step process for defining your own development process. Basically, you'd input your criteria and out would pop a suggested process, documented from front to back. You could, of course, pick and choose what you actually used; but the core concept is that the practices -- along with their pros and cons -- would be given to you so you can make an informed decision. That's one thing you have to be able to do as a consultant: allow your customers to make thier own decisions. If you want to bury yourself, I'll hand you the shovel; but not before telling you what I believe could happen, what to look out for, and what your options are going to be if my foresights have come to pass. Defining and following a development process is a weak point in most organizations. Sure, people might deliver, but is there enough documentation? Beyond that, how much is enough? There's no single answer for these questions and the thousand others that would typically follow. This, of course, is why I've always wanted to formulate the process generator I mentioned. I don't know if I ever will, but it will always be in the back of my mind.
If you're interested in software engineering processes, I suggest you give Rockford's post a read. I'm always interested in people's opinions regarding engineering processes because it helps me take in different viewpoints and better understand the necessary flexibility for any process to survive across multiple projects, which is almost a must-have for a development organization. The more processes in one organization, the more wasted time and money that goes into managing these processes. I don't think most developers realize the importance of a well-defined process because they haven't been exposed to larger system development teams and organizations where project scheduling and documentation isn't something that can be debated without risking project success.