A reflection on software projects

  1. I'm currently attending a class in project management, and many of the topics being discussed makes me reflect my own experiences from working in the software industry. I'd like to share my thoughts so far.

    Previously, my view on software projects and finding solutions have been guided by a somewhat limited knowledge from my school days. What we were presented with was the debate of whether to apply the classical waterfall model or newer iterative (agile) ones. We were also taught how important use cases were. All this knowledge was very useful, and in many ways I felt that my more seasoned colleagues didn't quite understand the importance of it. Even so, I realize now that I lacked a greater understanding of how these models and methods really fit into a greater picture and why what I had learned seemed to work so well.

    My lecturer, Åge Garnes, has during his long history of work and study in the field, developed a slightly different approach to project management than his peers. Firstly, he introduces a new term: "trancendental dialogi"; a theory that highlights humans' continual interaction with its environments and the transcension effect of doing so. It's a predicament both deterring and uplifting at the same time. However we like it, we must all come to accept that what has been will never be again. The bright side is that we, as humans, will always learn and thus improve ourselves (as a general rule). What implications does this have on our work process? The very moment something is done, the actors are affected, and this in turn will affect their next action. While working in the software industry I recognize this particularly in how a group of people develop a practice and how the customer always seem to change their mind about what they want.

    Further, Garnes choose to view project design through what kind of uncertainty is present. He classifies projects into four basic types of projects given whether the stakeholders agree or not, and whether the solution is known or not. The reason he does this, is because he thinks the different types each introduce very different challenges, and choosing the wrong design will most likely result in an unsuccessful project. He explains that many project managers tend to choose the same methods for every project because they have positive experiences with that, or just to save time, and when they meet a new situation it ends in disaster. I have myself witnessed this one-glove-fits-all way of thinking, not just in choice of method, but also in choice of technology. I have also witnessed project managers take on software projects without any experience in that field. Needless to say, high risk and little innovation is ensured this way. It has been a source of much frustration for me.

    """Solutions known""Solutions unknown"
    "Stakeholders disagree""Political project""Chaos project"
    "Stakeholders agree""Classical project""Development project"

    Most projects tend to grow out of the Chaos category, where no one agrees and the solution is unknown. In its extreme form it's the very opposite of what a project is. It is a hopeless situation with infinite risk. Quite often the situation tends more to the political type, where there's a sort of ever-lasting struggle of opinion. What we will need to do is push the project as far down into classical and development categories as we can, so as to reduce the risk. There are ways to do this, but that doesn't mean we can forget where we came from. If we do, we might end up in a situation where we drift back, and ultimately the project fails.

    When we have achieved a certain level of agreement, the approach to project design is the question of whether the solution is known or not. This is a crucial point that decides how we should proceed. The classical project is a situation where the solution is known. That means we can specify the goal and thus thoroughly plan the project. The success criteria is how well we optimize. A focus on this highly reduces the risk. On the other hand, a development project is a trial-and-error approach that has a relatively high risk until a breakthrough situation occurs. This cannot be planned, but achieved through a creative process. It's in the intersection of these two project types the waterfall-or-iterative approach discussion comes in.

    Having worked as a consultant in various software projects, I've seen several times how the customer thinks they are unified and that they know the solution to their own problem. Typically, at least for larger projects, the customers write a sort of specification for the solution they want someone to make. Then there's a process of suppliers bidding on the project. This is a valid approach if the solution is properly specified. The reality is, however, that the customer almost always don't know what they want. Typically, they have ignored a lot of the important work involved in making a specification. Firstly, their expertise in choosing a technology is severely lacking and secondly, they have not involved the end users of the solution. If this is the case, it's a really bad idea to go with a strongly classical type of project! The use of the waterfall model will likely end in disaster. Since this is very often the case, it's no small wonder that the iterative approach has become so popular over the years. However, many projects still fail because of poor project design decisions like this. This is why consultants are so valuable, if they give the proper advice like they should.

    So, what's the lesson? We should always be concious of the challenges at hand and choose a method accordingly.