Introduction to Software Projects Part II: Complexity

Introduction to Software Projects Part II: Complexity

150 150 admin

In our previous post –the first of this series– we talked about the different types of software projects. The level of complexity basically differentiated them: they can be simple or complex. We also looked at a high level what made a software project complex.

In this post I want to expand a little bit on the topic of complexity. Let’s define in more depth what elements create complexity and how they will impact the overall execution of a project.

There are two fundamental elements that define the level of complexity: requirements and technology. Ralph Stacey in his 1996 book “Complexity and Creativity in Organizations” created a fantastic chart representing the level of complexity in terms of these two elements:

In the vertical axis he plots the requirements. This is very important because it is what the customer wants (it is not necessarily what he/she needs). The customer may or may not know all the details about the requirements. Also, some of the requirements may not be realistic or simply put they can’t be done for whatever reason, only he/she doesn’t know yet.
It is our job to flag those unrealistic requirements very early to set the expectations right from the beginning.

When defining requirements there can be many of them that the customer provides to implement a specific functionality, and there are others that we may bring to the project as a necessity to implement such functionality. In any case, the project will have a list of requirements, which will be agreed upon. This level of agreement is what will drive the level of complexity to grow or shrink. Agreement of requirements means that the customer and CSW Solutions, together, know about what needs to be done. When there is no agreement, is because there is too much uncertainty about the requirements, and that increases the level of complexity. The uncertainty is caused by unknown factors in the requirements or there are requirements that are still unknown.

At the same time, in the horizontal axis we have technology. When the technology required for the project is known, the complexity level is low… but imagine the case where a technology that is needed for the project is totally new or is none-existent and needs to be built; then it is unknown if it will work or not, and that increases the complexity.

Now, how do we work at CSW Solutions?
First, we determine the level of complexity of the project at hand. We most likely won’t give you a complexity score as such, but it will be clear why a project is defined as simple or complex. We will work with our customers in simple and complex projects. Now, note in the complexity chart that there are two other types of projects we haven’t really talked about: complicated and anarchy (chaotic) projects.

A complicated project is the result of a high disagreement in requirements, but the technology to be used is well known. It can also be the result of a highly unknown technology to be used in a well-defined set of requirements. These complicated projects are normally treated as complex projects.

In anarchy/chaotic situations there is too much disagreement in the requirements, while the technology is, for the most part, unknown. These types of projects cannot be executed; there are too many unknown variables and that causes an extraordinary high risk for both the customer and CSW.
So what do we do in this cases? We break them down into smaller components to try to bring the whole project into the complex area, so that it can be managed and executed, one component at a time.

A simple project can be managed using many traditional software development life cycles methodologies. These are easy and normally can be executed with only having solid documentation on the requirements and technology. They may be short or long in time, but since everything is well known and already agreed upon, then it can be executed.

A complex project on the other hand needs to be treated differently. For these types of projects we rely on agile methodologies such as Scrum or Extreme Programming. These methodologies allow us handle the uncertainty by executing the project in small incremental steps. Doing so also allows, both the customer and us, to re-evaluate the requirements and technology without spending too much time and budget. As a consequence, change can also be handled gracefully because only small portions of the whole project are implemented at a time, so any change in the requirements or technology can be included and managed in the following steps.

In the next post we will go deeper into the managing complex projects using our favorite agile methodology, Scrum. Stay tuned.