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

Done By:
100022914 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/UniSAnet-
4/?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: Plant, location:

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
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