This post is a bit irrelevant, it is a reflective report I was made to write at the end of a group project, read it for pleasure or don't read it at all !
------------------------------------------------------------------------------------------------
In its early phase, this project felt like walking into a room blindfolded – we were new to the course material and hardly understood the deliverables expected of us. We were new to each other. We commenced with a series of unfocused and uncoordinated, albeit entertaining, set of planning meetings. We established a plan of action and work method. As the academic term progressed, we were exposed to new techniques and improved upon our processes. The final result reflected a number of recommendations found in system development literature. In this reflection I will identify what literature was most influential and explain the logic behind our eventual changes.
I will also detail the specific contributions I have made which helped shape our product and work environment. This will lead on to further analysis about my strengths and weaknesses and the role they define for me.
The development of our work environment and practices
When we first sat around a table to discuss the project, our main focus was hardly on group rules and work practices. Our initial group rules document was very basic and was only drawn up as a formality. However, one thing was clear from the outset; we needed a system for telecommuting. All team members had other commitments, and we needed to communicate efficiently. I was able to suggest a solution to this as I had prior experience with virtual meetings using Google Group technology.
We soon realised that more formal rules were necessary. The first team workshop highlighted the need, and I redrafted the group rules document immediately after the workshop. I posted my version on the Google Group and, to my relief, my unilateral initiative, which I feared may meet some resistance, was appreciated and implemented. My group members all agreed on the new, improved work practice/group rules document. We subsequently followed the rules and often even quoted the document in order to enforce one point or the other. It became our charter.
One paragraph in the document discussed the level of commitment expected by the group. I feel this was of particular benefit. Once everyone formally agreed to the higher level of commitment, the team seemed to bond much faster. It was almost as if the risk of free riding was diminished by simply discussing it, even though the basic economic principle of free riding should theoretically not have been diminished; as no alterations were made to the reward/punishment system (Coase,R.H, 1938). Nevertheless, reflecting on this point, I think that the clarity of the communication between us fostered trust, and this was all-important.
By the project completion deadline, the team managed to create an effective work environment that accommodated many suggestions prescribed in well-known field studies (Bill Curtis, Herb Krasner, and Neil Iscoe, 1988).
We attained a highly iterative process through a formalised collaborative procedure, where each member was expected to contribute his or her opinions to other member’s work. We found that Google Groups technology assisted knowledge sharing and implementation and speeded up communications. I think we utilised the tool effectively, and this benefited the project.
Our ground rules document covered detailed practice issues such as conflict resolution procedures. We distributed research work and tackled the learning process with professionalism - the vast array of literature summaries on our Google groups is evidence of this.
These actions are all recommended by Curtis, Krasner and Iscoe in their case study report, which influenced the final version of our work environment and procedure. I find myself very much in concurrence with their recommendations and arguments.
Their literature also inspired us to re-examine our work practices through the lens of the “Layered Behavioural Model”, through which we noticed situations where more formalised collaborative work procedures would have resolved bottlenecks and quality control issues that we had previously ignored.
We realised that group work was not getting quality controlled, and the lack of any formal leadership contributed to this. Our work was fast becoming a mine of minor errors and incoherent terminology. Our iterative process helped deal with the bigger issues and concepts, but no one was looking at the detail. I took it upon myself to proof-read the documents and again the team appreciated my initiative. We also scheduled a scrupulous team quality control meeting before submitting the work; yet small errors may still be encountered in our work.
Our “flat” team structure is also accountable for many for the co-ordination problems we encountered. We often encountered situations where one or more members had deviated from the pre-agreed argument or structure. As team members proceeded in the completion of their tasks, they identified better ways of structuring their section of the work, but this often led to departures from the pre-agreed structure, impacting the work of others. A substantial quantity of work had to be reshaped into a new structure and at times scrapped altogether. If this were a larger and more complex project, an unacceptable amount of resources would have been wasted due to our inexperience and, more importantly, lack of leadership; and the attainment of the project’s objectives would have been jeopardised.
This is not to say that if I were to redo the project I would advocate a formal organisational hierarchy. We were all inexperienced, did not know each other, and I am not sure how we should have proceeded to appoint a leader. Our experience, however, highlighted to me the great importance and the need of formalised work procedures and guided work practices, as well as the benefit a strong leader may have on a project.
"No organization can rise above the constraints of its leadership. It is therefore imperative that leadership at all levels be constantly growing beyond their constraints." - Flip Flippen
Evaluating myself within a team context
My previous experiences with teamwork were not encouraging; very often, I ended up taking control of the situation in a rather aggressive and unproductive fashion. This was not because I wanted things my way, but because I felt that other team members were not as motivated as I was, and I ended up carrying more than my fair share. Working with the talent at LSE spelled out a completely different story, and I have tremendously enjoyed the experience.
The role I played in the project is hard to characterise and it varied depending on the stage of the project. My most prominent role was of constant constructive criticism. I always let others explain their opinions, and often agreed with them. When disagreement occurred, I tried to affirm my logic, compromising on points that I felt had less import. I believe I had a strong impact on the decision making process and upon the quality of the final product. However, I was not stubborn and consider myself to be a good listener.
There really is only one area where I had tried to be assertive, and that was about the detail of modelling to be done. Some team members concluded that since only one class diagram needed to be presented, then only few use cases needed to be analysed; and that accordingly we should not get bogged down in the detail and complexity. I had a completely different view about the purpose behind the modelling stage; I look upon modelling as a mechanism to “iron out” the complexity, a method to tackle it and lay it out. I eventually managed to bring about a change in the team’s attitude by highlighting the need for tackling the complexity in our models, and by showing the interconnectivity of models; an exercise in “Socratic questioning”.
However, I also noticed that I was holding up the process, and that although I knew what needed to be done, I was relying heavily on the knowledge of other team members to actually draw the models. I eventually realised that some modelling I was working on myself was beyond the scope of the project. This is when the true benefit of team work became apparent, the right balance being found through a dialectic process of compromise and re-evaluation, producing a final result which the whole team understood to be the better than the individual efforts.
The experience indicated to me that I am effective in a managing role; but I can also identify certain risks related to the freedom offered to me by such a role.
I believe I am suited for a managing position as I have proven myself an able communicator; I am effective at coordinating teams, bringing them together and directing their attentions. I felt able to easily understand and value other people’s contributions and quickly put them to use, and I realise that not every member is so in tune to the collaborative effort.
However, as a manager I would need to counter my own weaknesses. I am an extremely creative character; I also love detailed examinations and often find myself going beyond the scope of a project. I find it very beneficial having to justify my ideas before they are applied, as they often need refinement or may even not be applicable. The proposition of letting my creative nature lead straight into the work pipeline without any filtering may not be the best way to capitalise on my creative potential.
Managers need good judgement skills, and one may easily doubt my judgment abilities after reading the above statement. I feel very confident in my ability to evaluate and make good use of other people’s ideas. It is my own that I am unable to scrutinize objectively, which is perhaps not surprising. Understanding one’s own limitations is important. This is a personal characteristic that I will have to be conscious about in the future, and that was brought to my attention thanks to this group project.
Conclusion
This project has been a continuous learning process for me. I benefited from the hands-on experience. I also acknowledge the many insights gained from subject literature.
Our academic background played a most influential role in shaping our project. Some issues and problems would have never even been identified, let alone addressed, had they not been mentioned in lectures.
Finally, I also learnt a lot from other members; more importantly, I learnt how to better appreciate the input of others and just how vital knowledge transfer and knowledge management techniques are for successful project development.
Bibliography and references
Coase,R.H. (1938). The nature of the firm, Ecomica
Curits, B, Kraser,H & Iscoe,N (1988) A field study of the software design process for large systems, Communications of the ACM, 37/1, pp.93-105
Flip Flippen : quote found at http://www.schipul.com
Peter Levin’s book, (2004) The Successful team work, Open University Press, ISBN 0335215785
