Gopal Pathi Premkumar Discussion

University of South Australia School of Electrical and Information Engineering

EEET2025 Systems Engineering 2 Stud Period 6, 2005

Joy flights to Space

Project Process Discussion Assignment Tutorial Group: Tuesday 2-4pm

100022914

Done By: Premkumar Gopal Pathi 03 November 2005

Disclaimer I declare the following to be my own work, unless otherwise referenced, as defined by the University’s policy on plagiarism.

Contents ......................................................................................................................................................1 University of.................................................................................................................................1 South Australia..............................................................................................................................1 Project Process Discussion Assignment...........................................................................................1 System Development Model.............................................................................................................3 Structure of Team......................................................................................................................3 Planning of Deliverables...........................................................................................................3 Team Development Process .............................................................................................................5 Group Dynamics Analysis................................................................................................................6 Group Participation Report...............................................................................................................7 Team Report......................................................................................................................................8 Course Evaluation.............................................................................................................................9 References.......................................................................................................................................11 Appendix A:....................................................................................................................................11

2

Project Discussion System Development Model Structure of Team There are 18 members in the team and they are split into four groups with four members for two groups (the Safety and Non-technical groups) and five members for the other two groups (Technical and System Aspect groups). The System Aspects team is concerned with the overall understanding of the system, and the shoulder the responsibility to bring together and to coordinate the work of the various portfolio concerns to ensure the resulting documentation and design is of a single unified whole entity. The Technical group had the task of proposing and recommending solutions for the customer’s needs through analysis and research. The Non-technical group are to focus on researching the aesthetics of the customer needs. The Safety group has the role of evaluate the critical scope of each situation and also the ethical, environmental and legal safety required. The Project Manager had the task of ensuring co-ordination of teams, timely deliverables and also ensuring all deliverables meet the specification of the customer by working closely with the Project consultant on-site. The Project consultant is the end-user customer representative who would provide assistance on clarification of the expectation of needs and deliverables. The hierarchical model of the team is as follows: Team 1: System Aspect

Project Consultant

Team 2: Technical Project Manager Team 3: Non-Technical Team 4: Safety Figure 1.1 Hierarchical Structure of Team

Planning of Deliverables The team went through the dot point deliverables from the course webpage. As a standard procedure, although it was not required in the dot points, as appointed Project manager, I felt we had to address the first and upmost important document - the project plan. This should be always present for any project. Next, we worked out the deliverable sections required for the project which would plan for the expected deliverable timeline. The schedule to deliver the team project proposal to the customer was 1st November and the first meeting was spent planning on deliverables and datelines. Using a “bottom-up” planning

3

approach, the initial draft was targeted to be due a week before (disagreeing with opinions that it only takes 3 days for compilation) and subsequently a week for each for each of the documents needed was needed. This made the team realise that although it was week 5 and while it looked early, however, with at least 6 major documents due, time was actually short and the subsequent weeks should be spent planning for delivering and reviewing each document. From a system perspective, the time margin to deliver a proposal for a joyride to space in a period of 10 weeks is deemed as an uphill task. The best approach to this would be to address the more of the top level functional analysis rather than performing a functional breakdown to the component level details which may not be feasible approach to have to achieve a wide coverage in the shortest timeline possible. Costs, maintainability and feasibility are some important factors that need to be emphasised to convince the management’s approval for consideration for project proposal put forth. The use of standards and references would help reduce the need to break down the component requirements further as they already would have been addressed for conformance to known standards.

4

Team Development Process The interaction model between the teams was planned such that all members would have an equal opportunity for participation. The planning was such that all teams would have equal turns to compile sections of the eventual single deliverable document. The main concerns of working together in a big team working towards having a single deliverable documented proposal would include addressing standardisation of document formats, a common style of expression and identification of key players who could ensure timely deliverable and quality of the document. By compiling the documents in early stages, the team could be moulded towards a cohesive unit and strength and weaknesses within the team can be identified. Some of the key players that were identified were Sam England from the safety team, having observed some of Sam’s work for Renewable Energy System proposal and the high quality of his IT Physics reports. I have identified him as probably the best potential candidate to assume the role of auditor for our documents. Sam was scheduled to be away for his project presentation and SIFE competition presentation for a few weeks and we would be missing his services till October and could best contribute as an auditor as his return schedule suits well with our planned final date for the compiled document. Chang Shi Hao, my project partner has an excellent understanding of the technicalities of requirements and functional analysis, having worked closely with him for my final year project documentation and observing his skill sets from his SE1 documentation. However, there is a need to eventually have an autopoietic organisation, one that is self-sustaining, thus the other potentials in the team need to be identified to strengthen the team and this could be done by rotating the chairman around for the first few weeks and have different people document agendas and meetings. As a result of implementing this process, the team had a well contingency plan that was put to use when an unfortunate incident caused Chang Shi Hao’s services to be missed when he had to be away on compassionate grounds. The rotational experience eventually helped in identifying the group leadership potentials in some of the members from a rather quiet team that originally started out: Technical team members: Lim Ted Cheng, Tim Saddlier, Non-Technical: Michael Belperio and Bailes Serge System Aspects: William Diep, Sujatha These members eventually assumed the roles of group leaders and were competent in assuring timely and quality of deliverables from each section.

5

Group Dynamics Analysis Mr Paul Bunnik was the consultant for the team and he addressed the topic and had initial discussions on interpretation of the topic. However, this subject required the ability for students to demonstrate skill sets of management, hence his involvement had to be limited and he had to assume an observatory role. The initial enthusiasm of the team was high, with everyone eagerly discussing the different technological knowledge they had about Space programs. The team had a debate upon stumbling onto the problem statement, with the reasoning why “Space” was in inverted commas, stating that technically a simulation proposal could be feasible. The non-technical team members, especially Bailes Serge in particular, had demonstrated his technical knowledge with some good justification. Sam England from Safety Team was also knowledgeable in some aspects of the technology, and at the end of the day, it was Sam and Bailes going loggerhead at each other. I could not contribute much in the first week as I felt that I should do my research on the topic well and obtain more facts. In the following week, when the type of technologies used was discussed I was able to contribute with some of my findings. However, I also noted that the technical team was still not very participative; having 5 members and only a couple of them actually contributing to the discussion and that was only on occasional bursts. An observation made was that majority of the other Non-English Speaking (NES) background members did not engage much in the conversation, as this might be a problem of their disability in fluent vocal communication in English. Another possible reason for some non participation by members was that there was probably a psychological factor, as most of the students were engaged in their final year and busy with their projects. Only a handful was doing honours and these students have more concern for their grades and would seriously take into account of the statement of team contribution, and these members were the more active participants. I have past work experiences in project management with Apple Computers and a few other organisations (please refer to Appendix A) and felt I could best contribute by assuming the role of Project Manager. I decided to revert to this role when in week 5, while the discussions were productive, there is a need to address the deliverables. I felt I had to step in to ensure that the goods are delivered. Some of the expected deliverables for this project were fairly difficult to comprehend and this sometimes threw meetings into frenzy, with each member having their own opinions. However, just as in the real world where not all customer requirements are well understood by contractors, it is important to have a strong communication protocol with the customer and review team’s expectation on deliverables constantly with him (for this case it was our consultant, Mr Paul Bunnik and at times, Dr Tim Ferris). Having a close communication protocol with the customer is necessary to obtain an in-dept understanding of the need. One of the novel approaches put forth involved designing jet-pack strapped onto the customer and releasing him from a high altitude (via a plane). However, the existing jet-pack technology could only have fuel that last 20 seconds into flight and thus the team chose a rather epistemological approach and this was ignored.

6

Group Participation Report By working in small groups, participants have the opportunity to make a significant contribution as views and points can easily be discussed as the scope of the group is generally smaller as opposed to the bigger group. There is much more interaction. Co-ordination of meetings is much simpler for management of small scale numbers. Communication between members is expected to be much better and productivity as a result should increase. However, in this team, there were some problems faced, firstly, the team was very much reduced to 3 members for most of the tutorials as Sam England had to leave overseas for SIFE competition for a few weeks. Some of the other members always had a problem of delaying deliverables, not addressing them properly or simply not wanting to make contributions. This is viewed as a rather unprofessional conduct and it still needs to be addressed. The approach adopted as a measure was to first send a group warning to that individual, stating that that this was clearly a non-conformance to standard practise on his part, and when this did not go well, the next step was referring him to the relevant management for further action. The later worked well and the team member did pull his weight in after the action was taken to send him a warning of non-conformance. The other approach that was considered only in late stages (had used this method during my SE1 documentation where a similar problem occurred) would be to have a documentation author page, stating the deliverables by each individual on the document. However, one has also to consider the drawback of integration as a team should this be implemented as individuals would only address the issues from their own perspectives and may not want to put efforts for team cohesiveness as would not bring mush recognition. However, the prepositions of having the author page are still useful in documentation control and should have been implemented.

7

Team Report Large teams are harder to coordinate as planning for common meeting times are rather challenging tasks. Many different options would be raised and it could be an uphill task at times to have a common solution to all problems. The unexpected problems did require additional thinking to deal with and this reverted to additional factors to be considered during planning stages for next course of events. One of the key problems noted during the first three weeks was that the meetings often fall adrift as not much planning was planned at those initial stages. Any meeting should have the basic agenda, previous meeting minutes, review of deliverables, discussion and planning to accomplish the next deliverable is utmost important. There should also be a meeting minute taker at every meeting. For efficient productivity, the meeting minute should be ideally sent within the hour of conclusion of any meeting, clearly stating and specifying all issues discussed and all action items and task owners for the next meeting. However, one problem noted here is that while efforts were taken to send the minutes, there was not much effort by the team to have a copy of the agenda with them during the meetings. As project co-ordinator, I had to ensure that the meetings went smoothly therefore ensured that all teams had a printed a copy of the meeting minutes to ensure that everyone is in the same page. Participation is needed from all team members. In the initial stages, there was a display of an enthusiastic approach by everyone. However, as the weeks pass, with other deliverables sinking in, the team morale would have a tendency to go low and performances tend to deteriorate. As I was exposed to different kind of management, I considered two different approaches to address this problem: The first type of approach would be Total Systems Intervention (or TSI) meta-methodology model, where dominant metaphors would be used to highlight major issues. The nature of this model would be to use an authorial figure (works well in government organisations). Tasks are delegated to members without much questions asked and critics. The other members are expected to be self motivated and should view comments and review in good light as a reflection to make necessary changes for the good of the team. However, this method often inhibits participation from all levels and thus the leader might not be able to accomplish much from a demoralised team and he may eventually suffer from lack of resources. Also, the group members may simply turn up for the sake of attendance and depend on the leader for directions The other approach is soft system approach, where participation from all members is encouraged. Having worked in both environments before (was in the Military as well as the commercial sector); my consensus would be to review the situation which I was in. I preferred the Soft Systems approach as it is a rather more professional approach to doing things and especially beneficial when applied to working in sectors such as research reviews, business proposals and community development activities and reverted to this approach when I chaired the meetings.

8

Course Evaluation As engineers-to-be, these tutorial sessions are indeed very useful to prepare us to handle large and more complex projects that are expected in industries these days. These tutorials have thought us the necessity to have interdisciplinary skills such as communication skills, project management skills and the basics of cost and budget analysis. As demonstrated in this tutorial, the ability to resource for talents and knowledge of the various skills of the individual is also an important factor to help in planning projects. It is always important for a leader to maintain composure by ensuring that he/she maintains the focus and vision for the team into and steer them in the right direction. The project leader should understand all fundamental aspects of the deliverables required although he may not know necessarily need to know the technical details of all aspects in great detail depths. The IEEE publication entitled “Transactions on Engineering Management, Volume 48 No.1 dated 01 February 2001 by William J. Lannes perhaps offers the best summary to sum up the discussion: “Not all engineers progress through all stages to an Engineering management role nor do they progress at the same rate. Some would suggest that this progress is often limited by lack of opportunities or desires to become engineering managers. It is my view that the limitation is primarily because of a lack of desire; not all engineers want to manage projects and people. On the other hand, good engineering managers are always in demand; so the opportunity is there for the willing.” This course has made be aware of the greater expectations that I have to shoulder as a professional Engineer. The reference points in this document are the best reflection according to my collection of the aims and objectives of this course. [1] Use decision theoretic methods to evaluate project choices; [2] Understand the use of systems level modelling and simulation; [3] Demonstrate knowledge of the importance of human resource management, organizational behaviour and people management in systems engineering; [4] Understand the importance and analysis of product reliability and after sales support; [5] Understand the nature and importance of test and evaluation in product development; [6] Describe ethical and legal issues pertinent to engineering; [7] Understand and appreciate the difficulties of engineering teamwork. [8] Understand the role of systems engineering standards in project development. [9] Be able to perform elementary system level modelling. [10]Be able to perform elementary system trade-off studies.

9

[11]Be able to participate in the negotiation of project objectives and requirements in a design team. [12]Be able to plan a system respecting the competing demands of design, performance and lifecycle support. [13]Be able to participate effectively as an engineering design team member. [14]Be able to negotiate technical specification and requirement issues with respect to a system.

10

References Ferris, Tim, 2003, ‘SE2 Course Statement’, University of South Australia, viewed 30 October 2005, http://www.unisanet.unisa.edu.au/learn/UniSAnet4/?PATH=/Resources/13398/Systems+Engineering+2/&default=Course+Info.htm. What is Engineering Management? By William J. Lannes, III, Fellow, IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, VOL. 48, NO. 1, FEBRUARY 2001

Appendix A: Profile of Premkumar Gopal Pathi Work Experiences: 1) Institute of Telecommunication Engineering, University of South Australia, Mawson Lakes, from July 2005 till present Appointments: Satellite Ground Station Crew member 2) Apple Computers Singapore, from August 1999 till June 2003. Team: Worldwide Operations Team, Appointments: Test Engineering Assistant (promoted to Test Engineer in 2002) : Appointed Resident Engineer to be stationed at the following subcontractor plants for the duration stated Duration: March 2000 – May 2000 Sept 2000 – Oct 2000 Jan 2001 – Feb 2001 Feb 2001 – March 2001 March 2001 – Feb 2002 Feb 2002 – Dec 2002 Jan 2003 – June 2003

Plant, location: LGE (PT) in Seoul, South Korea Natsteel, in Penang, Malaysia Apple Computers, in Sacramento Apple Computers R&D, in Cupertino LGE (MX) in Mexicali, Baja California, Mexico Foxconn, in Orange County, Los Angeles, California Foxconn, in Shenzhen, China

Other Experiences: March 1997 – May 1998

Munitions and Explosives Technician in Singapore Armed Forces, Singapore June 1998 - June 1999 Training and Demolitions Specialist stationed in Thailand, under joint Singapore-Thailand Army

11