Week 1 – Global Outsourcing

After a 7 week break it’s back to studies! Allen began our lecture by giving us a brief insight into the history of global outsourcing illustrating the various benefits it had to offer. We were then instructed to read a case study on MAT. In our groups we formulated questions that had occurred to us throughout our reading of the case. The six questions were as follows

1)      Cost of damage so far?

2)      What are the security issues with external prov. ?

3)      What cost comparison between external and internal?

4)      What IT services are “business critical?”

5)      Who owns/accesses our data “in the cloud?”?

6)      Can and how to control external supplier?

Our group formulated the question “What was the cost of the damages so far?” Our thought process began by looking at the reams of bad luck that MAT had endured ranging from physical on site fire damage to bots infecting their mail servers on numerous occasions. We were curious as to how much financial damage they had endured up to this. We felt it important to take this point into consideration because if it is more cost effective to continue fixing these problems as they occur rather than switching to the cloud and risk the privacy of their data then why do it? We concluded that when weighing the benefits of switching to the cloud, financial benefits alone could not be taken into consideration. Intangible benefits such as control over your own data would have to be considered also.

Allen then delegated the task of each group answering another group’s question. Our group discussed the problem surrounding data in the cloud (question 5) It is an extremely ambiguous area and difficult to answer in a black and white manner. We began by discussing how relevant jurisdiction was to the question. The fact that laws regarding data can vary so drastically amongst countries meant that MAT, should they chose to switch to the cloud, would need to be well informed as to where their data would be stored/viewed and the correlating laws. Who would own/access the data? We talked about this a length discussing varying possibilities. Perhaps MAT could outsource some of their more monotonous tasks containing data that was not highly important and keep their more sensitive data tasks on site? The option of buying the rights to their most important data was also talked about.

We concluded our opinions with the following points. MAT should switch to the cloud. The on – site fire damage and critical network outages suggests an unsuitable location and poor connectivity and perhaps would require large scale infrastructural investment to rectify. Their continuous bot attacks suggest they have a poor security system and do not possess the appropriate security infrastructure. Moving to the cloud would enable highly sophisticated levels of security and would eliminate the location issue. However the question of data remains. It is a matter of trust and being well informed. MAT should be as informed as possible regarding data laws but also trusting that their provider will not use your data inappropriately, it would cause damage to both company’s reputation.  

RTE player film

For our film Rayanne came up with the idea of doing an RTE news report in order to illustrate our ideas! We used windows movie maker which was quite easy to use. We filmed video and voice clips separately on iPhones and added them in. Windows movie maker made the editing process quick and simple! We imported the RTE clip at the beginning through youtube converter.

https://docs.google.com/a/ucdconnect.ie/file/d/0B1d2kB1DT_oedGktTVlMTzkwZTg/edit

 

RTE Player online

For our systems development project Noelle, Rayanne and I chose to enhance the RTE online Player. We chose this project because although it was a good system which provided a useful service it still had minor issues that may have the potential to drive many first time users.

We chose our research methods based on the Look Learn Ask & Try IDEO cards. Our surveys were used in order to gauge whether individuals were still using the PC as a means of accessing RTE player. We all participated in the try it yourself method which was important to complete very early on in the task. We had compiled our own thoughts and ideas on the systems and what we really wanted the research methods to yield was ratification or dismissal of our initial instincts.

The affinity diagram research group was, in my opinion, the most fruitful method. Our group was diverse and contained a good mixture of those familiar with the online player and those not at all familiar with it. Those who knew the online player ratified our own initial thoughts. The surprising thing to note from our affinity diagram work was that those users who were unfamiliar with the system provided the most useful insight. They provided us with insight that we ourselves and other familiar users had missed, for example the need for the Search Bar to be bigger.

After assessing our research method results we compiled a list of developments. The new features  or improvements we want to implement are as follows

1) Movies Page

2) Improved Personal Profile

3) Subtitles

4)  Kids section

5) Better integration of social media

6) New de- cluttered homepage

For the implementation of our new design we favoured some agile methods as we classed the RTE player online as a medium system that would be continuously evolving. “Design for today, can go anywhere tomorrow”.  We wanted our stories to be implemented slowly so as not to effect the everyday running of the player. We used RTE’s in house software developers and created a vigorous marketing plan in order to pull in new users.  Overall undertaking the project was the exercise I felt I gained the most knowledge and experience from. It required us to pull together everything we had learned in the course thus far including both theory and practical aspects. Below are some of our sketches for our new interfaces.

Soul of a New Machine – Overview and thoughts!

The Soul of a New Machine – Tracy Kidder

The mandatory reading of “Soul of a new Machine” was a valuable addition to the course. The story was so many things rolled into one. It was a lesson in software development practices and strategy. It was a lesson in start up companies and would make for an interesting study of leadership psychology.  Tracy Kidder expertly distils an historic project in a company’s history and creates an enthralling narrative. Kidder’s focus on the psychological phases undergone by the team members was, for me, how he created such an interesting story. By the end I felt so involved as if I were a member of the team! It proved to be an interesting insight into the internal workings of a business, politics included.

I enjoyed the focused insight into Tom West in particular. His risk taking abilities were evident in both technological advancements through use of mode bits but also in his hiring process. To hire graduates fresh out of college and give them high degrees of responsibility is something that is rare to hear of even now. West was interested in those who were doing it for pure love of the job and not for the money. His top down management style was unique but worked for the “Eagle Project” as it was a time constrained project that needed high levels of motivation and creativity which could be best generated by the inexperienced who just wanted to build something.

 West’s style of “Mushroom Management” appeared to be a driving force of culture within the workplace.  The crazy hours of unpaid overtime and the fast paced environment dominated by continuous pressure were driven by high levels of motivation. The time pressure was an interesting factor in the tale. The endless deadline changes and the incredible amounts of overtime gave a continued tense atmosphere to the work environment. Their way of thinking was realistic and it really didn’t matter how hard you worked on the project so long as the end product did what it was supposed to. “It doesn’t matter how hard you work on something, what counts is having it work” – Holberger.

Although this book was written over 30 years ago it is interesting that it is still applicable to organizations today. I expected the book to be a technical analysis of creating a machine and was surprised at the lack of technical content. A key question of Kidder’s is what drove these individuals to work so enthusiastically under such isolated conditions. I believe the competitive atmosphere and constant sense of urgency to get the Eagle out the door before competitors must have instilled adrenalin in them. The ability to work on a new innovative machine and to be given such high levels of responsibility was an incredible opportunity. The book was as I said a valuable addition to the course and gave a bird’s overview into all aspects of an organization’s workings.

 

 

 

 

Accenture Experience!!

Last Tuesday evening I attended an open night in the Accenture offices near Grand Canal station in order to gain a batter insight into the company. Throughout the evening we were given talks from managers and graduates alike. We were given advice and tips on how and what to apply for, the different areas we were eligible to apply for and also a great insight into what each job area involves.

I decided to share my thoughts on the experience as a particular part of the evening was extremely relevant to lessons I had learned from my managing systems project on the RTE player. We we split up into various tables with 8 – 9 people per table and were given a case study. We were told we had 40 minutes to answer 3 questions on the case study and then present them to the room. One question referred to a business strategy, one referred to a technological problem and one referred to an analytical problem. As a group we decided the best way to approach the case study was to divide the questions up between us and 2 -3 people would take a question and formulate points.

Myself and another student took on the question regrading technology which was : What risks are involved in undertaking large scale IT developments? I found myself quickly able to draw upon my project experience and formulate the following points

• customers need to be kept in the loop and fore warned about possible disruptions
• Are staff IT competent? If not what has to be done?
• Efficient testing of the software needs to be undertaken from an early stage of design (drawing on examples of agile methods)

Our comments and suggestions were well received by the Accenture managers and graduates overseeing the presentation. It was by far the most intimidating, yet interesting part of the evening and I was surprised by how much content from my managing systems development project and lessons I was able to draw on! 

Spaghetti Cantilever

We undertook quite an interesting and enjoyable class exercise during week 9 which required us, in groups of 4 or 5, to build a cantilever using spaghetti sticks, blue tack and sellotape.

We were instructed firstly to come up with guidelines or principles that we would follow throughout our session. We composed the following guidelines

• listen to one another and don’t talk over each other
• make sure everyone understands an idea before moving on
• write down everything!!

After we had composed these principles we set to work. There was 4 in our group and while 3 worked on the design the 4th was tracking the progress using a Design activity graph which tracked high, medium, and low level problems, scenario thinking and requirement thinking. The team member in charge of this tracking would rotate every 5 minutes.

Our group dynamic worked well and our process was interesting because although we did not sketch any possible designs first, we just launched into it, it still worked quite well. I was first on the rotation to track the design activity and concluded that most of our thinking was done within the fist 5 minutes. When I was relived of this duty I began to help with the design. I stood back for a moment to watch what my team members were doing and to get a grasp of where the project was going.

Our cantilever worked quite well due to our stability system. We ensured stability by using small thick bundles of spaghetti grounded on a completely flat surface. Our base was wide and flat which allowed for distribution of weight of our thick spaghetti bundles.

This exercise was definitely one of the most enjoyable. We were given the materials to design and create a model cantilever with no guidelines or tips. It allowed for creativity and innovation and was a good way of allowing us to see what it might be like to work on real life projects. It was interesting to see how every group in the class had something completely different. Different combinations of minds can assemble totally different creations in many different ways. Below are some pics of our proud creation 🙂

They write the right stuff!

This was a very insightful piece written by Charles Fishman into the role of software processes. The piece was based around the processes used by the “on board shuttle group” who write the software for NASA projects. The key point that stood out for me in the article was quality versus cheapness/speed.

The processes followed by the shuttle group are precise, detailed and incredibly structured. To quote the piece “the shuttle group now finds 85% of its errors before formal testing begins, and 99.9% before the program is delivered to NASA.” This perfection occurs due to the intense preparation done in advance of writing software. No code is written until the design is fully complete. They stick to rigid guidelines, which as pointed out, eliminates freedom or innovation with regards to software design. Creativity is stifled unless it has something to do with altering the process.

This unyielding system brings to mind a comparison from “The soul of a new machine”.  The Eclipse group that had worked on Eagle seemed to hold different values with regards to Software development. West himself had written up on a white board in his office “Not everything worth doing is worth doing well” Relative cheapness was a key factor while time was most certainly of the essence. If a younger engineer were to approach West with a request for the new Eagle, the reply was generally “no, there is no time for that”.

However, obvious industry differences exist between both stories and it makes for a somewhat weak comparison of examples.  West’s or rather Data General’s ambitions were for profit. It can be done cheaply, right, or quickly, so pick 2! West’s team had to work quickly and cheaply if they wanted to complete the machine within a year. Any errors would be found and improved on later. However the shuttle group were dealing with real human lives and shocking amounts of money. There is no space for creativity or laxness in such conditions. They worked continually improving software for shuttle launches and have developed for themselves a separate culture form modern day software companies. Their success lies in their process. They work set hours and have realistic goals. They have to write software that is perfect not simply good enough.

It is interesting to note that essentially both the shuttle group and the likes of Microsoft software engineers do the same jobs but for different purposes and yet their way of doing it so dramatically different! The lax dress code of Microsoft and its late nights compared to the office like structure of the shuttle group brings about an interesting point. Could a dramatic change in process alter Microsoft’s quality of software? Or is the need for speed and the highly competitive nature of the technology sector simply too high for Microsoft to implement such a structured regime? My opinion is that Microsoft stick to how they are currently operating. The difference in purpose of both groups makes all the difference. Personally I don’t believe Microsoft can afford to stifle creativity with such a rigid regime and risk losing an innovative edge.

Planning poker!

 

Planning poker is a method used to assign time estimations to projects. In groups of 4 we were given a list of activities involving a primary school teacher attempting to teach students about programmable robots. Each activity described how the teacher would attempt to teach the children about programming the robot and the tasks the children would carry out e.g. construction of the robotic base. We were each allocated a set of cards with various numbers written on them. As a group we clarified that the numbers would represent hours. We went through the list of activities carefully and after reading each one we would silently and separately decide how long we felt it would take for the teacher to teach the theory or how long it would take for the children to carry out each activity. We put our card with our choice of time face down on the table when we had come to a decision. When everyone had individually chosen a card we turned them over at the same time and discussed our choice of time.

This exercise forced members to justify their choice of time. In some instances members may have had very high or very low numbers compared to others. We had to explain our reasons for believing a specific activity would take longer than others or perhaps why we felt that children would pick it up quickly and required far less time. It forced us to tease out the activities and realise that certain projects have different conditions to others. For example, in this exercise, we were dealing with children. It was important to bear in mind that the learning capacity of children was a major factor with regards to time. A teacher could not possibly spend a week and a half on one particular exercise as interest would more than likely be lost. Initially we had a slight problem with regards to understanding what the numbers on the card represented. Some understood it to be an hour whereas others understood it to mean a full school day. This bump occurred early on and was easily rectified although it did demonstrate the need for clarification amongst groups. Planning poker allowed us to do more than plan a timeline. As we were forced to justify our reasons it meant we broke the project down and understood it better. Where there was dispute, it was discussed and provided interesting insight that usually led to consensus.

Research Methods

So far the practical aspects of the module are proving to be quite interesting and allow for a more hands on approach. In pairs we were each allocated a specific research method to be used and applied to a real life situation. My partner and I were to use affinity diagrams, a method that would hopefully yield some interesting insights into how customers feel about commonly used systems and their design. We applied the method to the AIB smart phone application. We asked a group of 5 individuals to take part in the exercise and told them that we were going to design a new user experience for the app. We sat them down and asked them to voice opinions on how user friendly they felt the application was and how they felt using it. We then penned their thoughts in single words on post it’s and came up with appropriate headings for the post its. The headings were posted to the board and each individual was asked to go up, one at a time, and group the post it’s under the various headings. This was done in silence. When we had a majority consensus of how the points should be grouped we discussed the findings.

As a research method it was a useful exercise as it is easy to conduct and yields a lot of information. The visual aspect of the method allowed us to make links between the individual post it’s. The fact that it was done in silence meant a range of opinions were voiced and therefore presented a truer reflection of what customers want. By allowing the participants to speak would have meant risking one or two dominant voices taking control and minimising the feedback.  There were a lot of ideas being thrown around and so the diagrams allowed visual structure and hierarchy of points made. 

Communication is key!

In week 2 our practical exercise consisted of the construction of a programmable Lego set which would, upon construction, be programmed to follow instruction for movement. At the end of this task we were asked to physically map out how our group found we handled the task. Our task began quite well! Our robot has been previously nearly fully assembled by a different group so we went with the old mentality of “if it ain’t broke, don’t fix it”! Unfortunately we ran into a bit of trouble when Allen dismantled it for us to have a proper go at it. Needless to say we didn’t complete it as quickly as our first record breaking attempt.

We didn’t start out well as we didn’t assign roles to various members but rather just launched ourselves into it. Coming towards the end when frustration set in we gave roles to our group members e.g. finding the various pieces needed, reading the instructions and physically assembling the pieces. The task began to run more smoothly, however we were too late in implementing a structure and failed to finish it. For me the most beneficial part of the exercise was the reflection. The physically timeline of our experience allowed us a more accurate summary of what went wrong with the task, at what parts it went wrong and why? This in turn allowed for suggestions of how we could have avoided the frustration we experienced.  

The exercise was a good lesson in proving that communication and structure is an integral part in development. Our initial lack of structure led to a breakdown in communication as nobody really knew what to do. The instructions were clear and all the necessary parts were present. It proved that regardless of how sophisticated, promising, or seemingly simple a product/system may be, without good organization and communication is it surprising how easily its execution may fail.