Individual Report

Abstract

The document contains information about the ongoing project for Securitas Direct. My contribution to the project, predictions of how everything will outcome. I will also cover the project preparations.

1. Introduction

This is the individual report 2 for the Securitas Direct project. The project contains both programming and hardware knowledge. We are assigned to work on a project for the customer for six months. I have been assigned the role as a Head Programming Architect.

2. Enhancement of my Competence

During my first report about this project [2] my intentions were to learn about project management in general and enhance my competence about leading a group as the Head Programming Architect. These six months have passed by with both good and bad times but it has all been good for my own competence. Thus I can come to the conclusion that my experience as leading a group from a programmers perspective has sharpened up. There’s two ways of leading a group, either you take experience from all parts in the group, this may not always be a possibility but in a smaller project like ours this was possible and all of us helped out leading the project in the correct direction.
The other way to lead is being a dictator and assign work to whoever fits, this may however cause conflicts in the group. Both of these ways have been tested in our group and I have come to the conclusion that sometimes you need to be a dictator in order to get to the milestone of the day and sometimes it’s necessary to take in knowledge and thoughts from everyone else.
When interviewing personnel on TetraPak Lars[1] got this amazing quote from an employee;

“..if there was a problem we only wrote ‘we solved it’, you do not write how you perhaps tried two-hundred thousand other things that did not work …”

This is clearly something that I’ve tried to live by in my ways of working in a project. However this generates conflicts in a group because when you do know something and you decide that it’s not necessary to share this when someone else stumps onto the same problem, they will become angry.
However we need to take in mind that the best way of learning is failure. If you do fail you often know why you failed and this will be remembered next time a similar problem comes up. Thus what I tried to do is analyzing the situation, giving only the smallest amount of information to my comrades so that they learn and might not be obligated to ask next time. We can see that this actually is something that bigger firms are adapting a TetraPak[1] manager said;

“..you should no longer have information served, instead we turned it upside down. We told the employees that now you have to search for information”

Spoon feeding co-workers will never work, if they do not have the nature of searching before asking, you need to force this into their heads. Except from all this management experience I’ve overcome, I have also learned a lot about programming and programming architecture. As mentioned by Stephen[3] one obstacle is a lack of awareness and lack of understanding the importance when being a Software Architect. This is clearly something that I did; I tried understanding the importance and requirements of being Software Architect.

2.1. Conclusion

This project has been very worthwhile; I’ve learned a lot about both working in a smaller group and my experience as a programmer has evolved.

3. Good versus Bad

3.1. Failing Cohesion

There are very few groups that work perfectly together the first time they make a project together and our group was no exception. The group might not be the worst case when it comes to failing cohesion and we did actually handle it. Of course it’s very hard to make everyone like each other all the time. But we did our best. However some of the times we lacked communication abilities and just sat down in a corner stuck and didn’t ask anyone for help or gave any status reports. This behavior is very dangerous if it’s not handled correctly. We did manage to handle these, but something that’s important to remember is, we need to handle it before it happens, because we lose time when we get these kinds of obstacles.

3.2. Rupture regimentation

Imagine you work on something for a couple of days and when it’s nearly finished everything collapses and you need to start all over again, but the thing is that you do not have time to start over. This is something that destroys the regimentation completely. This is a big issue that we had, our project was very hard to take on and we lacked a lot of knowledge that we should have had before we started. And this made our discipline fall down to the bottom of the ocean. But all problems need to be handled and this is no exception. Thus we had daily meetings and talked about progress and if there were something that we didn’t understand. You need to be able to communicate, otherwise the project will fail.

3.3. No knowledge

As mentioned above we lacked a lot of knowledge, some of these were hardware related, there has been no courses in our education plan. At least not on this level. There were also some lack in programming skills, but as I’ve said before in [4] and I quote myself;

“There are no projects that can’t be done. Never underestimate yourself. Take a book and read it.”

3.4. Positive approach

In the beginning of this project our approach of the project was in a very positive attitude. We liked the challenge and really looked forward to start programming. As a lead programmer I had to believe in the group and the competence, even though I didn’t always, I really had to give the group a positive aura.

3.5. Open discussions

The group worked very hard to have open discussions about everything project related and we had other discussions as well that helped the group become tighter. I believe that you need to have some kind of cohesion training and having open discussions is a very good way of training this and it also might open doors to allow new people inside your castle walls.

3.6. Cooperation volition

This part speaks against previous parts in this report, depending on the approach. Let’s look at it in this way, we all wanted to be able to finish the product and deliver a well programmed and formed product. We were all very eager to start programming and see the outcome. However the rupture knowledge and the failing cohesion made this very hard. But even though we all knew form a certain point that this project was not going to be fully deliverable. Even though the discipline fell apart sometimes and the rupture regimentation, we all wanted to continue and made the best out of the situation.

4. Project Outcome

4.1. Anticipation

I believe that our entire group for six people anticipated that it would result in a better way than it already did, after about half the project time had passed, we all realized that we needed to do some changes in our way of working; and this we did. After we made these changes a lot of pieces fell into the correct place and we were able to deliver. Even though we didn’t deliver what was anticipated from the start, we did deliver what was anticipated after our second analyze.

4.2. Summary

The project has been very educating in a very good way, I believe that the best way of learning is my failing and even though we did not fail all the time, I learnt a lot. Our customer got a product that they might not feel useful but we all learned a lot of new things, such as new programming languages, project management and most important, I learned more about documentation and software architecture. As I predicted in both [1] and [4] there would be organizational issues and so there were, but we managed these as good as possible and the project did finish. As a future reference I will tell myself over and over again to review what the project is all about and I will push my comrades to read all documentation and books suggested.

10. References

[1] Lars Lindkvist, “Project organization: Exploring its adaptation properties”, Journal of Project Management, ScienceDirect, Linkoping, August 9 2007, pp. 13-21.

[2] Filip Ekberg, “Individual Report 1”, Ronneby, February 10 2008

[3] Stephen T. Albin, “The Art of Software Architecture”, Wiley Publishing Inc, 2003, p 56

[4] Filip Ekberg, “Individual Report 2”, Ronneby, 2008, p 2