These small lists of Software Development Processes are the processes I am referring to in this blog.Agile- Small teams / small projects at the same locationXP Agile-Model Driven DevelopmentSCRUMEssential Unified Process (EssUP)Formal - High Ceremony Striving for Higher PredictabilityUnified Process (UP)Rational Unified Process (RUP)Enterprise Unified Process (EUP)Product Line Engineering (PLE)FrameworksMicrosoft Solutions FrameworkZachmanWhat makes people think a Software Development Process can be implemented in an organization at no upfront cost (including time and money)?
Of course the number one culprit is lack of experience. The inexperienced have no understanding of what is involved in process engineering, and they usually have the belief that process is a luxurious overhead that is only to be thought about when there is complete downtime or during hours above billable hours. This same lack of experience also usually leads to the perspective that implementing a process will add hours to a project, and therefore adds cost to every project in the organization that uses a process. If your software development process adds hours to every project you have, it is time to reengineer your process.
I have also run into a lot of people that believe that they have been involved with a successful process implementation. After spending some time talking about their experience, you find that they built some reusable components, made them available to a development team, and considered that process implementation.
Another scenario I have commonly seen is an organization putting a project manager in charge of the process engineering project management that has no process engineering experience. They have worked with in a development process very successful, and they believe that is process engineering experience. What they do not realize is that project management is one of many roles found in a development process, and when in that role you are project managing a development process from with in the process. Those skills obtained while doing that, are not the same skills you need to project manage a process engineering process. This scenario I like to call the blind leading the blind.
There is a lot for a person to learn about software development processes. Actually there is as much to learn about them as there is to learn about programming, architecture, and project management, which are all parts of a software development process. Process engineering has its own set of skills that is above and beyond being part of a software development process. That is one of the reasons Rational put together the Process Engineering Process (PEP)
and SEI put together the Software Engineering Process Management (SEPM) Program
Like a software development process there are different phases, iterations, roles, activities, and artifacts present in a process engineering process. It would stand to reason that a process that creates the environment that allows for the implementation of multiple processes that guide your development teams through the development lifecycle would require a little work to get put in place. There are a lot companies out there that do not understand this.
Also like a software development process there are different process goals found in different companies. Companies developing simple brochureware websites with static HTML pages will have a much different process than one that develops software for hospital equipment. That means the process engineering process will greatly differ when implementing for different types of development.
90% of the companies I am involved with develop rather complex web applications or smart client applications. The development cycles range from months to years. So the development process is usually one that supports instances of the RUP, UP, EssUP, or PLE. The range of development teams within a given organization have range from 5 to 25+ working on separate projects. I have been in organizations that do understand the process engineering process and have allowed for the proper time and allotted for the cost of implementing processes correctly. That has happened approximately 33% of the time.
Many times the ones that do not understand process at all are found in Never Neverland (The Process Ladder- UP, RUP, EUP, PLE, & Never Neverland
My worst experience is with the companies that continuously plan and talk about process improvement, and plan and talk about process improvement, and plan and talk about process improvement, and plan and talk about process improvement, and then they decide to plan and talk about process improvement.
Imagine if all we ever did was talk about and plan an application. No one did any development. We just had monthly meetings to talk about the application and how wonderful it will be when it is done.
These are the companies that think process will magically appear one day, and it will have cost them nothing. They have no understanding of process engineering, yet they don’t want to hire a process engineer because they don’t understand what one would do. Mainly because they don’t understand what process is, or how much work it takes to engineer one. Some of the companies are changing. It wasn’t too long ago that software architects were not understood, and therefore were not accepted as a necessity. Before the architect, the software project manager had the same problem (Where is my Project Manager
My craziest experience has been being assigned to improve the development process across a company of about 10 to 12 development teams, ranging from 1 developer to 7 or 8, working on moderate to highly complex applications. We talked about process improvement for months.
Finally I was told it was go time. They want to use the RUP and PLE where appropriate. I would be given a team of 5 to work with me. I was told we should meet for breakfast, lunch, or dinner every few weeks to do the process. We should be sure to do process work after we have billed our 40 hours for the week. Most of the team did 50 – 60 billable hours a week as it was, so I was sure they would love hearing about their newest assignment.
That was like telling me, we are giving you a team of 5 developers to develop a new system. It is going to impact all our other teams, making them more efficient, and it is going to save the company a lot of money over time. The system is much more complex than the systems you have architected for us to date, so this will be the most difficult project we have given you so far. We think this system should be done by you and your team over breakfast, lunch, or dinner every few weeks. We don’t want you to bill for this system.
Needless to say, process was not improved. Process Engineering takes an upfront investment of time and money. You cannot avoid paying for it initially. I guarantee that if you think you are getting by without paying for it, whatever you are doing that you consider a software development process is costing you much more time and money in the long run than it would to implement process correctly.
For the companies out there that are reading this, I would like to put in perspective where I place the skill set of software process engineering. Most companies understand cost. So let’s use that as the scale. Let us say you want me to be your developer, the price would = A. If you want me to be your lead developer, the price would be A x 1.5. Let us say you would want me to be your architect, the price would be A x 2. I wouldn’t be one, but if you wanted a good project manager, the price would be A x 2. Let us say you would want me to be your software process engineering, the price would be A x 2.5.
But those of you, who are not willing to change and still think process should magically appear for free, you need not lose heart. For $20.00 you may purchase a pair of slippers just like Dorothy wore. I suggest wearing them to each meeting you hold to plan and talk about process improvement. After each meeting you all close your eyes and click them together 3 times saying each time “We just want process for free”. Get your ruby slippers HERE