Customers Need to Know Process Models

I'm currently taking a software engineering course which covers many aspects of software project management. The class is great because it covers a lot of knowledge that otherwise has to be won with hard earned experience. It's a curious phenomena that most technical managers are promoted to management positions because of their technical proficiency. Organizations take someone who is at the top of their technical game and suddenly switch them into a whole different role that they often times have to learn from scratch. Other professions do this as well, and it's always difficult. Just because someone displays technical proficiency doesn't necessarily mean they'll display managerial proficiency. Also, you take someone with years of experience and change their jobs into one which they have no experience in.

The course covers several strategies for managing, and guiding, successful software development projects. One of the earliest topics we touched on were software process models. These are the strategies that organizations use when approaching software development, things like Scrum or Extreme Programming. I've heard these topics bandied about before, but never given them a whole lot of thought. In the past I managed software projects based on past experience and my gut feeling. It turns out that there's a wealth of data driven studies that help quantify and formalize the approach to software development. These studies have been used as the basis for developing successful software process models, some of which have become quite well known. However, it is important to note that each process model has it's own unique advantages and disadvantages. Some models are better suited for certain situations than others.

As I learned more about these models it occurred to me that is not only useful to know and understand them as a manager on a development team, but it is also important to understand them if you are a consumer. Often time customers will be deluged by buzz word jargon when soliciting bids, and many RFP responses will include information about the development shop's desired process model. Understanding what these models are, what they mean to you as a customer, and what to expect out of them is hugely informative to your decision making process. If a vendor pitches a model that is wrong for your business style, or wrong for the project, it is important to identify that fact up front and address it.

Unfortunately, most people, even experienced programmers, are completely unfamiliar with the various software process models. One reason for this is their complexity. Another is the fact that there are so many. Yet another reason is that customers generally hire outside firms for development assuming that the firm understands these models and will choose the best one for the project. This last assumption can be dangerous, however. Development shops may choose a model that works best for them, but not for you as a customer. They might also choose a model that has worked well in the past on other projects, regardless of similarities between prior projects (and customers) and your own. This could produce a very bad fit, or even lead to project failure.

By way of example, one popular process model is extreme programming. This model is uses an iterative approach where customers get quick wins and early deliveries. It is very well suited for incremental development and getting feedback from customers early and often. However, this model does have some disadvantages that could potentially be disastrous. Extreme programming requires a lot of interaction with customers, without which it fails. Extreme programming also produces iterative code towards a goal with the understanding that requirements will evolve over time. With a clearly defined project that doesn't need any iterations this can be a wasted effort.

Another model is the waterfall model, which is a very old model. In a waterfall model the project is divided into stages, with the customer signing off on each stage. This model is great if you have a very clearly defined and understood product. It doesn't require as much client interaction and divides the project into easily measurable milestones. The waterfall method, however, is fairly inflexible. If the project needs to be redefined part way through the waterfall model doesn't have any good mechanism to adjust. Early commitments can lead to headaches down the line if the commitments turn out to be unnecessary or wrong.

As you can see, these two examples each have their own advantages and disadvantages. Each model will work well for different projects, and different communication styles. Picking the right model will help to smooth the project, and picking the wrong one will insure conflict, uncertainty, and development problems. Without understanding these two models they simply look like buzz words on paper. If a manager knows that he has a clearly defined project that doesn't need much redefinition or interaction with the development shop then choosing a proposal that is based on an extreme programming model might be problematic. Similarly, if a manager has a project that needs to evolve as it is developed to address shifting customer requirements then a waterfall model will not work very well. Having someone who understands these models can make all the difference when selecting a development shop for your project, but learning about these models is usually restricted to actual software engineers rather than customers. It is critical that customers educate themselves about these models before choosing a vendor to develop a project in order to assist in a positive outcome.