What I learned from writing a Master Project

Building the research question

When you are following the Executive Master in Enterprise IT Architecture (MEITA) at Antwerp Management School (AMS), you have to write a Master Project to get your degree. From the start I had a clear idea about the subject: I wanted to proof that Business and IT must work together if they want great software. In my experience it happens too much that IT makes software for Business based on vague requirements, while Business thinks that all time spent with IT is a waste of time. My research question, after lots of editing, resulted in: Can pair information modelling between Business and IT optimise business change? I invented the term Pair (information) modelling (based on the term pair programming) for this research: it means that someone from Business and someone from IT are looking at the same model, Business explaining their domain while IT models what Business is doing the explanation. At the same time, IT gives feedback to Business what he/she is changing to the model and why. I narrowed down the research to information modelling to make the experiment feasible for the time frame of a Master Project. Business represents the business stakeholders, while IT represents the modellers, in a software project (in the context of the Master project). I limited the term business change in the research question to business change related to software projects.

The literature study

At the start, I was doubting if my research question was relevant enough to dedicate a complete Master Project to it. Isn’t it obvious that cooperation between Business and IT gives better results? Why bother with a Master Project for which the conclusion is already clear from the start? I made abstraction of my doubts and headed into the literature study. My first lesson started with the description of the problem. Initially, I jumped right into the core. Obviously, the first feedback from my promotor stated that I took the assumption that the potential readers knew what I know about the subject, that they know how to interpret the terms that I mentioned in the right context. This is rarely the case. Readers have different backgrounds. And even so, I cannot assume that readers can easily deduce the context or which definition I had in mind for each term. So I slowed down a bit and started to set explicit definitions, draw meaningful schema’s, and clarify all terms I used in my problem statement. I used the steps that were drilled into me during my Master in Physics: given, to prove, prove. Once I was in that mindset, it was not difficult to do. Next step was finding out what scientific material existed on the subject. I was a bit afraid that I would find many papers that already proved my point. Strangely that was not the case. At least, I didn’t find that kind of papers. It is a tiresome process, but it must be done. I read a lot about research as such. What are the different methods that can be applied in what context? Which kind of results can you expect for each of these methods? And especially: techniques to objectively analyse the collected material during the research. This was not a very exciting part but essential if you want to obtain scientific relevant results from the research.

The fun part

To study my research question, I wanted to do some interviews and an experiment. It was difficult to find the right people. Lucky for me, AMS helped with finding a relevant case for the interviews. The experiment got a delay because it was very hard to find people that could spare the required amount of time for participating in the experiment. It surprised me that it was so difficult to find experienced information modellers. Doing the interviews and executing the experiment were pure fun! I loved the insights I got from listening to the interviewees and observing the participants of the experiment. Next difficulty was how to process all the gathered information objectively and scientifically. My promotor helped by proposing the technique of key word analysis. I was afraid that I would lose important parts of the insights if I only worked with key words. So I made a mix: I tried to process as much input as possible in the key word analysis and I kept a separate chapter for the observations and insights that couldn’t be captured by key words alone. Both approaches were very useful. From the key word analysis I found the root causes why Business and IT are not always working together in an optimal way. The observations and insights showed me what was key in the collaboration between Business and IT.

The conclusions

The problem statement and solution seem obvious. But if they are so obvious, why is the solution so little applied? The analysis of the key words gave me the answer: higher short term project cost and more energy, focus, and dedication needed from the people working on the software project. Since the long term gain had never been quantified, people don’t take the risk with the higher short term cost. Moreover, intensive collaboration between Business and IT requires a change of mind set, a change of culture. The observations of the experiment showed me that pair modelling encourages the involvement of Business in Software Projects and makes them aware of the importance of their correct input. It made them even think critically about their own way of working. Both experiment and interviews showed the importance of assigning a shared responsibility to Business and IT for defining the base for Software Projects. In the case study, Business had the responsibility to create and write the definitions themselves for the concepts they use and define themselves the relations between the concepts. IT modeled the concepts and their relations, with the input from the Business, and Business validates the model. In the experiment Business felt more responsible and the quality of the model was rated higher by both Business and IT when pair modelling was applied.

The experience

The start was difficult. At first, I couldn’t grasp the general approach and structure of a Master Project. I put a lot of time in finding my way and I had the feeling that the progress was going slow. I wrote, rewrote and deleted lots and lots of text, struggling to apply the feedback I got from my promotor. Apparently that is a normal phase in doing a Master Project. Once I could get to the core, doing the interviews and experiment, everything fell into place. I rewrote the existing chapters (again) but now I had a clear story in mind. Maybe I could have started more efficiently, but the first struggle was not a waste of time. I used everything I read and found out and wrote and rewrote, but I brought it back to the essence and reduced it to the scope of the Master Project. The rich background I obtained that way helped for defending the Master Project and is still relevant when I present the Master Project to interested parties.

What I learned

Even if a research question seems obvious, only by studying it, you get to the core of the problem and bring out the essence. The overall results were no surprise but the importance of the ruling factors got much clearer. Based on the research, these factors can be presented to the involved parties in a similar situation with the pro’s and cons, and will enable them to make conscious decisions. I found out that even if the research question and results are not a surprise, new insights are always possible. In the case study, it made a huge difference that Business wrote the definitions of concepts themselves! I found this even more striking and meaningful than the conclusions on the observations of pair modelling. For me personally, the most important discoveries are that there are still things to learn, and surprises to be discovered, even if things seem obvious at first.

Not the end

The Master Project demonstrates that involvement of Business is essential in software project but that there are key factors that discourage optimal cooperation between Business and IT. It would be interesting to find out if these factors have the same relevance for the different ways of executing software projects (e.g., agile, waterfall, hybrid), and for the different kinds of models needed for software projects (not only information model, but also process model, case model, organisation model, requirements model, business rules, …). Key to convince management is to be able to quantify the long term gain of optimal cooperation between Business and IT against short term cost. This means lots of opportunities for future Master and Doctorate Projects!