Gdplga006a PDF

®
Group Development Project

Disclaimer
While every effort has been made to ensure that the information contained in this courseware is
free from errors and omissions and is not misleading in any way, Whitireia New Zealand Limited
(trading as Computer Power Plus) makes no representations or warranties and is not liable for any
loss or damage or injury of any kind (however caused) under any theory of law including
negligence resulting from or in any way connected with the use of this courseware.
Copyright 2012
© This courseware and the concepts, information and material contained in it are the copyright of
Whitireia New Zealand Limited, a Private Training Establishment (PTE) No. 9344 (trading as
Computer Power Plus) and may not be used or reproduced in whole or in part without the prior
written consent of Whitireia New Zealand Limited. All rights reserved.
Edition Released: January 2012
Publication No.: GDPLGA006a

Table of contents
CONTENTS
SECTION 1: PROJECT ORGANISATION ................................................................. 1-1
Topic 1: Introduction .................................................................................................... 1-2
Topic 2: Making a Beginning ....................................................................................... .1-8
Topic 3: Project Deliverables ..................................................................................... 1-17
Topic 4: Communication ............................................................................................ 1-22
Topic 5: Assessment.................................................................................................. 1-26
SECTION 2: PROJECT FUNDAMENTALS ................................................................ 2-1
Topic 1: Definition of a Project ..................................................................................... 2-2
Topic 2: Project Constraints ........................................................................................ .2-3
Topic 3: Project Overview Statement ........................................................................... 2-5
Topic 4: Development of the Project Workplan .......................................................... 2-13
Topic 5: Monitoring and Controlling Progress ............................................................ 2-18
Topic 6: Closing the Project ....................................................................................... 2-20
SECTION 2: WORKING IN A GROUP ....................................................................... 3-1
Topic 1: Elements of a Group ...................................................................................... 3-2
Topic 2: Leadership ..................................................................................................... 3-6
Topic 3: Group Decision Making .................................................................................. 3-7
Topic 4: Establishing a Strong Team ........................................................................... 3-9
i
Table of contents
SECTION 4: ADMINISTRATION ................................................................................. 4-1
Topic 1: Team Personnel Problems ............................................................................. 4-2
Topic 2: Summary ........................................................................................................ 4-4
APPENDIX A: RESOURCE MATERIAL ....................................................................A-1
APPENDIX B: SYSTEM DEVELOPMENT PRACTICES .............................................B-1
APPENDIX C: WINDOWS LIVE GDP GUIDE .............................................................C-1
ii
Introduction
INTRODUCTION
This course provides students with the skills and experience in working together on an IT
development project, using a team approach. This team approach could involve a variety
of electronic tools, as used within global IT project teams.
COURSE OBJECTIVES
On successful completion of this course, you will be able to:
 Determine and confirm a client’s business expectations and needs

 Develop and present a feasibility report
 Develop a system design plan
 Develop an integration plan
 Ensure that a proposed IT solution meets the client’s strategic goals
 Develop a project plan
 Match the company’s IT needs with the strategic direction of the enterprise
 Participate in a team and individually to achieve organisational goals
 Apply time management, project integration and quality management processes
 Participate in planning the testing and documentation of programming code that
may be developed within the course
 Design a project life cycle and determine project stages leading to the completion of
the separate project tasks with respect to the project baseline.
RESOURCES
 Group Development Project learning guide (GDPLGA006)
PREREQUISITES
Successful completion of the Personal Effectiveness 2 workshop (PE2) is the minimum
prerequisite for this course.
As with any project you may encounter in the workplace, be prepared to use personal
skills and to draw from your own wealth of life experiences in this course. Do not rely
solely on the knowledge and experience you have gained during your Computer Power
Plus course.
ASSESSMENT
This course comprises 2 component courses:
 GDP Trigger (GDT) – 5 hours

 GDP Project (GDP) – 45 hours.
The assessment for these courses takes the format of a quiz based assessment
completed during the GDT course, and a project which is completed during the GDP
course.
GDPLGA006a Computer Power Plus iii

Introduction
A more detailed breakdown of each assessment component and its weighing is provided
below.
 GDT Final Exam (Compulsory) – (0%)
After the study of the GDP learning guide, this exam must be passed to complete
the GDT course. This exam consists of a 60 minute online quiz using a variety of
questions types. Students must achieve a score of 60% (pass or fail) or more in this
assessment component to be considered competent. The exam is open book and
can be attempted as many times as is required to pass. This exam must be passed
before a student can begin the GDP course. This is marked but does not contribute
to the GDT course mark.
 GDP Project (Compulsory) - (100%)
This project occurs during the GDP course and involves a project for a client where
a group of students work together to produce a solution for the client.
Assessment for this course is made up of 3 main items:
 A team performance mark, where the team will be judged on how well they
performed together. This contributes 15.5% to the GDP course mark.
 An individual mark, where your contribution to the team effort will be judged.
This contributes 15.5% to the GDP course mark.
 Assessment of the proposal your team submits. This contributes 69% to the
GDP course mark.
Each student must achieve a score of 60% or more in their individual mark; and the
team must achieve a score of 60% or more for the combined team
performance\team proposal part of this assessment component to be considered
competent.
iv Computer Power Plus GDPLGA006a

Introduction
HELPFUL INFORMATION
Learning guide layout

This Learning Guide contains different types of study materials as indicated by the
following icons.
Reading icon
This icon indicates that you need to read and study the topic. You may also be
directed to study Sections of associated reference materials.
Activity icon
When you see this icon, you have the opportunity to experiment with the
features previously described by completing a practical exercise.
Assessment icon
The assessment icon is used to help reinforce what you have learned
throughout the learning guide to check your understanding. It is also used to
specify any assessment activities that are requirements for assessment.
Timer icon
This icon indicates an estimated study time for a topic.
Hot tip icon

This icon indicates a valuable tip, hint or note.
GDPLGA006a Computer Power Plus v

Introduction
STUDY PLAN
The student plan provided below is a helpful tool in making sure that you complete this
module in the time provided.
Please be aware that the student plan is based on 5 hours study per day at the campus
and that you should be completing at least two hours revision at home.
Day Reference Topic Subject Time Dates I will Date

(S = section (mins) study this completed
T = topic) content
1 S1 T1 Introduction 15
S1 T2 Making a Beginning 25
S1 T3 Project Deliverables 20
S1 T4 Communication 20
S1 T5 Assessment 20
Total Time 100
S2 T1 Definition of a Project 5
S2 T2 Project Constraints 10
S2 T3 Project Overview Statement 20
S2 T4 Development of the Project 25
Workplan
S2 T5 Monitoring and Controlling 10
Progress
S2 T6 Closing the Project 5
Total Time 75
S3 T1 Elements of a Group 20
S3 T2 Leadership 5
S3 T3 Group Decision Making 10
S3 T4 Establishing a Strong team 15
Total Time 50
S4 T1 Team Personnel Problems 10

S4 T2 Summary 5
15
Final Assessment
vi Computer Power Plus GDPLGA006a

Group Development Project Section 1: Project Organisation
1.0 SECTION 1
PROJECT ORGANISATION 100 mins
OBJECTIVES
On successful completion of this section, you will be able to:
1. Explain how the GDP is set up

2. Work productively with your group’s client and supervisor
3. Communicate with the other members of your group
4. List and describe the deliverables of the project
5. Explain how the GDP is assessed
TOPICS
1. Introduction
2. Making a Beginning
3. Project Deliverables
4. Communication
5. Assessment
GDPLGA006a Computer Power Plus 1-1

Section 1: Project Organisation Group Development Project
TOPIC 1: INTRODUCTION
15 mins
Welcome to the Group Development Project Trigger (GDT) course and the Group
Development Project (GDP) course.
The Group Development Project is Different!
One of the main benefits of studying at the Computer Power Plus is that you can work on
your own in a self-directed environment. You set your own goals, choose when and
where to study so that you can complete your assessments and stay on schedule.
However, as an IT professional, you will almost certainly be required to work in a team.

People with good team skills are in great demand because most IT work is organised
into projects that are undertaken by teams of employees or contractors. It is therefore
very important for your career that you develop your team work skills.
There are also other vital skills that are used in the workplace, namely time
management, task planning, document writing, that you need to learn if you going to be
a successful employee.
Because you are given only one or two very limited opportunities to develop and practise
the work place and team skills elsewhere in your qualification, the main purpose of this
course is to give you more experience in working as a member of a group or team
producing a real-life business solution.
The GDT and GDP Combination
The GDP course appears in your qualification schedule as two separate entries:
 Group Development Project Trigger (GDT - 5 hours)
GDT is the trigger point for introducing you to the GDP. In GDT, your task is to read this
learning guide to familiarise yourself with the course. You then sit the 60 minute GDT
Flash based Quiz exam in which you are tested on your knowledge of the GDP learning
guide. This is an open book exam and you are able to resit it as many times as required
until you are able to pass. After passing the GDT exam, you then continue with the next
course. The GDP Supervisor will add every student who passes the GDT automatically
to the list of students waiting to do the GDP course.
You will then continue the next course in your schedule because GDP is done
concurrently with other courses. You will be notified by e-mail by the GDP Supervisor
when your project is ready to commence.
 Group Development Project (GDP - 45 hours).
The GDP Supervisor will put together a team of about eight to ten students and guide
you through the Induction phase of the GDP. Your team will then be given a project to
create a system proposal for an external client.
What the project is about
In GDP, you will be working with several other students as a team to solve a business
problem. To provide an air of realism to the scenario, your team will function as if it is
working for Computer Power Plus to produce a system proposal for a client company’s
1-2 Computer Power Plus GDPLGA006a

business solution. The company will be represented by one person, the “GDP Client”, to
whom you will be introduced. A Computer Power Plus staff member, the “GDP
Supervisor” will oversee your team’s activities. You will be provided with the project’s
briefing notes by the Supervisor.
Because you will be working in a team whose members can be part-time or full-time
students, it is not practical for the full-time students to work on such a project exclusively
and continuously. Also in any real work situation there will be times when you have to
shift focus between more than one task, and manage your time to achieve a number of
outcomes. Also being organised in your personal life requires you to jungle multiple
tasks during a normal week, so learning this skill is to your benefit. You will thus need to
manage your study time and allocate time between the GDP course and the current
course you are studying in order to make progress in both. Don’t be alarmed that this
uses up hours from your current course, as you will receive a 45 hour credit once GDP is
completed.
The hours allocated to GDP are to be used up over approximately an eight-week period.
If you are a full-time student, you will be completing other courses of your course while
involved from time to time with the activities of the GDP. All students should expect to
spend a minimum of eight hours per week on GDP tasks (5 hours shift time plus 2 to 3
hours homework time). Therefore part-time students with the minimum eight contract
hours per week should dedicate most of their contact time to the GDP to maintain the
required contribution to the team effort. Because the course will take many weeks to
complete, we advise you and your team to make a start at the earliest opportunity.
Because GDP is a concurrent course, the amount of time spent on the project
necessitates careful planning; otherwise your current course may suffer as a result of
over-indulging in the activities of the GDP project to the disadvantage of the other
course.
Your Goal for this Course
The projects are based on real-life business problems. While the projects are no more
difficult than any you have completed in previous courses, they are complex and can
only be conducted within a team setting. As you are very likely to be involved in similar
situations in the workplace, your goal is to work professionally and productively with
other team members to produce an IT solution proposal for a specified business
problem.
Feedback from previous GDP students
Below are comments made by students, based on their experiences of the GDP course.
They are comments made to other team members or to a student’s supervisor. The
comments have only been edited for spelling and grammar. Names are omitted to
protect privacy.
The GDP applies in industry more than we might think.
Comment: … I know the feeling. I had a Computer Power Plus Evening last night. Got
home about 10ish & was working on GDP till about 2 am.
One night is bad enough, but two in a row is even worse... Mind you, I wouldn't have
missed the coffee& chat last night for anything - very useful. The ex-students also
assured us that as unrealistic as the GDP looked, it applies in industry more than we
might think - that turned my head a little.

I really learnt a lot.
Comment: Here’s the End Of Project Report and Review.

Got to admit I really learnt a lot from this - it’s an awesome exercise!
Thanks for all your patience and guidance!
This exercise is bound to impress any prospective employer.
Comment: I would also like to take this opportunity to thank everyone for their efforts
over the past 2 months. This proposal would not have been possible without everyone’s
contributions. I think the team performed exceptionally well under trying conditions and it
is a credit to you all that we have achieved what we have. It has been a real pleasure
working with you all. (As much fun as it has been......YEAH.... its over!!) I suggest that
everyone keep a copy of the proposal for reference as this exercise is bound to impress
any prospective employer. Once again thank you everyone…
Employers like the GDP.
Comment: According to placement staff, employers like Computer Power Plus’s GDP
course, and what’s more concerning is that they love to hear that the students are
tearing their hair out.
Communication is a major factor for success!
Comment: It was great working with you all. At first I found it unusual communicating
with people I’ve never seen before. It felt so awkward! I guess I’m a visual person.
Anyways I learnt much from this project, amazingly (didn’t think I was going to). But I
learnt that communication is a major factor for success! We achieved success, no doubt,
but we communicated very well! Something I KNOW other teams are struggling with! So
great work everyone and if I never talk to you guys again then I wish all of you great
success!
The GDP has helped us grow into stronger individuals.
Comment: We’ve had some interesting ups and downs throughout the project, as far as;
one person pulling out, a step down from the original team leader and occasional
communication breakdowns, we all had these situations affect us in different ways which
has helped us grow into stronger individuals; by not letting situations that we can not
avoid get us down, being confident and giving things a go even if we make mistakes
along the way and staying focused on tasks and goals.
I’ve seen documentation similar to what we worked on in the GDP.
Comment: Just to say thanks; it’s been a great experience for me with the GDP. I’m
currently doing field site training and seen documentation there similar to what we
worked on in the GDP and yes I have learned a lot from it thanks to everyone involved.
I’ve asked for an extension in training and it’s resulted in a possible 18 week contract
with the company at the end of this month, not bad for someone who knew nothing
about computers 9 months ago. Well thanks again it’s been a lot of FUN.

NOTE: The objectives of the GDP course are about working with others to
solve a client problem and the process of designing a system, not about
building a system, cutting code, or making new applications. The nature
of the project will be an IT problem, and the solution you identify to solve
the client’s problem is important. However, this course requires a team
effort. Your involvement, communication and performance as a team
member and the quality of the proposal you produce are as
important as the solution. In this course, the focus is as much on how
you arrived at the solution and how you present it as on what the solution
is.
Group based assignments provide these positive valuable lessons:
1. Learn from others and share ideas

2. Learn to work in a group, which reflects real industry
3. The social interaction
4. The division of work, which saves time
5. The fact that you can achieve more - a larger project and better quality outcome
6. Gain communication skills.
In a perfect world, group projects would have no problems. There would be no conflict,
no slacking, everyone would contribute and things would run smoothly according to
schedule. But group based assignments can also have downsides and these can be:
1. The inequality in the contribution of members

2. Timetable and other logistical problems
3. Conflicts
4. The fact the some members lack required skills
5. Being dependent on other people.
So what can you do to take advantage of the positives and minimise the negatives
during a group based project. Here are some ideas:
 Make a team charter. Before you even start working on your project, sit down with
your teammates and create a charter that encompasses things like:
 the goals and objectives of the group;
 how you will allow each person to equally communicate their views (clear
communication is key in successful group work!);
 information on when and where your group is going to meet on a regular
basis, and contact information for each group member;
 an exit clause, clearly stating what will happen if people do not show up for
the meetings or don’t do their work;
 and how you will resolve conflict should it arise.

 Exercising flexibility will make a difference. Being patient is very important.

Don’t take things so personally when people don’t agree with your ideas. Listen to
others - don’t always think that you are the only one who is right. Be willing to
compromise.
 Determine the strengths of the team members. First, figure out what needs to
be done on the project. Then assign each person in your group a responsibility
according to their abilities. It’s important and helpful to find out what people are
good at and then assign roles accordingly. For example, someone who is good
at writing reports, but hates research should not be stuck doing all the research.
Allow each person to develop his or her abilities within your group.
 Set deadlines for each group member to get their assignments done by. This
establishes clear boundaries and helps to prevent stress caused by leaving
everything to the last minute. The team leader is usually responsible for this, but
each team member needs to set their own deadlines to complete their own
individual project work on time.
 Take the lead if needed. So what if you get stuck in a group with a couple of
slackers in it who really don’t care about how the project goes? By taking
leadership, you will get the chance to expand your leadership capabilities and also
ensure that work gets done. And what if your other group members have nothing
to contribute? If group members aren’t responding, encourage them to contribute
by asking them directly by name for their ideas.
 Finally, stay positive about your group. Refrain from gossiping about other
members and try to help one another as much as you can. After all, you may even
come out of the experience with a friend or two.
ASSESSMENT
Assessment for this course consists of three main items:
 A team performance mark, where the team is assessed on how well they perform
together. The manner in which you communicate with each other, the way you
organise yourselves to achieve the team’s goals and the effectiveness of the team
will all be assessed.
 An individual mark, where your contribution to the team effort is assessed. Your
involvement in the meetings and discussions, as well as your commitment to
allocated activities and your ability to meet agreed deadlines are all taken into
account.
 Assessment of the proposal you submit. The team’s submissions to the client are
assessed on how well they meet the client requirements and the professionalism
of the presentation documents, not on the elegance of the IT solution.
The assessment structure means it is possible for a team to pass the GDP, but for one
or two members of that team to fail because they have not made a satisfactory
contribution to the team’s success. A student who fails the GDP will be reassigned to a
different team and required to repeat and pass the course in order to graduate. Failing
GDP too many times could result in you being dis-enrolled from your qualification, just as
doing a bad job can get your fired from your job!

Progress reports and reviews
During the project, two mandatory “Progress Reports” are made to your Computer
Power supervisor. S/he will need to know what each member of the team has achieved
so far, whether the client is happy with the project developments, how any difficulties that
have arisen are being dealt with and whether the project is progressing according to
plan.
Your supervisor will be able to advise you on what is required to correct any
unsatisfactory performance. You can then make sure that you do what is required for
you and your team to receive good marks in the End-of-Project Report and Review.
End-of-Project Report and Review
When you have submitted your final proposal, you will be required to present a
performance report in the same format as the progress reports. This “End-of-Project
Report and Review” is marked and contributes to your final mark for the GDP.
The final review also includes a peer appraisal of the other members of your team to
indicate your assessment of the quality of their participation and achievements.

TOPIC 2: MAKING A BEGINNING

25 mins
In this topic, you will be introduced to the overall setup of the GDP program and you will
find out how to proceed with your project. The GDP program includes the GDP Trigger
(GDT) course and the GDP Project (GDP) course, and is made up of a number of steps
and each step builds on the previous one.
You should complete all the steps in order.
Step 1: Complete the GDP Trigger Course – GDT

Your first task is the GDT course which is the introduction to the GDP program. You
need to familiarise yourself with the GDP by reading (and rereading) this learning guide.
Make sure you thoroughly understand what you need to do before moving on.
Step 2: Complete the GDT Quiz Exam

When you are confident that you understand the material covered in this learning guide,
you complete a Flash based Quiz Exam. This is an open book exam and you may re-sit
it as many times as necessary without penalty in order to obtain the required 60% pass
mark. The result of the exam does not count towards your score for the GDP course.
Step 3: Continue On With Your Next Courses

After passing the GDT Exam, you are eligible to begin the GDP course project.
You will then be moved on to the next course in your schedule because GDP course is
done concurrently with other courses. You should get started on your next course as
soon as possible.
At some point later usually in the second half of your qualification; the GDP Supervisor
will contact you by e-mail to let you know that you have been assigned to a team and
that your GDP project will begin soon.
If you do not hear from the GDP Supervisor by the second half of your qualification,
contact your institute’s GDP Supervisor via e-mail (see the e-mail addresses below) to
confirm you are on the list and to let them know you are ready to begin GDP. The GDP
Supervisor may be able to assign you to begin the GDP project earlier.
If you have any known future absent time away from the institute (if you plan to have
holidays or are away on work), then e-mail the GDP Supervisor to let them know when
you will not be available.
The e-mail addresses for the GDP Supervisor at each Institute are as follows:
 Auckland - gdp-supervisor-auck@mail.computerpower.ac.nz
 Wellington - gdp-supervisor-wgtn@mail.computerpower.ac.nz
 Christchurch - gdp-supervisor-chch@mail.computerpower.ac.nz

The GDP Supervisor will match you up with other registered students to form a team that
will have a variety of skills and abilities, which is perfect for solving complex problems!
When this has been done, the GDP Supervisor will send an email to the members of the
new team advising them of the team’s composition.
There are two phases to the GDP project:
 Induction Phase – Where team members start to work as a team by completing

tasks utilising skills they will require for the main project
 Main Project Phase – Where the deliverable documents for the client are created
by the team.
Within these phases are several review steps where the team’s performance is
assessed.
An outline of these phases is shown below:
Induction Phase:
Task 1 -
Arrange a Task 4 -
Task 2 - Task 3 - Task 5 -
meeting Produce
Delegate Research Elect Team
and combined
research assigned members to
complete research
tasks tasks Team Roles
Team report
Profile
Total Time Approximately 10 days
Project Phase:
Task 4 -
Complete
Task 1 - Task 5 - Task 6 -
Task 2 - Task 3 - Training,
Receive Produce Complete
Complete Complete Testing
Brief and Final Post
Feasibility System and
write to Proposal Project
Study Design Implemen
client Report Review
tation
Plan
Total Time Approximately 55 days

Step 4: Starting your GDP Project. The Induction Phase

After you have been notified of your team, it is important for all team members to get to
know each other, to begin to communicate effectively and to become a close-knit unit
ready to tackle the project itself. We call this the Team Induction phase. Team members’
strengths and weaknesses need to be recognised so that the various tasks can be
undertaken by those best equipped to do them well, but it is also important that the work
is shared equally between all team members (see page 1-5 to 1-6).
Each team member is required to fill in their details in a team profile during this
induction phase. Information on how to do this will be e-mailed to you by the supervisor.
The GDP Supervisor will also e-mail you a list of four topics, which the team must
research and put together in a report. Since there are 8 to 10 team members initially in a
team, each team member will only be required to research one topic at most and may
also work along with another team member as a pair. For example, if the team only has
6 members (because a few members leave the team), then some team members may
work on one topic alone, while 2 members may be assigned to work on one of the other
topics together. It is recommended that you have an initial team meeting within a day or
two of starting the induction phase, to decide who will research each topic, and who will
edit and submit the research report to the GDP supervisor.
The report is just a list of the topics and the information that each team member(s) has
researched. A team member should be chosen to compile and submit the report to the
supervisor. The information in each topic should be checked for spelling errors and to
ensure it is readable and understandable before submitting it to the supervisor. The
purpose of this induction phase research report is to get you ready for the GDP project,
by giving you practise in researching and writing information, and cooperating with your
fellow team members.
Your GDP team will have 10 days from when the GDP Supervisor notifies you by e-mail
that your induction phase has begun, to complete all the induction phase activities. It
should take 2 to 3 days to form your team, fill out the team profile, and hold your first
meeting. The next 7 days should be used to produce the research report.
Thus during the 10 day induction phase the following must be completed:
 Fill out your details in the team profile

 Hold one team meeting
 Produce a research report document
 Hold a second team meeting to elect your team leadership and establish how your
team will operate.
If these activities are not completed in the first 10 days then this will delay the beginning
of your GDP project. This may have a negative effect on some of your fellow team
members who are facing time pressures to complete their whole qualification, so please
cooperative with your team and do your best to ensure that the research report is
completed on time. This is what would be expected in the workplace – a professional
approach.
Therefore it is essential that you regularly check your student emails, to ensure
you read and respond to all e-mails in a timely manner!

Once the research report has been submitted, you will receive a “Project Briefing
Document” that outlines the project assigned to your team as well as marking schemas
which show you what you are required to produce and what marks you can earn. Read
over the Project Briefing Document to familiarise yourself with the project and get
together with the rest of the team to discuss the requirements.
At this point the team should hold a second team meeting where you will chose which
team members will take the 3 leadership roles for your GDP team.
At this second team meeting, all participants should:
1. Introduce themselves and express what they bring to the project, their interests,
qualifications, and even preferences in projects.
2. Choose a Team Leader who will keep participants on target and involved and
manage the teams’ work. This choice is determined by who would like to volunteer,
their experience and expertise with organising people and tasks, and even their
desire to learn about group management.
3. Determine the strategy of how often to meet in person or through technology,
where the group will meet, communicating including e-mail and (cell) phone
information, and how to distribute minutes and updates. All documents produced
by the team should be stored in the Documents area of the Windows Live Group
setup by the Supervisor, so that all the members can have access to them. Team
members can store documents they are working on, on their H drive or on
Windows Skydrive. Using Windows Skydrive allows you to give other team
member permissions to view or edit your documents, so this is a better location
than the H drive for GDP team documents. Appendix C will provide instructions on
how to use the Windows Live tools.
4. Summarise objectives in a team charter (see page 1-5). Each member
independently writes down one or two main objectives of the project, and then the
group compares these, extracts key words and phrases, and then prioritise the
results.
5. Determine the process to achieve the objectives. What is the timeline? What are
the deliverables and when are they needed? Do you need sub-groups? What
project planning tools can you use to manage the team (Gantt, Critical Path,
PERT)? What applications do you need - word processor, spread sheets,
presentation software (PowerPoint) etc. This information can also go into the team
charter.
6. Analyse the Project Brief and reach some conclusions about what the project is
about and what may be involved.
When the team is completely familiar with the project, you make your first contact with
your GDP client by sending an e-mail that introduces your team. This e-mail needs to
be written and sent to the GDP client within 2 days of receiving the project brief.
All project time-lines, deadlines and milestones are calculated from the date of this e-
mail, hence it is important that you do not delay writing and sending out this e-mail!

Step 5: Making progress on your GDP Project

During the GDP, your team will need to submit four separate documents to the client to
satisfy the project requirements. These documents, called deliverables, are submitted to
the client at the end of each of the project development stages:
Stage 1. Investigation and Feasibility Report

Stage 2. System Description and Project Plan
Stage 3. Testing, Training and Implementation Plans
Stage 4. Final Proposal
Figure 1-1 shows the overall structure of the GDP within the allocated timescale.
Figure 1-1
Once you begin the project, the GDP Supervisor will give you dates for each stage by
which you must submit the required documents for that stage to the client. The
documents should be submitted to the Supervisor two to three days before each stages
deadline to get the Supervisors’ opinion on the document before submission to the
client.
The submission date for each stage takes into account weekends and holiday periods.
Extensions may be granted by the Supervisor if extraordinary events occur, such as a
major team member experiencing a medical emergency. Extensions to submission dates
will not be given for poor organisation by team members. Marks are lost for every day
that a submission is overdue.
You should hold regular team meetings at least once during each stage. These team
meetings may not always be at a time to suit every student on the team, but they should
be arranged ahead of time, and every team member should endeavour to be in
attendance. If you cannot be there for reasons beyond your control, you should always
inform the Team Leader. Failure to communicate with your team members is
unprofessional and may be reflected in low scores during the end of project peer review.
You should thus check your student e-mail account every day while you are working on
the project, so that you do not miss out on important information until it is too late. E-mail
is also used to communicate with your fellow team members when you are collaborating
on work.
It is thus important that every team member communicates and cooperates with the
team in a professional manner and completes the work asked of them in a timely way.

The Team Leader also communicates with both the Supervisor and the Client during the
stages to clarify project requirements and to get feedback.
Likely activities during each stage of the project will include:
1. Research: library, Internet, experts, etc

2. Research analysis: consolidation and identifying key concepts and issues,
planning for gaps, requests for assistance, etc
3. Solution development: Development of solution alternatives and individual
sections
4. Write/compile document: Executive Summary, body sections, closing
statement/argument
5. Bibliography (if required)
6. Review and evaluation: Output produced, process used, participation by members
7. Project summary
Topic 2 covers the details of the GDP Project.
Induction Tasks
At the start of the GDP course, time is set aside for the Team Induction process as
outlined above. The usual length of time required to successfully achieve the goals
associated with this process is about seven days from the first team meeting. During this
phase there are a number of tasks to complete which include:
 the collection of team member profiles

 establishing communication protocols and a file sharing system for the project
 completing the research report
 establishing client contact protocols and customer service goals
 electing your leadership team
 plan how your team will tackle the project itself.
The GDP Supervisor will set up a Windows Live Group at the beginning of the induction
phase, which the team can use to help manage the group project and share and
collaborate on project documents. Your team needs to set up its own file sharing
arrangements using the Windows Live system so that all team members have access to
the team’s documents. The GDP Supervisor will also put important project documents in
the Documents area of the Windows Live Group for your use during the project.
A team communication protocol also needs to be set up with a common address that is
accessible by all team members. Along with certain other team activities assigned by
your team supervisor, making these preparations is all part of the induction process.
Information on how to use Windows Live for the project and the tools available are
contained in Appendix C of this learning guide.

Electing the leadership team

Towards the end of the induction phase, your team needs to hold a meeting to select its
leadership team consisting of a Team Leader, a Deputy Leader and a Communications
Officer. All team members participate in the selection process in a democratic way,
taking into account information from the team members’ profile and individual
achievements in the induction phase during which all members got to know each other.
Different members may assume these roles during the project if the team and/or the
supervisor decide that such a change would benefit the team.
Due to the administration tasks that team leaders have to perform, they are expected to
spend less time on the developing the actual system proposal for the client than other
team members. This is especially so in the team leader’s case. It is not anticipated that
students volunteering for these roles should need to spend more time on the GDP than
the other team members.
Your elected team leader needs to email your GDP Supervisor as soon as the position
has been decided. It is important that your team leader accesses his/her Institute email
several times a day during the project because all e-mail will be sent to this person’s
Institute email address.
From this point on, it is important to remember that the team is in control of its own
activities and its own destiny. You’ll need to communicate with each other and with
your supervisor to determine the roles and responsibilities of each team member. Be
prepared to take on multiple roles, and for the roles to change as the project develops. It
is essential that every team member is actively involved throughout the project. You
need to be flexible and cooperative with your fellow team members in a professional
manner, just as would have to do in the workplace.
Team Leader
The team leader’s role is to manage the team. All team members are expected to
contribute to the team discussions, but they must abide by the team leader’s decisions.
The team leader’s duties include:
 ensuring the proposal meets its required criteria

 ensuring progress is maintained throughout all stages of the project by all team
members. The Team Leader is responsible for creating and maintaining the teams
own WBS for its work and the teams’ progress report to the supervisor
 exercising authority to pull into line anyone not making the required effort
 presenting the deliverable documents of the project to the supervisor and to the
client
 calling and leading team discussions
 making decisions based on the suggestions and discussions of all team members
 acting as the communications liaison between the team and the client and
between the team and the supervisor.
These activities will occupy much of the team leader’s GDP time, so the team leader is
not expected to be heavily involved in writing the project’s systems development work.
But the team leader is expected to take a leading role in editing the final documents for
each stage to ensure that they are delivered on time and are of acceptable quality.

Deputy Leader
The main role of the deputy team leader is to prepare the deliverable documents for final
presentation and to stand in for the team leader whenever s/he is unavailable. It is
therefore important for the leader and deputy leader to work closely together.
As there are normally less administrative demands on the deputy team leader than on
the leader, there will be time for the deputy leader to have significant involvement in the
written project proposal development work.
As the Deputy Leader is responsible for compiling and preparing the deliverable
documents for each stage, it is most important that this team member should be a
person who has skills in document writing and presentation. Because each document
must be presented in a professional manner to the client, it is vital that the document be
well written, understandable, free of errors, well formatted, and internally consistent. It is
the Deputy Leaders job to ensure that all the documents submitted meet these criteria as
marks are allocated for this at each stage. Therefore the Deputy Leader will be required
to edit the team members’ submissions when compiling the documents for each stages
submission.
If any team members’ work is of poor quality then the Deputy Leader’s job is to negotiate
with the member to correct the work. If this is unsuccessful the Deputy leader may need
to re-write their work as part of putting each stage submissions together. In this case you
would let the team leader know, and the team leader will liaise with the supervisor. This
may result in the team member being removed from the team.
If a team member continually produces poor work, then the end of project review gives
each team member the opportunity to provide their assessment of that member’s
contribution to the team.
Section 5 will contain information on how to prepare project proposal reports.
Communications Officer
The communications officer maintains a log of the emails sent between the team and the
client and between the team and the supervisor. This is done throughout the life of the
project. The communications officer also provides summaries of the important
communications between team members as part of the documents required for the two
progress reports and the end-of-project performance review.
As there are less administrative demands on the communications officer than on the
team leader, there will be time for the communications officer to have significant
involvement in the project proposal development work.
Planning the Project

During the induction process, your team needs to plan how you will proceed to the end
of the project. Section 2 of this learning guide shows you how to produce useful project
plans. We recommend that you read this section carefully before you sit the GDT exam,
and again before you start the actual project.
Your supervisor will expect you to plan your work and to submit your updated project
plan as part of the progress reports that follow completion of Stage 1 and Stage 2.

Marking the Project

To grade each student for the GDP course, marking takes place at each stage and at
the end of the project. Marks are awarded by both the Supervisor and the Client for the
content of the documents, the presentation of the documents, and the professionalism
and teamwork you display during the stages. Marks are also awarded by your fellow
team members during the end of project peer review.
The marks available at each stage are shown on the marking schemas for each stage,
which the GDP Supervisor will place in the Documents section for the Windows Live
Group.
The breakdown of the marks for each stage is as follows:
Phase Supervisor Client Team Total %

Stage 1 28 33 - 61 19
Stage 2 32 37 - 69 21.5
Stage 3 28 33 - 61 19
Stage 4 12 17 - 29 9.5
End of 30 20 - 50 15.5
Project
Review
Peer Review - - 50 50 15.5
Totals 130 140 50 320 100
Table 1-1
Each stage is marked at its completion and the results and feedback will be given to the
Team Leader, so that the team can make any required corrections to their project
documents during the following stage.

Topic 3: PROJECT DELIVERABLES

20 mins
Project Requirements
Carrying out a project can be difficult if the project effort is not organised. For the GDP
project to be successful, your team needs to be organised and plan its work. For this
reason, many methods have been developed to assist project teams in carrying out
projects.
The project should be conducted according to the traditional Systems Development Life
Cycle (SDLC) model, in which the main tasks are generally agreed to be as shown in
Figure 1-2. In Appendix B you will find extracts of information about system development
processes that will be highly useful to you during GDP. It is therefore highly recommended
that you study this Appendix.
For the purposes of the GDP course, you will not be delivering a fully developed
system, only the System Proposal, which covers the design of the system to solve the
client’s problem. Although you will not be developing and implementing the new system,
you will be developing a plan for this process. Thus there is no programming or website
development required for this course.
You will find that the project calls for a system solution that consists of a number of
processes and applications. Solutions consisting of a single application do not meet the
GDP assessment criteria and are therefore unacceptable.
Part of your team’s first deliverable consists of a project plan that identifies when the client
company can expect to receive the deliverables at each stage of the project. At this stage,
the project plan will show just the major tasks and milestones, and the proposed schedule
for submission of the deliverables. A Gantt chart (see Section 2, Topic 4) would be a
suitable method of illustrating your project plan. The project plan will need to be accepted
by the client based on the schedule and the project completion deadline date.
NOTE: All submissions to the client should be properly formatted and

edited, and presented in a professional manner. It is also important that
you ensure that the information is consistent within the document, as you
will have different team members working on different parts. Hence
someone in the team should be responsible for reading through the
complied document to ensure that it does not make statements nor has
information which clashes, or states something different in separate areas
of the document. Your client’s impression of the team’s performance will
be largely formed from the standard of the deliverables you submit. Marks
are allocated for formatting and presentation by the client during each of
the stages.

Project Request Form from Client
Problem
Definition
Confirmation of Project Request
Feasibility
Study
These steps
Feasibility Report
belong to
the scope
of the GDP
Analysis
project
Requirements Specification
Design
Design Specification
Production
Documented and
Tested Software
The project
proposal requires Implementation
only a plan for the
completion of this
part of the Model User-evaluated
operational system
Maintenance
Figure 1-2. Traditional model of SDLC
For the team’s initial guidance, the following broad outline of the deliverables required at
each of the stages for this project is provided.

NOTE: The Due dates show below are counted from the beginning of the
client’s project (when you send the introduction e-mail to the GDP client),
not from the beginning of the GDP course which includes the induction
period.
Stage 1: Investigation and Feasibility Study

Deliverable for this stage: Investigation and Feasibility Report
Due date: End of day 15
Following communications with the client to establish a clear understanding of the

requirements, the team will need to investigate potential solutions and applications that
could be used to solve the problem. A number of possible solutions with comparisons
and a final recommendation need to be presented to the client for perusal. The client will
respond, and will give the go-ahead for the project to proceed if one of the suggestions
is acceptable.
If none of the suggestions are acceptable, the client will indicate why and agree on a
deadline for resubmission. In this case, it may be necessary for the team leader to ask
the supervisor for advice.
If you haven’t done so already, you will need to develop a Work Breakdown Structure
(WBS) for your team’s GDP work (what has to be done), assign Resources (who does
what) and a Time scale (when the work is to be done). This is best summarised in the
form of a Gantt chart. See Section 2 of this Learning Guide for information about creating
a simple Gantt chart using an Excel Spread sheet. This needs to be submitted to the
Supervisor 2 days after the end of this stage.
NOTE: The WBS and\or Gantt chart for your team’s GDP work is separate
and is in addition to any WBS or Gantt chart that you produce for the
Client’s project. Thus you will have two project plans – GDP team’s work
plan and the Clients’ project plan.
Stage 2: System Description and Project Plan Design

Deliverable for this stage: System Description and Project Plan
Having obtained the client’s go-ahead for one of the solutions, the team’s next task is to
produce the detailed system description and a second project plan (project plan for the
client). The detailed system description will be used to develop the solution to the
problem and becomes the team’s system design document. It must be agreed to and
“signed off” by the client before development work on the solution proposal begins.
The client’s project plan describes each of the components (tasks) of your solution,
which team members are responsible for the project’s tasks, how many hours are
required, what must be completed before each component can be started and which
components can be worked on simultaneously. It should include a detailed breakdown of

your system design but only an overview of the testing, documentation training and
implementation plans. Don’t forget to include contingency plans and plans for on-going
support. The deadlines for each component must be included, agreed to and “signed off”
by the client. Penalties may apply for any late completions after the plan has been
accepted.
NOTE: You need to create two Gantt charts. You use one to plan and
monitor the tasks for each member of your team in creating the proposal
documents. This chart is delivered to your supervisor in the two progress
reports and at your End-of-project Review. The second chart explains how
you would develop and roll out your solution for the client and is submitted
as part of your second and third deliverables with the system design. Both
charts should be reviewed and updated as you progress through the
project.
Stage 3: Testing, Training and Implementation Plan Design

Deliverable for this stage: Testing, Training and Implementation Plans
On completing this stage of the project, the team leader presents the proposed detailed
implementation and testing plans to your supervisor and the client. While the GDP does
not require you to actually do this part of the SDLC, you will be required to explain how
you would develop test data to show that the expected results could be achieved. The
team leader should send the plans to the client via e-mail but must include instructions
on how the proposed solution would be installed and tested. This will form part of your
documentation for the next submission.
From its understanding of the client company’s business, the team is required to produce
a detailed implementation plan. Implementation needs to be supported by good quality
documentation, a training plan and training materials. The team will be expected to make
useful and constructive suggestions for the implementation and training processes,
including disaster recovery and contingency plans should there be any problems.
Stage 4: Final Proposal Submission

Deliverable for this stage: Final Proposal
The activities of this final stage of the project include:
 combining the already completed component documents into the final system
proposal document that is properly formatted, paginated, spell-checked, consistent
throughout, provided with suitable headers and footers, and generally well-
presented
 adding a cover page, executive summary and table of contents.
Appendix B contains some advice about how to write a final proposal and the sections
and it should contain.

NOTE: The final proposal document should consist of approximately 65 to

80 pages of 12 point single-spaced text with appropriate headings and
subheadings. Don’t be too concerned about the size of the document, but
if it is too small, you may have omitted something or not provided enough
detail. If it is too large, you may have unintentionally repeated some
sections, put in too much detail or been too verbose in your narrative. In
either case, you run the risk of having marks deducted.
So in summary here is a list of the submissions that must be made as part of the GDP
course:
Day Stage Who What

-10 to -8 Induction Team Members Team Profile
-7 to -1 Induction Team Members Research Report
1 to 15 Stage 1 Team Members Feasibility Study
17 Progress Review Team Leader Mandatory Progress Report
16 to 28 Stage 2 Team Members System Design
30 Progress Review Team Leader Mandatory Progress Report
29 to 48 Stage 3 Team Members Implementation Plan
49 to 53 Stage 4 Team Members Final Proposal
55 End of Project Review Team Leader End of Project Performance
Review
56 Peer Review Team Members Peer Appraisal
Extensions given for any stage will add to the days shown above, so the Team,
Supervisor, and Client will adjust the due dates and timetable for this. Both the Team
and the GDP Supervisor shall endeavour to stick to these timelines and targets since the
skill of time management is an important lesson for students to learn.

TOPIC 4: COMMUNICATION
20 mins
Communication is one of the most important issues you deal with in this course.
Effective communication is the key to ensuring you complete your project satisfactorily.
You will be communicating with a number of audiences:
 your team members

 the client
 your supervisor
 Institute staff members.
Communicating with Team Members

As team members are likely to attend the Institute on different shifts or on different days
of the week, the most practical method of communicating with other members of your
team regularly is to use e-mail. The Windows Live student e-mail system will enable you
to communicate with your fellow teem members. This can be done using an e-mail,
messaging, or by posting discussion comments via the Windows Group page. See
Appendix C for further information on using these tools.
If it can be arranged, your entire team should meet regularly to review progress and
modify activities if necessary to meet the project deadlines. Your team leader should try
to organise meetings so that the entire team can get together at least once a week.
Wherever possible, meeting times and venues should be chosen so that all team
members can attend and participate.
The local Computer Power Plus likely will have a meeting room that you can book and
use to hold your team meetings in. Please ask an Instructor or at Reception if this
service is available at your Institute.
Internet communications tools

If you want to communicate as a team using the Internet, you can do so at the Institute
or from home, an internet café or your local library, by mutual arrangement with the rest
of the team. The Student Windows Live system makes it very easy to do this.
There are several ways you can “talk” to each other at the same time. The Student
Windows Live system includes a messaging tool which you can use as well as e-mail.
This is the recommended method that you use.
Other systems that you could use include a chat room or Paltalk. There are many chat
rooms available on the Internet. For example, you can visit the Yahoo! site and create a
chat room for your team.
Paltalk is a free application that will allow you to communicate verbally with other
members of your team as well as messaging. You will find a free downloadable version
at http://www.paltalk.com/ . To use Paltalk, you will need a sound card installed on your
PC and a headset with a microphone. However, due to the possible disturbance to other
students, we cannot allow Paltalk to be used in the Institutes.

Sharing files
An important tool that is part of the Student Windows Live system that you can use to
provide shared access to files for other members in your team is via the Windows
Groups. During the Induction phase, the GDP Supervisor will create a Windows Live
Group for the team and invite all the team members to join it. The GDP Supervisor will
post all project documents via the Windows Live Group, so it is important that you
regularly use the Windows Live System.
This also will allow all the team members to view, edit, and collaborate on the team’s
project documents. Team documents can be stored in the Documents section of the
Windows Group for your team. This will allow you to use a collaborative workspace
where you can share documents with other members of your team.
You can also store files on Windows Live in your personal Skydrive and can give other
team members permissions to view those files. Windows Live also includes Office Apps
so can use a version of Microsoft Word to view and edit documents via the Internet. You
can also use Office Apps to open and edit any documents in the Documents section of
the Windows Live Group. Information on this can be found in Appendix C.
If your team uses a chat room and a central repository such as Windows Groups for the
files you will be working on, your work on the GDP will be made very much easier. This
will ensure that all team members and your supervisor are able to access files and
communicate easily.
Your supervisor will direct emails to your student e-mail account and to any other
personal email address that you have loaded in SMART, so it is vital that you check your
e-mail regularly. You are not restricted to using your student e-mail account for all GDP
communication, but keep in mind that the team supervisor and the client will use the
Computer Power Student e-mail system to respond to your e-mails and communicate
with your team. The replies will therefore go to the e-mail account from which they
originated. Also, if you change your home or alternate e-mail address, please remember
to advise your GDP supervisor.
Communicating with your Client

Your team will be representing Computer Power to provide a service to the client in the
form of a Systems Proposal document. The Systems Proposal document outlines the
agreed scope of the system that Computer Power will build for the client based on your
discussions with the client. Exactly what role does the client play in the GDP?
The client is the person who has requested the systems development project. The client
pays Computer Power for your team’s development work, and as a result, is effectively
paying your wages. If the client is not happy with your work, another company may win
the contract and you will be out of a job.
Therefore, it is imperative that you understand the client’s needs completely and that you
seek to provide the client with a Systems Proposal document that describes exactly what
the problem is and how your team have agreed to address the problem.
To do this, you need to ask the client a lot of questions. This is the only way that you can
possibly know exactly what the client wants you to do and whether or not the solution
you propose will actually work in the client’s current business environment. Do not rely
entirely on the project briefing notes. They only provide a broad outline of the client’s
problem. Your team will need to ask many questions of the client to get the complete
picture. This should be done via the Team Leader.

At the beginning of a project, a client usually does not understand the full extent of the
information the project team requires. Whereas in the programming courses you may
have done, complete and detailed specifications were provided, the GDP requires you to
gradually produce your own design specifications by asking questions of the client as the
project unfolds.
You must assume that the client knows little about computers, so s/he will be unable to
answer any technical questions. In a work environment, if you need assistance of this
type, you would ask a colleague. For the purposes of this project, look on your
instructors as senior colleagues. They will know no more about the project details than
you do, but they may be able to help you with some problems. You can also ask the
GDP Supervisor for advice.
As you proceed with the development, it is important to keep the client informed of your
progress and to let the client know what you are proposing. S/he will be pleased to know
of your efforts and will be given an opportunity to determine whether you are on the right
path and to provide you with useful additional information.
If you don’t keep the client involved throughout the project, you are likely to make false
assumptions about what is required. Your submissions will then be flawed, will not
achieve very good marks and may need significant amendment before they are
accepted. This is very frustrating and an unnecessary waste of time for all concerned.
Good communication is one of the essential ingredients of a successful project
development.
All communication with your GDP client should be via e-mail through your team leader
and/or supervisor. E-mails to your GDP client should be sent to the appropriate address
shown below:
 Auckland - gdp-client-auck@mail.computerpower.ac.nz
 Wellington - gdp-client-wgtn@mail.computerpower.ac.nz
 Christchurch - gdp-client-chch@mail.computerpower.ac.nz
When you e-mail the client, always enter at least the following in the Subject field
project x, team y, client (where x is the project number and y is your team’s number
assigned by the GDP Supervisor).
NOTE: When you contact the client, either by e-mail or when submitting
reports etc., make sure that you use an appropriate salutation. As your
customer, the client needs to be properly treated and given good service.
Always remember that the client is the person you are trying to satisfy.
Communicating with the GDP Supervisor

The GDP Supervisor assigns students to teams, allocates projects and makes final
decisions on the make-up and assessment of teams. If any unexpected changes in the
availability of individual team members occur during the GDP period, your team leader
must immediately advise your GDP Supervisor.

Your Computer Power supervisor also keeps track of the team’s progress, assesses
your deliverables at each stage of the project and provides general guidance in the
same way that a workplace supervisor would. Any general queries that your team cannot
resolve internally should be promptly addressed to your supervisor. For example, if you
have one small piece of a stage submission completed, you can ask the supervisor to
comment on its suitability.
Your supervisor provides feedback on your performance when the team’s two progress
reports are presented so that you can correct any deficiencies. Your supervisor will also
give you advice about the project deliverables.
Your team leader should forward your team’s reports and deliverables to your supervisor
initially. If the deliverables are of an acceptable standard, your supervisor will require you
to submit the documents to the client for acceptance and/or modification, as would be
the case in a workplace situation.
E-mails to your GDP Supervisor should be sent to the appropriate address shown on
page 1-8.
When you e-mail the supervisor, always enter the following in the subject field: project
x, team y, supervisor (where x is the project number and y is your team’s number
assigned by the GDP Supervisor).
Communicating with other Institute Staff Members

During the GDP, think of your instructors as senior colleagues who may be able to help
with specific questions concerning the operating system or application you have chosen
to solve the problem or for creating your Gantt chart, CPM diagram, or the Data Flow
Diagram. However, your instructors are not familiar with the GDP projects, so they will
be unable to answer specific questions about them.
Because this is a group project, you are expected to consult with other members of your
team when you have questions such as, “How do we solve this part of the problem?”
Your supervisor and/or the client may be able to provide general guidance, but won’t be
able to help with technical parts of the application.
NOTE: Remember - Institute staff members are only a limited source of

help with the GDP beyond acting as “senior colleagues”. They may be able
to provide advice on application program(s) you decide to use and they
may be able to help you with other GDP problems you encounter.

TOPIC 5: ASSESSMENT
20 mins
There are two things to be assessed in this course - the quality of the proposal you
create and the effectiveness of your team’s operation. To assess the first, each of the
deliverables you produce for the client will be marked. The second will be assessed at
three milestones – at the two progress reports and at the final review. Both the client and
your supervisor will award marks for your individual and team performance.
During the project, you will be advised of your on-going achievements as you deliver
each component of your proposal. The final grading of the team and the individuals
within it will occur at the very end of the project, when all the tasks and deliverables have
been completed.
Drafts and Rework

You should submit a draft of each of the team’s deliverables to the supervisor once only
at each stage for comment. The supervisor’s comments may then be used to rework
your deliverable if required. You then submit the stage deliverable for marking to your
supervisor and client as a Word document attached to an e-mail. (Zip up large files
please.) Also include any other supporting documents or files.
When each proposal document is assessed, if one or two criteria are not satisfactory,
(especially if subsequent stages depend on these unsatisfactory items being corrected)
your team will need to fix the problem before your supervisor will allow you to proceed to
the next stage.
Marking–the Role of the Client and the Supervisor

The supervisor and the client mark the stage deliverables from completely different
aspects, so although they both allocate approximately 50% of the marks for every item,
expect the marks awarded by the supervisor and the client to be different. The
supervisor will be marking your submissions for format, presentation, grammar, spelling,
appropriate use of language, inclusion of all required items and so on. The supervisor
will also assign marks at each stage for the teamwork used in developing and producing
the submission. The client will also mark the content for format, presentation, readability,
spelling etc from their perspective, and also such things as its suitability, its user-
friendliness, how well it integrates with any existing systems, ease of use, documentation
quality and so on.
If the supervisor comments that “everything looks fine” with your submission, you may
expect to receive a high mark from the supervisor, but the client will award lower marks if
the submission does not satisfy the client’s needs. To achieve the best result, keep the
client informed of what you are working on during the development process – make sure
you are meeting the client’s requirements.
To get good marks, ensure your team’s proposal documents meet expectations by
referring to the marking schemas loaded into the Documents section for your Windows
Live Group. Also follow the advice given later in this Learning Guide on how to write and
structure your reports.
Your individual performance will be determined by your communication with other team
members, your contribution to the team’s work and the peer review reports that everyone
completes during the final stage of the project – so get involved, contribute and have fun.

Saving and Sending your Submissions

From time to time, submissions get lost, are accidentally destroyed, or are mislaid. Save
each stage deliverable as a single Word document and store it somewhere safe like the
Documents section of your Windows Live Group, then send it to your supervisor and
client as an e-mail attachment. The document should be named:
p<project number>t<team number>stage<stage number>.docx
For example, if you are preparing a report for the Stage 1 submission, you are from team
8 and have been assigned to project 2, you name the document p2t8stage1.docx.
Your Word document should contain the criteria and/or the criteria numbers followed by
your appropriate responses. This will ensure that you address all the required criteria.
For example:
Deliverable 1. Investigate the operation of the current system…

The client’s current system consists of… It is hamster-powered and…
Supervisor’s Team Performance Reviews

Three formal supervisor reviews take place during the project – one after the Stage 1
report has been submitted to the client, another after the Stage 2 report has been
submitted to the client, and the main review at the end (the end-of-project performance
review).
Progress Reports and Reviews

Two days after your stage 1 and stage 2 submissions, mandatory progress reports are to
be made to your Computer Power GDP Supervisor. S/he will need to know what each
member of the team has achieved so far, whether the client is happy with the project
developments, how any difficulties that have arisen are being dealt with, and whether the
project is progressing according to plan.
Documents you will need to submit for review

For these reviews, you send to the supervisor the Gantt chart that you have been
updating as work progresses. The Gantt chart will show what tasks were done by which
team members and the time scale associated with the tasks. See Section 2 for
information about a simple Gantt chart using an Excel Spread sheet. You could also use
Microsoft Project to create the chart.
Grading the progressive performance reviews

The two progressive performance reviews are presented by the team leader and are
graded satisfactory (S) or unsatisfactory (U). These grades do not contribute to your
final mark, but they do influence the marks the Supervisor awards you during the end-of-
project review. Your supervisor will let you know how to correct an unsatisfactory grade.
You can then do what is required to make sure that you and your team receive good
marks in the end-of-project performance review.

End-of-project performance review

Immediately after acceptance of the final proposal, your team presents a performance
report in the same format as the mid-project reviews. The end-of-project performance
review is marked and contributes to your final mark for the GDP.
For this report, send your supervisor the updated Gantt chart that you created when you
started work on the project, and have been maintaining throughout the life of the GDP
course. The Gantt chart will show what tasks were done and by whom of your GDP team
members, and if they were completed on time.
NOTE: The GDP team’s Gantt chart is NOT the same as the Gantt chart
you create for the Client’s project.
The final review also includes a peer appraisal of the other members of your team to
indicate your assessment of the quality of their participation and achievements.
Marking your Team’s Proposal and the Final Review

Table 1-2 shows how many marks are awarded for each component of the course. Both
the client and the supervisor award marks in this course.
Item Client Supervisor

1. Proposal documents
Feasibility study 120 marks (total) 100 marks (total)
System design
Implementation design
Final proposal
2. End-of-project performance review
Team performance 20 marks 30 marks
Individual performance 50 marks
Total: 140 180
Total possible marks: 320
Table 1-2
NOTE: To emphasise the importance of meeting deadlines, marks will be

deducted by both the client and the supervisor for late submissions at
each stage. 2 marks will be deducted for every normal working day that
the submission is late, 1 by the supervisor and 1 by the client.
If your team leader realises that a submission date will not be met, s/he can try to
negotiate a later date with the client. Any extension that may be granted will not exceed
the number of days’ notice the client receives. For example, if the team leader contacts
the client 3 days before the due date, the maximum extension that will be granted is 3
days. If the team leader contacts the client for an extension on the due date, no
extension will be granted.

If a team is awarded 132 marks or more for their submission documents and at least 30
marks for their overall performance, those team members who also receive 30 marks or
more for their individual performances in the End-of-Project performance reviews all
pass the GDP. Any team member who receives less than 30 marks for his/her individual
End-of-Project performance review fails the GDP, even though other team members
have passed. Table 1-3 summarises the marking requirements.
Item Min. pass

%
mark
Proposal documents
Total marks for the 4 stages /220. 132 60
(Client + Supervisor)
End of project review Team performance
Total marks /50. 30 60
(Client + Supervisor)
End of project review Individual Performance
Total marks /50 30 60
(Supervisor + peers)
Table 1-3
Final Grade Calculation

Your final grade for the GDP is determined from the sum of the marks in the three
categories in Table 1-3 expressed as a percentage of 320 and converted to a grade in
the usual manner.
If you fail the GDP, you will need to repeat the course successfully with another team on
another project before you can graduate. Your transcript of results will then include an R
against your GDP grade. If you have failed before on other courses or you fail GDP more
than three times, you may be dis-enrolled.
The GDP Project is an important course and enables you to demonstrate a number of
skills that are important in the workplace, including communication, time management,
cooperation, planning, and document writing and editing, and working in a team. It is
therefore important that you take the GDP course seriously, and put in a good effort, and
regularly communicate with your team in order to be successful.


Group Development Project Section 2: Project Fundamentals
2.0 SECTION 2
PROJECT FUNDAMENTALS
75 mins
OBJECTIVES
1. Define a project
2. List and explain some common project constraints
3. Develop a project overview statement
4. Develop a project workplan
5. Monitor project progress
6. Close a project
TOPICS
1. Definition of a Project
2. Project Constraints
3. Project Overview Statement
4. Development of the Project Workplan
5. Monitoring and Controlling Resources
6. Closing the Project

Section 2: Project Fundamentals Group Development Project
TOPIC 1: DEFINITION OF A PROJECT

5 mins
A project is a sequence of unique, complex, and connected activities having one goal or
purpose, which must be completed by a specific time, within budget, and according to
specification.
The activities in a project are unique in that a project has never happened before and it
will never happen again under the same conditions. Something will always be different
each time the activities of a project are repeated.
The activities in a project are complex, not simple repetitive acts such as mowing the
lawn or loading the delivery truck.
The activities in a project are connected in that there is a logical or technical relationship
between pairs of activities, such as the output of one activity is the input to another.
Projects must have a single goal and a specified completion date.
Projects have resource limits, such as a limited amount of people, money, or machines
that are dedicated to the project.
The client, or the recipient of the project’s deliverables, expects a certain level of
functionality and quality from the project. Although the project manager treats these
expectations as fixed, the reality of the situation is that they can and will change, thereby
presenting special challenges.
There are only three variables that we have any control over when involved in a project
of any kind. They are: the outcome or product of the project, the time frame involved and
the resources employed. A change in any one of these will always have an impact on
the others.

TOPIC 2: PROJECT CONSTRAINTS

10 mins
The five constraints that operate on every project are:
 Scope
 Quality
 Cost
 Time
 Resources.
Scope is a statement that defines the boundaries of the project. It tells not only what will
be done but also what will not be done. The scope document is the foundation of all
project work to follow. In reality, the scope will change throughout the life of the project,
and detecting that change and deciding how to accommodate it in the project plan are
major challenges for the project manager.
Two types of quality are part of every project. The first is product quality, which refers to
the quality of the deliverables to the client of the project. The second type is process
quality, which is the quality of the project management process itself.
The dollar cost is best thought of as the budget that has been established for the
project. Initially, the client may indicate a figure that he or she has in mind for the project.
The project manager prepares a proposal for the projected work that includes an
estimate of the total cost of the project. This allows the client to base his or her go/no-go
decision on a better estimate.
The customer specifies a time or deadline date within which the project must be
completed. To a certain extent, cost and time are inversely related to one another. The
time that a project takes to be completed can be reduced, but cost increases as a result.
Throwing more resources into the project work would cause the increase in cost.
Resources are assets, such as people, equipment, physical facilities or goods, all of
which have limited availability, can be scheduled or can be leased from an outside party.
They are central to the scheduling of project activities and the orderly completion of the
project. Although accountants will tell us that resources can be reduced to dollars, we
deal with them as a separate constraint because they are controllable by the project
manager.
Projects are dynamic systems that must be kept in equilibrium. Figure 2-1 illustrates the
dynamics of the five constraints. The area of the triangle represents the scope and
quality of the project. The sides of the triangle are lines representing time, cost and
resources availability, and these are the boundaries of the scope and the quality.
Changes (increase or decrease) to any one of these constraints will have an impact on
the others, causing an increase or decrease.

COST TIME
SCOPE
&
QUALITY
RESOURCES
Figure 2-1. The Constraints Triangle
The dynamic system is illustrated by the fact that if the area of the triangle (scope,
quality) increases, then an increase must be made to one or more of the sides of the
triangle (time, cost, resources). Similarly, if the area of the triangle remains constant, but
one of the sides is decreased in length, then one or both of the other two sides must be
increased to compensate.
The resources availability, time and cost that are needed to deliver the scope and the
quality of a project are all identified in the project plan, so the project begins in
equilibrium. The sides are long enough to encompass the area generated by the scope
and the quality statements. The reality is that this equilibrium will not last too long.
Change is waiting around the corner to throw the system out of balance. Perhaps the
client wants an additional requirement for a feature that was not envisioned during the
planning sessions. Perhaps market opportunities have changed and it is necessary to
bring forward the delivery date. Perhaps a key team member is no longer available. Any
of these (and many other) changes throws the system out of balance. The project
manager has to control resources utilisation and work schedules, while management
controls cost and resource levels, and the client controls scope, quality and delivery
dates.
A good project management methodology provides a framework, a process, and a set of

guidelines and techniques to greatly increase the odds of being successful. One thing is
sure: if you fail to plan then you plan to fail!
Planning a project involves answering several questions:
 What work is to be completed?

 What conditions will determine that the work has been completed as agreed?
 In what order should the work be completed?
 How long will it take to complete each item of work?
 How can the work be scheduled to meet the requested deadlines?

TOPIC 3: PROJECT OVERVIEW STATEMENT

20 mins
After the feasibility study has been conducted and the client has approved a solution,
then the development of a project plan can begin. The Project Overview Statement
(POS) or Project Charter as it is also known as will contain the project goal, the project
objectives, the risks and assumptions, and a signature page. The POS answers five
basic questions:
 What is the purpose of the project?

 What are the objectives for this project?
 What assumptions and risks are involved?
 How long will it take to achieve the objectives?
 How much is it likely to cost as a ballpark figure?
Establish the Project Goal

A project has one goal that gives purpose and direction to the project. It defines the final
deliverable or outcome of the project so that everyone understands what is to be
accomplished in clear terms. The goal statement will be used as a continual point of
reference for any questions that arise regarding scope or purpose. The goal statement
will be short and to the point, and devoid of technical jargon.
A goal statement should fulfil the following SMART criteria:
 Specific: be specific in targeting an objective.

 Measurable: establish measurable indicators of progress.
 Agreed to: ensure that the client agrees with the goal.
 Realistic: state what can be done realistically with available resources.
 Time-bound: state a time duration estimate for the project.
Define the Project Objectives

The project objectives are derived by identifying specific customer expectations and
requirements, and identifying the customer’s definition of a successful outcome. Think of
the project objectives as a more detailed version of the goal statement. The purpose of
the objectives statement is to clarify the exact boundaries of the goal statement and
define the scope (boundaries) of the project. Every objective must be accomplished in
order to reach the goal and no objective should be superfluous. Avoid the tendency to
include project activities and tasks that extend beyond the boundaries defined by the
project goal (known as scope creep).
An objective statement should contain four parts:
 An outcome. A statement of what is to be accomplished – a deliverable.

 A time frame. The expected completion date.
 A measure. Metrics that will measure success.
 An action. How the objective will be met.

Seven Steps for Avoiding Scope Creep

The expansion of a project outside of the planned objectives is commonly known as
scope creep. Scope creep can originate from several sources and is a leading cause of
project failure when handled poorly. You must take measures to control project
embellishment and to ensure that you and your team don’t fall victim to its unsavoury
results, which are deadline delay and budget shortage.
Fortunately, there are a number of strategies you can follow to keep scope creep from
derailing your projects. Use the following guidelines to control the scope of your project
successfully:
1. Be sure you thoroughly understand the project vision. Communicate with the
project drivers (especially the client) and deliver an overview of the project as a
whole for their review and comments.
2. Understand your priorities and the priorities of the project drivers. Make an ordered
list for your review throughout the project duration. Items should include budget,
deadline, feature delivery, customer and employee satisfaction. You'll use this list
to justify your scheduling decisions once the project has commenced.
3. Define your deliverables and have them approved by the project drivers.
Deliverables should be general descriptions of functionality to be completed during
the project.
4. Break the approved deliverables down into actual work requirements. The
requirements should be as detailed as necessary and can be completed using a
simple spread sheet.
5. Break the project down into milestones and complete a project schedule to be
approved by the project drivers. Milestones should not span more than a month.
Whatever your method for determining task duration, leave room for error. Coming
in under budget and ahead of schedule leaves room for additional enhancements.
6. Once a schedule has been created, assign resources and determine your critical
path using a Work Breakdown Structure or Network Diagram. The Network
Diagram is also known as a CPM (Critical Path method) chart. The critical path
determines which deliverables must be completed on time to avoid an overrun.
7. Expect that there will be scope creep. Implement Change Order forms early and
educate the project drivers on your processes. A Change Order form will allow you
to perform a cost-benefit analysis before scheduling changes requested by the
project drivers.
If you can perform all of these steps immediately, great. However, even if you start with
just a few, those that you are able to implement will bring you that much closer to
avoiding and controlling scope creep. That way, you are in a better position to control
your project instead of your project controlling you.

Feasibility Study
The need for a solution to a problem identified and the deliverables that are needed to
overcome the problem need to be investigated. The client has identified that they have a
problem which a project can solve. Thus the problem must be investigated and
alternative recommendations made on potential solutions that will fix the problem and
achieve the deliverables. These activities and the report are known as a feasibility
study.
Basically a feasibility study involves looking into the problem and reporting back to the
client. The costs and advantages and disadvantages of alternative solutions would be
discussed in the document, and one may be recommended as a potential solution. If one
of the solutions investigated is acceptable to the client and they give approval then the
project will proceed to the next step.
Thus a feasibility study describes the activities involved in investigating a client’s need
for a new system development and examining a number of reasonable solutions. As you
carry out the requirements analysis of their problem and understand the situation and
the needs of stakeholders, a solution will be developed that can meet their requirements
or solve the problem.
Initially, it is difficult to feel comfortable that you’ve decided on the best solution when
completing a feasibility study for a project. However, if you continue communicating and
stay open and honest with your clients, you will be able to change and modify the
solution if necessary. You may find out that you’ve forgotten something, or that the client
didn’t fully understand what you were presenting. By maintaining a good rapport with the
client, you’ll be able to modify the solution before too much time and money has been
wasted and before you’ve reached the point of no return in terms of investment.
During this stage the team is responsible for investigating, identifying and documenting
the needs of the client to highlight exactly what the system solution should achieve. The
business part of the analysis is mainly concerned with determining the business
requirements - the functions the system is required to perform to support the business
processes and activities of the organisation. The system part of the analysis is the tricky
task of converting the business requirements into detailed systems requirements that will
guide what they need to develop to meet the client’s needs.
What needs to be done?

During the investigation of exactly why a client requires a solution (defining the problem),
you will start to get a picture of how much risk is involved with the project, how much
time is involved, what technologies are needed to meet the need, and most importantly,
an understanding of the scale of the development costs.
Much information can be gained at this stage through general enquiries or by research
of similar projects. It is important to gain a number of views on these estimates as this
will generally lead to a better range of estimation than if you undertook the project alone.
Consultation with the client is the most important factor in the development of your
opinion of feasibility, and the client should be aware of how and why you’ve come up
with your opinions as this leads to a smoother final approval process.
When you have identified the levels of risk, time involved, availability of technology and
resources and approximate cost, you can compare your findings with the expectations
held by the client. If the client’s expectations are not aligned with your conclusions, then
the project is not feasible. This is the case when the client’s expectations are significantly
higher than your own, i.e., the client believes there is very little risk, no considerable

outlay, no need for more than one person and the technology is readily available, while
your findings indicate that the risk is high, several people are required, the cost will be
significant and the technology is immature.
Essentially, what you are defining is the scope of the project. Most clients need to adjust
their idea of the scope of a project at this phase, and this is the purpose of the feasibility
study. If you do not have a realistic scope agreed to by the parties involved, the project
is doomed to failure. Managing expectations is the key activity that goes hand in hand
with delivering a feasibility study to the client.
You need to establish the business problem or opportunity before you begin translating
business needs into technical requirements. This will often be documented in the
business requirements section of a feasibility study. This will contain a problem
statement or opportunity statement, and the functional requirements. The functional
requirements describe the way in which the different components and functions in the
solution will interact. The functional requirements will further clarify how the solution is
going to work and how users will use it. You are now taking the functionality and
describing not only how it works, but what has to happen to make it work. The functional
requirements include listing all the database, servers and software systems that are
involved in the process or problem. You need not go into detail at this point, of what
specific components of each of these systems are involved in the process. That will
come later in your technical requirements specification when you do the system design.
NOTE: Refer to Appendix B for a more detailed explanation of the process

of gathering business and functional requirements.
If the business requirements information has not been completed already by the
organisation, you will need to conduct a needs and requirements analysis. All this
information will usually be contained in the feasibility study report.
There are various techniques used to define and refine the project needs such as
interviews with the client, surveys or forms, user discussion groups and questionnaires.
The major purpose of this analysis is to develop an understanding of what is achievable
within the project constraints.
Before gathering requirements, it is important to discuss the business context of the

project with the client. Requirements need to be gathered and managed in relation to the
organisation’s overall vision and strategic goals. They must link to business goals and
objectives. When requirements do not have this linkage, there is a high likelihood that
customers will request features and functions that are not only out-of-scope, but also
promote their own personal viewpoints.
In addition to meeting business objectives, requirements should also work together to

solve business problems. The underlying need for the solution is the focus at this point.
Some questions to ask to uncover this business problem are:
 What is currently limiting you?

 How do you describe need or problem?
 How did you first realise status quo wasn’t good enough?

 What opportunity arose?

 What are you trying to solve?
Initial meetings with the sponsor to discuss the business vision as well as the business
problem(s) can be a helpful way to establish rapport and begin to build trust.
Compiling the business requirements thus involves these four main areas:
1. Clarifying what the business problem is from the viewpoint of all stakeholders.
Establishing the business problem to be solved by the system or project is the first
step. The problem definition may have already been identified in the project brief,
but it needs to be formally documented and have the approval of the client. This
will require interviews, surveys, forms, questionnaires and discussion groups.
The process of requirements analysis may result in a separate business needs

report, especially on large projects. On smaller projects, the needs analysis and
the other information gathered can often be documented with the proposed high
level solution in the one feasibility study document.
The requirements analysis will focus on the current business structure of the
company that is driving this project – the primary business aim or product – and
the IT systems and infrastructure of the company (including PCs, numbers and
locations, details on operating systems, servers, IT policies, networks and
bandwidth capacity).
The focus should be on the root cause of the issues at hand at this point rather
than on the solution. While the solution is important, you need to emphasise that
you understand the underlying causes first, and then address this with your
recommended high level solution later.
2. Identifying the strategic objectives for the business or process.
The business needs that have been identified should align with the strategic
mission of the business; however, often the system for which you are writing the
technical requirements is only a small portion of the total business systems. In this
case you will need to clearly understand the processes and procedures that the
new system will replace or automate.
3. Identifying stakeholders’ business requirements.
Gathering business requirements from stakeholders is a difficult phase.

Requirements are often vague because it is difficult for customers to articulate their
needs before they see the end product. When business customers and the project
team have a relationship built on trust, they can work together more quickly to
produce a product of value to the organisation.
Identify all the stakeholders within the business as well as external stakeholders
who may have an interest in or be affected by the system.
4. Documenting the business problem.
Once you have gathered all the business requirements, this should be
documented in a report. The organisation may have a specific format for this. The
content will also depend upon the nature of the problem. This report will likely

become part of the feasibility study. This basically defines the scope for the
project.
This helps the client understand why the investment is required to address the
business need or problem. It also provides sufficient information to justify whether
or not the organisation should move forward with the development of a feasibility
study.
How do I do the feasibility study?

You do a feasibility study by completing the following steps:
1. Find out what the client wants and why (problem definition and requirements).
2. Create an initial high-level architecture or context model of how things work at the
moment.
3. Start investigative analysis of what needs to change and how the model works in
terms of business processes.
4. Constantly communicate and revise your conclusions on what technologies may

meet the needs of the client, based on their expectation of cost, timeframe,
resources, technology and risk.
5. When you reach an agreed expectation, map out how you intend to make the
solution a reality (a basic project plan) and document it.
The report on your findings under the headings of cost, timeframe, resources,
technology and risk, coupled with your final recommendation of a way forward, complete
the feasibility study.
It’s a very simple process, but it takes a lot of care to ensure that the project is on the
right path.
A template of a feasibility report is given in Figure 2-2.
Feasibility Report
Project Name
<Name you have given for the project>
Client Name
<Name of the client you are developing the system for>
Problem Definition
<A brief description of the problem of the existing system and why the client wants
a new system>
System Requirements
<What the client wants in the new system>

Technical Feasibility and Risk
<State whether you (or your organization) are technically competent to build the
system. This should be addressed under software, hardware, personnel and
expertise.>
<The potential risk of the project outlining the risk factors for the project>
Economic Feasibility
<The approximate cost for the project in detail>
Timeframe
<The time needed to complete the project>
Resources
<Type and amounts of resources required for the project>
Conclusion
<Your final recommendation>
Figure 2-2
List the Assumptions and Risks

What events are taken for granted (assumptions, e.g., the client has enough storage and
network capacity) and what future events might change the environment (risks, e.g., one
of the team members has to withdraw from the project)? These are factors that can
affect the outcome of the project and that must be brought to the attention of
management. These factors can affect deliverables, the ability of the project team to
complete the project as planned, or any other environmental or organisational conditions
that are relevant to the project.
The project manager will document the assumptions and risks to alert management to
any factors that may interfere with the project work. Management may be able to
neutralise their impact. The project manager will include in the project plan whatever
contingencies can help to reduce the probable impact of each risk on the success of the
project.
A Risk Management plan is a good way to document the risks, their probability of
occurrence, and the actions that will be taken if they occur.
Signature Page
This is the formal acceptance or otherwise (GO/NO-GO) for the project to proceed. The
approval process is a deliberate decision on the part of the client that the project
overview as presented does indeed have value and that it is worth proceeding to the
detailed planning phase. Consequently, it may be necessary to have several attempts at
the POS to get it right from the client’s perspective before it is signed off.

The signature page will ask the client to signify that they agree on what is planned, as
outlined in the POS document, and counter-signed by the project manager, and provide
a date for each of the signatures.
By the end of this phase, we should know:
 the purpose of the project

 the objectives for the project
 the assumptions and risks involved
 how long it will take
 how much it is likely to cost as a ballpark figure
 whether or not the project should go ahead.
Once approval for the feasibility study and the POS is given, work can begin on the
system design and implementation plan for the chosen project solution.

TOPIC 4: DEVELOPMENT OF THE PROJECT WORKPLAN

25 mins
When the Project Overview Statement and a solution have been accepted by the client,
a detailed Project Workplan can be created. The workplan answers five basic questions:
 What tasks are to be done to achieve the project objectives?

 How long will it take to complete each task?
 What are the deliverables and the milestones?
 What resources will be allocated to each task and who will be responsible for it?
 In what order should the tasks be scheduled to meet the requested project
deadline?
Creating the Work Breakdown Structure

The Work Breakdown Structure (WBS) defines in step-by-step detail what work is
required to be done to achieve the project’s objectives. The elements of the WBS form a
list of the project’s deliverables, milestones and tasks. It establishes all the project work
that is necessary and is the basis for
 defining resource requirements

 assigning team responsibilities
 developing the project schedule
 developing a budget
 establishing project monitoring and control procedures.
The WBS is developed by listing the major deliverables then listing the sub-deliverables
and tasks for each of the major deliverables and establishing the dependency
relationships between the tasks. Milestones are added after identifying all the tasks. A
milestone is a WBS element with zero duration that marks the completion of a series of
tasks. Milestones are used as reference points in a project to identify the achievement of
key targets.
Each WBS element
 is a discrete task
 has a starting point and duration
 may have a predecessor task on whose completion it is dependent
 has an end product or deliverable
 has one person (or group) responsible for its completion.
The WBS breaks the project down to terminal elements that are manageable and able to
be delegated to a resource. It may help to view the WBS as similar to the contents
section of a learning guide, whereby the sections correspond to the main pieces of work
that need to be done and the topics correspond to the sub-tasks.

Figure 2-3 shows an incomplete WBS for building a shed in your back yard. Some tasks
are missing and some tasks may need to be broken down further, but you can get the
idea of what a WBS should look like.
Figure 2-3. A Work Breakdown Structure
Resources Assignment
The next step in putting together the project workplan is to assign the resources to the
tasks that have been identified and will be scheduled in the Gantt chart. A table like the
Resources Assignment Matrix (RAM) shown in Figure 2-4 is a useful tool for doing this.

WBS Duration Name(s) Equipment Special

Planning
Draw design plans 4 days Mary & Mike CAD skills
Submit plans for app 6 days Boris
Order materials 4 days Beatrice
Site Preparation
Clear and level site 5 days All
Peg out shed 1 day Yuri & Haobi Theodolite Surveying

skills
Excavate trenches 4 days Mary, Beatrice Backhoe Tractor driver
Building Construction
Build Foundations
Pour Concrete 2 days Yuri & Haobi Readymix Concreters
Lay bricks 3 days Mary, Beatrice Concrete mixer Brick layers
Fit out
Install benches 1 day Yuri
Install shelves 1 day Haobi
Hang doors 1 day Mary, Beatrice
Commissioning
Test roller door 1 day Yuri & Haobi Test kit
Obtain certificate 2 days Boris
Celebrate! 3 days Everyone Beer, wine, etc
Figure 2-4. A Resources Assignment Matrix
Constructing a Gantt Chart

The final step in developing a workplan is to construct a Gantt chart. A Gantt chart is a
simple scheduling tool that can be created using a spread sheet. It portrays tasks in
relation to time and resource.
A Gantt chart can be created using a number of tools including Microsoft Excel,
Microsoft Visio, and Microsoft Project.
Figure 2-5 is an example of a partial Gantt chart that has been produced very simply
using an Excel spread sheet and one constructed using Microsoft Visio software.

Figure 2-5. Gantt chart examples
In the Excel Gantt chart, the indicates scheduled dates when work on a particular
task is scheduled to take place. The indicates completed dates on which work
for that the task has been completed. For example, the task Order materials was
completed two days behind schedule but one day less than expected. This did not affect
the following task, Clear and level site, which was able to be started before the previous
task was completed. Although it took one day longer than scheduled, it was still
completed on schedule (18th March) because it started earlier. The task Peg out
boundaries was started and completed one day ahead of schedule but the task
Excavate trenches was completed on schedule. If today is 27th March, then the project is
one day behind schedule.
A dependency relationship may exist between pairs of tasks. The usual dependency is
the Finish-to-Start (FS) dependency. For example, the task Submit plans for approval
cannot be done until its predecessor task, Draw design plans, has been completed. Any
dependency between pairs of tasks will determine the sequencing of the tasks. The
availability of resources is another factor that determines when tasks can be scheduled.
Some tasks can be done simultaneously if resources are available, and thus shorten the
total duration of the project.
In the GDP course, you need to create two Gantt charts, one for the client’s project (the
client’s Gantt chart for designing a system proposal for the client’s problem) and one for
your team’s work (the team’s Gantt chart). The team’s Gantt chart will plot and track your
progress through the GDP course. It will show the summary tasks and sub-tasks that
need to be done, as well as which team member(s) will do them and a time schedule for

these tasks. The team’s Gantt chart will be presented to your supervisor at each of the
progressive performance reviews and at the end-of-project performance review.
The client’s Gantt chart will show the sequence, time and resources for the tasks
associated with the planning, development and implementation of the proposed system
to solve the client’s problem. It will be submitted to the client as a deliverable in each of
the stages. In the first stage, the Gantt chart will be a simple high-level view, but as you
progress through the development of the system proposal, the Gantt chart will become
more detailed until the final version is submitted in Stage 4.
A CPM chart is another management tool for scheduling and monitoring what must be
done to accomplish a project’s objectives on time. The acronym CPM stands for Critical
Path Method. Critical path analysis is used to identify critical tasks in the project. The
critical path is the sequence of tasks that control the completion date. If any one of the
tasks on the critical path is delayed, the final completion date will be delayed by the
same amount unless additional resources are used to accelerate some other task on the
critical path. The CPM chart is frequently also referred to as a Network Diagram.
NOTE: Refer to Appendix A for a more detailed explanation of Gantt and

CPM charts.
System Design and Implementation

In stage 2 and 3 you will be creating a system design and implemantion plans for the
soltuion to the client’s project that has been selected. While your document will not be as
detailed as a real design, there is a lot of information that the team must write. The
marking schema for stages 2 and 3 lists what is required.
In Appendix B you will find guidance on creating system design and implementation
plans.

TOPIC 5: MONITORING AND CONTROLLING PROGRESS

10 mins
When you have completed the WBS, Gantt and RAM, you shift from a planning to a
monitoring mode. To keep things running smoothly, the following must be monitored for
every project:
 status of work being performed compared to the workplan

 quality of work being performed
 costs compared to the plan
 attitudes of project team members and others who are involved with the project,
including clients and supervisors
 cohesiveness and cooperation of team members.
Change Control
It is important to have procedures in place to control any changes that occur during the
life of the project. The tasks and milestones that are documented in the project workplan
form the checkpoints to be used to monitor progress. You will need to update the
schedule as the project progresses and evolves.
If a project falls behind schedule, a decision has to be made to compensate for this
change to keep the overall project on track. This could involve shuffling of resources,
altering the level of effort that was originally planned for a task or changing the sequence
of tasks. If a particular task that is on the critical path is delayed, it makes sense to
borrow resources from other task areas that are not so critical.
Guard against scope creep - the small scope changes that are made to the project
without approval being given. Sometimes a team member can inadvertently introduce
scope creep with good intention. If the client requests scope change, ensure that he/she
formally approves of the scope change and is aware of repercussions that it may have
on the overall project’s schedule and budget.
Progress Reporting
Reports allow your team to communicate to the major stakeholders how well you are
following the project “roadmap” and staying on track. In the GDP course, the major
stakeholders are the project supervisor and the project client. This Learning Guide
specifies the reports that are required at each distinct stage and describes the
corresponding deliverables.
Ensure that reports to the client are proofread, are written in an understandable manner,
appropriately titled, professionally presented with logical formatting of headings, a table
of contents and headers and footers.
Frequent reporting on the team’s progress should be made to the project supervisor.
This can be done by keeping the supervisor in the loop on communication emails
between team members and with the client.

In the GDP course, progress is formally reported to the supervisor on three occasions:
 the Progress Report which is due on day 17 (after the start of the project), two
days after the Investigation and Feasibility Study is delivered to the client
 the Progress Report which is due on day 30 (after the start of the project), two
days after the System Description and Project Plan Design is delivered to the client
 the End-of-project Performance Review, which is due on day 55 (after the start of
the project), two days after the final system proposal is accepted by the client.
For each of these reports, you will need to show your team’s actual achievements
against the scheduled achievements as planned in the Gantt chart for your team’s tasks.
Outside of these three formal reporting occasions, you should promptly report any
variances from the project schedule to the supervisor, particularly negative variances,
before they develop into a major issue.
Project Time Line

The project time scale is largely up to the team. It is easily possible to complete the
project within the number of hours allocated if the workload is shared amongst the team
members. In the past there have been a wide variety of differing time frames
experienced. For example one team completed the project in 3 weeks and 4 days (26
days), while another took just under 13 weeks (90 days). Usually, a full time team will
complete the project within 55 days and its course will typically follow the time-line (Gantt
chart) shown in Figure 2-6.
Figure 2-6. GDP timeline

TOPIC 6: CLOSING THE PROJECT

5 mins
When satisfactory delivery of the desired outcomes has been completed, a formal
closing of the project prevents it from developing into another project and ensures that
the work of the project team is acknowledged.
Final Proposal
The Final proposal report should bring together all the information that you have created
in the first 3 stages. It should be a well formatted, error free, understandable, and an
internally consistent document.
In Appendix B you will find guidance on how to write and structure a project’s final
proposal report.
Client Acceptance
The client decides when the project is done. Ensure that the client acknowledges receipt
of the full suite of the project’s deliverables. The acceptance procedure requires that the
team demonstrate compliance with the client’s performance specification. This should be
done in a formal letter, signed and dated. This is a deliverable in Stage 4 of the GDP
course.
Post-Implementation Audit
The post-implementation audit is an evaluation of the project’s goals and activity
achievement as measured against the project plan, budget, deadlines, deliverables
quality, specifications and client satisfaction. Some of the important questions to be
addressed are:
 Was the project goal achieved?

 Does it do what the project team said it would?
 Does it do what the client expected it to do?
 Was the project work done on time, within budget and according to specification?
 Was the client satisfied with the project results?
 What lessons were learned about project management methodology?
 What worked well? What didn’t?
The answers to these questions are helpful hints and suggestions for your future project
work, either as a project team member or a project team leader.
Celebrate Success
Even though the project team may have started out as a disconnected group, the project
will have honed it into a real team. Bonding has taken place, new friendships have
formed and working relationships have been established. The individual team members
have grown professionally through their association with one another, but now it is time
to move on.
Often, one or two team members will stand out from the rest in their contributions and
efforts. It is OK to recognise these efforts.

Group Development Project Section 3: Working in a Group
3.0 SECTION 3
WORKING IN A GROUP
50 mins
To complete this course, you will be working in a group to accomplish a project. In most
of the courses in your qualification, you work as an individual, setting your own goals
and timeframes. You may find that the other members in your team have a different
approach to you in the way they wish to work toward accomplishing the project tasks.
Understanding the way teams are formed and the way they function best will give you
the background information you need to make key decisions about the way your team
will perform in the weeks ahead.
OBJECTIVES
1. Identify team members and roles

2. Identify and act upon tasks and goals
3. Seek assistance from team members when necessary
4. Give and receive feedback to ensure organisational goals are met
TOPICS
1. Elements of a Group
2. Leadership
3. Group Decision Making
4. Establishing a Strong Team

Section 3: Working in a Group Group Development Project
TOPIC 1: ELEMENTS OF A GROUP

20 mins
Groups and Teams
Is there a difference between a group and a team? Sociologists distinguish between
primary groups in our lives and secondary groups. Primary groups are usually small
groups of people with whom we have an intimate relationship over a long period of time
such as our family, friendship or peer groups. Secondary groups are groups formed for
a specific purpose from people who have no prior contact. Secondary groups can
become primary groups if the group members form a bond while working to achieve the
specific function that sparked the formation of the group.
A team is defined as a small group of people who have a distinct identity and work
together in a coordinated and mutually supportive way. They are accountable to each
other and they use complementary skills to fulfil a common purpose or goal. Most teams
begin as secondary groups, but not all secondary groups are teams. In order to function
as an effective team, groups must agree on processes to decide how they will achieve
appropriate leadership, decision making, communication and task-oriented functions.
Group Roles
Group roles relate to the difference in the functions individuals perform within the group.
Roles may relate to the task functions of the group (the work allocated to the group) or to
the maintenance functions (activities that relate to an effectively functioning group). Five
basic functions relating to task functions and maintenance functions are:
Information management
This role relates to the data collection and information exchange activities within the
group. The group shares information and opinions on the information. A person who
facilitates the circulation and collection of information is working in an information
management role within the group.
Problem analysis
Once information begins accumulating, the group must begin synthesising the data and
applying it to the problems at hand. A person who helps the group to understand the
problem and to define criteria to begin analysing the various options is acting in an
analyst role for the group.
Executive
While the information management and problem analysis roles already discussed
primarily relate to the task related functions of the group, the executive role incorporates
both the task and the maintenance functions. A person who fills the executive function of
the group will work on the development and application of group goals, norms and
procedures.
These functions are similar to a manager role in that people fulfilling the executive roles
also must consider the attitudes and feelings of group members as well as get the job
done. In order to fill this role effectively, group members must display skills and abilities
in all five of these group role functions.

Gate keeping
People who perform the gatekeeper role are aware of the interactions of all group
members. They may invite other group members to comment on a particular task or
issue and keep track of the input from all other members of the group. Successfully
performing this role means that all group members feel included in group processes,
especially in the decision making process.
Climate building
Climate building relates to the generation of positive group morale and a general good
relationship between group members. Two roles are associated with this function. A
person who actively supports other group members and encourages them to participate
when they withdraw and share ideas with other members of the group is called an
encourager.
A second role that is included in this category is that of negotiator when conflict arises
within the group.
Group Norms
Group norms are rules that group members abide by in typical group interactions.
Group values are somewhat determined by the context of the group. For example, it may
not be appropriate to laugh and joke in a formal meeting, but laughing and joking may be
perfectly acceptable in an informal gathering. Generally, groups agree on types of
behaviours that are acceptable and those that are not.
If the group specifically discusses or writes down the behaviours it determines to be

acceptable, explicit group norms have been adopted. This means that all group
members are clear about the type of behaviour that is deemed acceptable and that
deemed to be unacceptable.
Many groups do not formally document or discuss the group norms. In this case, the
norms are implicit and may be clear, unwritten rules or may be ambiguous.
If the group is not functioning very well, it is easy to blame other members of the group
or to decide that the task the group has been set is too difficult to accomplish. On such
occasions, it is worthwhile adopting group norms that can help the group get past these
false barriers. Norms that foster competent group interaction include:
Attending to process
One effective group norm is ensuring that group processes, or how the group will go
about the work to be done, are discussed in addition to the tasks themselves. Being
aware of the way the group functions means thinking about the order of proceedings or
the behaviour of the group.
For example, a group may discuss a particular way of achieving an outcome prior to
determining if the outcome is desirable or even necessary. A group member who made
the observation that a vital stage of the process had been omitted (that of selecting an
agreed option) would be attending to the process of the group.

Other ways of attending to process might be related to:
 participating in meetings at the specified times

 ways of recording or responding to ideas generated in discussions
 decisions about the way meetings will be structured
 the way decisions will be arrived at
 processes for handling disagreements.
Accepting feelings
Over the lifespan of the group, it is likely that group members will experience a range of
emotions such as frustration, anger, excitement, enthusiasm, confusion and anxiety.
Effective groups allow group members to express their feelings because feelings can
affect behaviour. If a group is aware that one member is impatient, they may be able to
agree on a way of speeding up progress without affecting the overall outcome.
Adapting to feedback
The group should consider feedback from both within the group and from external
sources. Internal feedback may entail asking a silent group member for his or her
opinion on a specific matter or paraphrasing opinions voiced by other members to clarify
differences or similarities in thought.
External feedback may entail canvassing opinions regarding the proposed group
direction and collecting input from external sources.
When a group truly adapts to feedback, members do not simply follow the leader’s
opinion or adopt the thoughts of the person who is most dominant. Adapting to feedback
means considering all opinions and taking the time to clarify differences in perception.
Once this has been done, the group re-evaluates group processes, plans and ways of
interacting to incorporate relevant points.
Objectively diagnosing problems

Group problems can originate from both the task and maintenance perspective. Groups
that objectively diagnose problems take into account all of the feedback, feelings and
perceptions of group members with a view to trying to reach a solution that supports the
group rather than just falling into line with a dominant member or trying to ignore the
problem or forcing a certain point of view.
When groups are attempting to objectively diagnose a problem, they focus on “how”
rather than what is considered to be “right” or “wrong”. For example, the following
questions are all aimed at finding a solution to a problem rather than whether or not a
particular person is right or wrong:
 How are we going to work through this?

 How can we resolve our differences?
 How can we change our processes to accommodate that requirement?
 How can we alleviate your frustration with that task?
 How can we find the information we need to resolve this problem?

Sharing responsibility
Shared responsibility is communicated by using “we” rather than “you” or “they”. It
assumes that all group members accept responsibility for the outcome and are willing to
contribute ideas and to encourage other members to participate. When members share
responsibility, each feels that their contribution is worthwhile and listened to by the
others in the group. Each member realises that they are partially responsible for
achieving group goals.
Group Cohesiveness
Group cohesiveness measures the extent to which individual members want to belong to
the group. This includes all of the reasons members may wish to belong to the group
including the degree to which members like each other, share common goals, the
degree to which individual needs correspond to group needs, and the cost to the
individual of leaving the group.

TOPIC 2: LEADERSHIP
5 mins
All groups have leaders–even groups who try to avoid having a leader. Leaders affect
the way other people in the group act. This might be because of their personality or
because of their leadership style. Generally, two types of leadership are acknowledged:
 Instrumental leadership revolves around the process of organising members to

achieve group goals and tasks.
 Expressive leadership refers to the leadership needed to ensure group harmony

and solidarity. Expressive leaders maintain group morale and smooth over
conflicts within the group.
In newly formed groups, the roles of both instrumental leadership and expressive
leadership are allocated to one person. Sociologists have observed that over the
lifespan of the group, these roles quite quickly separate and are allocated to different
people.
Leadership Styles
The way a group leader interacts with group members will differ from group to group
depending on a number of factors including the leader’s personality and leadership style.
Although cultural differences may exist, there are three generally acknowledged
leadership styles in Western societies.
Authoritarian
Authoritarian leaders assume responsibility for all decisions made and give orders to
other members of the group. In some cultures this style is very effective, however, in
Western cultures, authoritarian leadership is usually only effective in emergency
situations (for example, in hospitals or within the military where life or death decisions
need to be made quickly). It is not very effective in less urgent work related situations
because the group begins to focus on conflicts rather than the tasks at hand.
Laissez-Faire
Leaders who adopt this style of leadership are pretty easy-going and tend to make little
or no attempt to organise the group. Although individual members may be empowered to
follow their own thoughts and processes, the groups are usually unsuccessful because
there is no common direction and problems are attacked haphazardly.
Democratic
Democratic leaders try to ensure that all group members have an understanding of the
issues and goals. They try to achieve group consensus on decisions and manage to
achieve a reasonable degree of harmony while working toward the goals of the group.
Democratic leadership is not very effective in emergency situations.

TOPIC 3: GROUP DECISION MAKING

10 mins
If democratic leadership is usually more effective in Western culture, how can groups
make good decisions when individuals within the group have different opinions?
Costs and Benefits of Working in a Group

Firstly, let’s consider if groups make wiser decisions than individuals. To some extent
this depends on the type of task being considered:
 Determinate tasks are those tasks that have only one correct answer, such as
completing a crossword puzzle or where the task is very complex in nature. The
collective range of skills and knowledge within the group is broader than that
attained by any one individual. Therefore, the group is more likely than an
individual to come up with a correct solution.
 Indeterminate tasks are those tasks that have no correct answer such as
deciding among applicants for a job or deciding how to handle a street riot.
Different people may come up with different solutions but there is no right or wrong
way to achieve the task. Depending on the group members and the way the group
functions, the solution may be equal to, better than or worse than that arrived at by
an individual.
Another way of looking at the effectiveness of groups is to consider the input of each
individual to the group in relation to tasks as follows:
 Additive tasks rely on the effort of one group member adding to the effort of
another member. For example, individual efforts at collecting signatures for a
petition can combine to produce an even larger group effort than any single
individual.
 Conjunctive tasks are those tasks where the weakest member of the group limits
the group effort. For example, if acrobats are constructing a human pyramid, the
group effort is limited by the strength of the weakest member of the troupe.
 Disjunctive tasks are those tasks where the limit is established by the strength of
an individual member’s idea. As the group can only work on one idea at a time, for
example, within scientific research, the team will have to decide to research one
theory at a time. The success of the group will be determined by the best idea.
This is similar to indeterminate tasks in that there may be no right or wrong
solution. It is fallible because the group process may not deem the best idea to be
the best.
Decision-Making Processes
Several methods of team decision-making processes can be used to arrive at a group
decision. These include Brainstorming, Multi-voting and the Nominal Group Technique.
Briefly, these techniques can be described as follows:
 Brainstorming
This is a technique used to generate many different options. The general rules of
brainstorming are that a problem is defined, ideas are generated and recorded, but no

evaluation occurs on any of the suggestions. Even improbable ideas should be treated in
this manner. This open and positive environment encourages the development of yet
more ideas based on suggestions previously made.
 Multi-voting
Multi-voting is a system that allows every group member to have a say in deciding
among and prioritising all of the options proposed. If, for example, a brainstorming
session generated 50 ideas, each team member would be permitted five votes. Team
members select their five favoured options, maybe by voting, or maybe by sticking a dot
alongside the option on a board. At the end of the day, the option with the most dots is
the favoured option.
 Nominal Group technique

This five-step process is designed to ensure members of a group feel that they are
participating as equals. It revolves around focusing on ideas rather than people by a
series of processes including silent writing of ideas, round robin reporting of ideas and
discussing each idea in turn. The ideas are voted on, the vote discussed and a second
vote taken.
Obviously, the Group Development Project does not lend itself to some methods of
group decision-making as well as others. You will need to consider the time taken in
each exchange of ideas and work toward the shortest possible time-span for the best
possible results. For example, you may choose to “brainstorm” by simultaneously
circulating as many ideas as you can think of at that particular time. These ideas may or
may not be in relation to a structure or an agenda related to the project. Perhaps multi-
voting is a way the group can determine the relative support for each idea.
The technology you choose to use and the group dynamic you establish via leadership
style and the combination of group roles you choose to use will, to a certain degree,
determine the best way of approaching group decisions.

TOPIC 4: ESTABLISHING A STRONG TEAM

15 mins
To establish a strong team, it is essential that all team members take responsibility in
each of the following areas.
System Influences
A strong understanding of all of the organisational, environmental and political
constraints that affect the group is vital if the group is to set realistic boundaries and
achievable goals.
Goals
All group members must understand the team goals and accept responsibility for their
part in achieving these goals. A strong awareness of the team goals will lead to team
members becoming more involved in process and maintenance along with their
individual task.
Roles
Each team member should understand and respect the roles played by other team
members. The team should acknowledge that it may be necessary for the members to
take on new roles or exchange roles in order to respond adequately to changed
circumstances.
Ground Rules and Procedures

Teams need to agree on ground rules and procedures to ensure that both task and
maintenance work is done. Agenda setting, decision-making, conflict resolution and how
to deal with additional learning needs are some of the areas that need to be considered.
Interpersonal Relationships
Each person must recognise that they are mutually responsible for the group dynamics
and for creating norms that encourage good interaction between team members. This
means supporting other group members and facilitating an environment that encourages
honest and open communication.
Continuous Improvement
All team members should be totally committed to the group and achieving a quality
outcome in line with the requirements of the task and organisational goals.
Ground Rules and Constructive Behaviours for Team Learning

Peter Senge, in his book The Fifth Discipline, outlines the difference between dialogue
and discussion. He argues that discussion is often filled with personal values and that
this restricts the effectiveness of team process. Senge believes that the key to effective
team process is in effective ground rules and quality questions. His ground rules include:
 Suspension of assumptions. If team members cannot avoid assumptions and

find it difficult to move from a point of view they held when the issue was first
raised, then the team is likely to be discussing an issue rather than having a
dialogue.

 Acting as colleagues. There is no acknowledged hierarchy among members

aside from the team leader.
 Spirit of inquiry. Team members should be able to look at the reasons behind
their views in order to try to identify any assumptions they might have made.
Quality Questions
Senge identifies four categories of questions that can be useful:
1. Advocating a point of view

 Make sure your reasoning can be understood so others can understand how
you arrived at your point of view.
 Try to encourage other team members to think about your point of view, for
example, by asking them if they can see any flaws in your reasoning.
 Try to encourage other team members to come up with alternative points of
view.
 Try to understand why other team members have arrived at a conclusion that
differs from your own.
2. Inquiring into other people’s views

 If you have made assumptions about other people’s views, let them know the
assumptions you have made and give them an opportunity to tell you if the
assumptions are correct.
 If you have some data to support your assumptions, state the data source.
 Don’t ask questions if you are not genuinely interested in finding out the
person’s views.
3. When an impasse is reached

 Ask the person if any particular data could change their views.
 Find out if it is possible to work together to find any new perspectives.
4. When others are hesitant to express ideas

 Encourage others to express why it is that they find it difficult to participate.
 Find out if there are any issues that need to be addressed in order to make it
more comfortable for the person to participate.

Group Development Project Section 4: Administration
4.0 SECTION 4
ADMINISTRATION
15 mins
OBJECTIVES
1. Deal with some common group personnel issues

2. Summarise the objectives of the GDP
TOPICS
1. Team Personnel Problems

2. Summary

Section 4: Administration Group Development Project
TOPIC 1: TEAM PERSONNEL PROBLEMS

10 mins
 What happens if for some reason I can’t complete the project or another
person from the team leaves?
If this situation arises, your team leader must advise the supervisor immediately. If the
project has only just started, it may be possible to assign another student as a
replacement. In any case, the project is expected to proceed as originally planned.
Often in the workplace, if a team member cannot complete a project, or drops out of the
team for some reason, it is very unlikely that s/he can be replaced. The remaining
members will be expected to complete the project on time.
In the GDP course, we will therefore expect the same. However, some allowance may
be made, perhaps in the form of a waived penalty for late submission of deliverables.
Such cases will be dealt with appropriately, depending on the prevailing circumstances.
No member of a group will be unfairly disadvantaged by having his/her workload
increased in the event of another group member dropping out.
 What happens if I can’t stand to work with somebody in the team?
You will need to learn to cooperate and work together no matter how much you are
irritated by the other person. Getting along with other people is a most important skill,
one that many employers rate more highly than technical skills. However, if you are
being harassed by another member of the team in violation of our workplace health and
safety policies, you should report the matter to the GDP Supervisor. If the issue is not
satisfactorily resolved, then contact the local Institute Area Manager.
 What happens if somebody in the team is not contributing?
The team leader is responsible for ensuring that everybody has a task(s) and is making
suitable progress. The regular reporting to your supervisor should show how much
progress each team member has made. If it is clear that a team member is intentionally
not contributing, then s/he may be asked to complete another project with another group.
In this case, allowance will be made for one team member dropping out, and the
remaining members of the team will not be disadvantaged.
 What will happen if the team as a whole cannot satisfy the requirements of
their project?
As soon as it is apparent that a team will be unable to achieve a satisfactory result, the
team will be broken up and the project cancelled. Each team member will be allocated to
a new team and will restart the project.
As the composition of the groups and the assignment of projects will be most carefully
determined, we expect this situation to occur very rarely.
 What is to stop us from plagiarising another group’s project?
All project solutions and team correspondence are retained and are checked against
other team’s activities. If it is clear that a team is submitting another’s work, the team will
be broken up and the project cancelled. Each team member will be allocated to a new
group and the incident will be recorded in each team member’s GDP result.

Group Development Project Section 4: Administration
However, the main purpose of the GDP course is for you to work in a team, and the main
factor on which you will be assessed is your participation in the team’s activities. Your
team’s correspondence and your active participation in the team’s activities are just as
important for assessing your performance, not just the sophistication of the project
solution.
 Will I need to do any programming in this course?
No. Your team is not required to produce a working application. However, you may
choose to partially develop the application to prove the concept, or create screen shots.
 What happens if I have completed everything else in my qualification, but my

team has not completed the GDP?
You will need to complete the GDP successfully before you can graduate. However, if
you have completed all your other qualification requirements, you will be issued with an
interim transcript of results to support your resume for job-seeking purposes. While you
are seeking employment, you need to continue working with your team on the GDP until
it has been completed.

Section 4: Administration Group Development Project
TOPIC 2: SUMMARY
5 mins
If you have just read this learning guide for the first time, you may need to read it through
again to fully grasp the function and purpose of the GDP course.
For the first time in your qualification, you are required to work on a project with several
other students as a member of a team. With the GDP, you cannot work just to suit
yourself. Your team colleagues will be relying on you to complete certain tasks to meet
agreed deadlines.
You must also work on GDP tasks while you are on your current course, since the GDP
course is a concurrent course. Being able to manage GDP tasks and your current course
is something that you must learn to handle, because in the workplace managing multiple
tasks is a skill that is expected. Thus time management and being able to change your
focus during any week is something you need to get used to.
Also for the first time in your qualification, your performance will not only be assessed on
your own individual achievement, but also measured on the overall performance of your
team. The team’s performance, in turn, is measured by how well the team functions as a
system development unit, not just by the sophistication of the solution that is proposed.
However, an individual can fail the course if he or she has not participated fully in the
team’s activities or contributed to the team’s achievements.
In today’s IT workplace and in many other arenas, it is becoming increasingly rare for
people to work as individuals in isolation. The team approach is being used more and
more as companies come to recognise its many benefits. The complexities of modern
business solutions demand expertise in many specialist fields. Assembling a team is
often the best way of gathering all the expertise together and providing the focus to
produce an efficient solution. When you start working in the IT industry, you will almost
certainly be required to work in a team, so it is important to have some experience of
what that entails.
The GDP course provides the opportunity for you to develop a valuable skill that is highly
regarded in many industries – the ability to work effectively as a member of a team.
Therefore, you are encouraged to pay particular attention to this course and to work hard
for the success of your team. The result in terms of your job placement prospects will be
well worth the effort.
Because the skills it addresses are so important to prospective employers, make sure
you include your GDP result in your resume. When preparing your portfolio of
documents to present at a job interview, you could include a copy of your team’s GDP
Final Proposal to support your involvement in the project.

Group Development Project Appendix A: Resource Material
A APPENDIX A
RESOURCE MATERIAL
GANTT CHART
There are several techniques for scheduling and controlling tasks. One such technique
is the Gantt chart. The following explains the purpose of the Gantt chart, how to interpret
one and how to construct one.
Purpose of the Gantt chart

The Gantt chart was devised to cope with scheduling problems. It is a graph of output
activities plotted as bars on a time scale. An example of a Gantt chart is shown in Figure
A-1.
Figure A-1
The Gantt chart is basically a bar graph, but not all bar graphs are Gantt charts. The
feature that makes a Gantt chart unique is the fact that the activities are plotted on a time
scale. Bar graphs are broader in scope and are a graphic means of comparing two
variables. Time may or may not be one of the variables. The principal value of a Gantt
chart is its simplicity. It just shows which activities are committed to which dates
depending on a given schedule. No attempt is made to show networks, risks, or
alternative actions.
Reading and Interpreting a Gantt chart

Gantt charts are relatively simple to read and interpret. They require you to look at the
activity and the time required. For example, consider the Gantt chart shown in Figure A-
2.
GDPLGA006a Computer Power Plus A-1

Appendix A: Resource Material Group Development Project
Figure A-2
The activities that need to be accomplished are listed on the left side along the vertical
axis. The time required to accomplish the various activities is located at the bottom of the
graph along the horizontal axis. In the previous diagram, the time is given in weeks; it
could be given in days or months, depending on the scope of a particular project.
The estimated time for completion in Figure A-2 is thirty five weeks. Operators are not
hired until after the programmers are hired and trained. It’s established that it will take six
weeks to write the program.
You can see that there are some activities occurring simultaneously, such as the
programmers and analysts being hired at the same time; the programmers are writing
their program while the DP manager is hiring the operators.
Gantt charts can also be used to determine the total manpower required at any time
during the project if the manpower requirements are known for each activity or task.
Data Flow Diagrams

A Data Flow Diagram (DFD) is a graphical representation of a system. DFDs use
symbols to show how data flows through interconnected processes.
DFDs are best suited for representing system processes at the higher and middle levels
of the systems hierarchy. Other tools are used, such as structured English (pseudo
code), to explain the processes and data on a lower, more detailed level.
DFD Symbols
DFDs use four symbols. One symbol represents environmental elements, the second
processes, the third symbol represents data flow and the fourth the storage of data.
Environmental Elements
Environmental elements exist outside the system. These elements provide the system
with data input and receive data output. No distinction is made between data and
information. The name terminator is used to describe the environmental elements that
are entry or exit points in a system. These terminators can either be people,
organisations or another system and are represented using rectangles as shown in
Figure A-3. Though in real life two terminators can interact, in DFDs it is incorrect to
show an interaction between two terminators.
A-2 Computer Power Plus GDPLGA006a

Figure A-3
Processes
A process is something that converts input into output. Processes could either be
programming code or a set of procedures that need to be followed.
Processes can be represented in one of three symbols as shown in Figure A-4.
Figure A-4
Processes are normally associated with a verb and an object, for example, compute pay.
Data Flows
The flow of data within a system is represented using arrows as shown in Figure A-5.
The amount of data represented by a single data flow can vary from a single data
element to several files.
Figure A-5
Figure A-5 shows a single flow of data (the total profit) that flows from a database to the
manager.
Processes can generate one or more data flows. For example, Figure A-6 shows how a
process can have more than one data output. In this example, the output of the billing
system is stored in the accounts receivable and is also used to generate an invoice:
Figure A-6

Data flows can diverge when the same data travels to different locations as shown in
Figure A-7.
Figure A-7
Data flows can also converge. Figure A-8 shows how identical data flows converge at
one single location:
Figure A-8
Data that can flow in two directions is represented using a double headed arrow as
shown in Figure A-9.
Figure A-9
Alternatively, two separate arrows can be used as shown in Figure A-10.
Figure A-10
Data Storage
Data stores are used to represent data that needs to be stored and are represented as
shown in Figure A-11. Data stores can only be connected to processes. It is incorrect to
connect two data stores directly or to connect a data store to a terminator.

Figure A-11
Example DFD
The process of drawing a DFD is simply one of identifying the processes, linking them
with data flows, identifying the terminators and adding data stores.
The example in Figure A-12 shows a DFD that models how a company determines
commissions for its sales representatives. In process 1, the mail is opened and the sales
order removed. The data from the order is entered into the information processor
(process 2). The sales orders are stored in the sales order form file. In process 3, the
sales order data is sorted in some way. The sorted records are used in process 4 to
prepare a report that goes to the sales manager.
Figure A-12
Leveled DFDs
The previous example illustrated the major process of the sales commission system.
This diagram is known as a Figure 0 diagram. Each process is labelled with a single digit
number as well as its name.
Additional DFDs can be used to summarise the main DFD or provide more detailed
information on each process. A diagram that represents a summary of a system is
known as a context diagram. A diagram that shows extra detail is known as a figure n
diagram.

Context Diagram
The context diagram consists of a single process symbol that represents the entire
system. The example in Figure A-13 shows a context diagram of the sales commission
system:
Figure A-13
A context diagram only contains one process which is not numbered. The diagram
includes all terminators but not the data stores.
Although the context diagram shows the system at the highest level, it is usually best to
begin at a lower level, such as a figure 0 level.
Figure n Diagrams
When it is necessary to include more detail in the DFD, a figure n diagram is used. The n
represents the number of the process. The diagram in Figure A-14 shows a figure 4
diagram for the Compute sales commissions process. In this example, the Compute
sales commissions process has been further sub-divided into two processes, Compute
commission amounts and Accumulate totals.
Figure A-14
The small circle indicates a link with some other process, in this case process 3 shown in
the level 0 DFD. These circles are known as connectors as their task is to connect the
various DFDs.

The term “leveled DFDs” is used to describe the hierarchy of DFDs from the context
diagram to the lowest level figure n diagram.
If you intend to construct figure n diagrams, then each process in the figure 0 diagram
should be numbered.
How much detail should be on a DFD

Figure A-14 illustrates the lowest level that you should attempt to achieve with a DFD.
Any remaining detail is best left to another tool, such as pseudo code. There are two
basic rules that you can use when determining how many levels of DFD to use. One is to
restrict the number of processes on a single DFD to six. The second is to use another
tool to document the lowest level of detail. This should require no more than one page
per process. If this does require more than one page, the DFDs are not adequately
detailed.
DFD Guidelines
In addition to the above rules, you should also keep the following in mind when
designing DFDs:
1. Use unique names for each data flow.
2. Keep data flow names consistent between DFDs. For example, if a certain data
flow has the name “Mail” on the level 0 diagram, then this same name should be
used on any figure n diagram that refers to this same data flow.
3. Show the proper disposition of records deleted from a data store. It is common
practice to archive deleted records in case they are needed at a later date. The
diagram in Figure A-15 shows the proper technique for indicating this.
Figure A-15
4. Don’t include reads and writes in documentation. These are assumed from the
input and output data flows.
5. Avoid read-only processes. If a system only has input with no output, there is a
serious error with the DFD logic.
6. Don’t include requests for data. A request is generally not recognised as data
unless data is included with the request.

CPM Charts
The acronym CPM stands for Critical Path Method. CPM is a widely used method for
Schedule Development. Performing a CPM analysis of a project results in a CPM chart
that shows the sequence of activities that must be completed and how those activities
are related. Though PERT charts are still used they are now considered quite out-dated
and are replaced by CPM charts.
CPM allows you to determine the earliest start date, earliest finish date, latest start date,
latest finish date and float/slack time of each activity. The other main objective of the
CPM is to show the critical path of the project. We will look at each of these elements in
detail.
Creating a CPM
The first step in constructing a CPM chart is to define and list all the activities/tasks
required to complete a project.
After determining the activities of the project, the next step is to assign a duration for
each task. The duration of tasks are estimates (an expert guess) made by the project
manager.
In order to come up with the CPM chart you need to know the tasks, their duration and
their predecessors.
A predecessor tells you which tasks have to be completed before you start a particular
task.
Consider the following table:
Task Predecessors Duration(months)

A - 4
B A 2
C A 3
D B 2
E C 3
F D 1
G E,F 3
Table A-1
Using this information you can draw a precedence diagram. A precedence diagram
shows the tasks and their logical sequence. It also shows you the different paths through
the project to its completion.

Figure A-16
The starting node is the first task of the project. In Figure A-16 it is task A.
The tasks B and C follow task A. Therefore, task A is known as the preceding task for
task B and C. Similarly, task B is the preceding task of D and task C is the preceding
task of E etc.
The tasks which can start or finish at the same time are known as concurring tasks. In
Figure A-16, task B and C are concurrent tasks because they both can start together
after task A is complete.
A task which cannot occur until another task is completed is known as a succeeding
task. In Figure A-16, task B and C are succeeding tasks of task A. Similarly, task D is the
succeeding task B and task E is the succeeding task of task C. This can be applied for
other tasks in the diagram as well.
There are two paths through this project. That is A-B-D-F-G and A-C-E-G.
If you consider the example in Figure A-16, allocating the durations for the tasks you can
determine the longest path to complete the project. The highest value obtained by
adding up the durations of the tasks, through different paths to the completion of the
project gives you the longest path.
In this example the longest path is the path through tasks A-B-D-F-G. It has a total
duration of 13 months.
Forward Pass
Once the tasks, their duration and the order which they occur are determined the next
step is to do the forward pass. This will let you determine early start and the early finish
for all your tasks in the diagram. When you are executing the forward pass, you will be
reading and working on your diagram from left to right.
The early start of a task is the earliest date the task can start. Early finish is the earliest
date you can finish a task.
Using the durations of tasks you can now calculate the early start and early finish for the
project. Early start for task A in Figure A-16 is 0 because that is the first task you do in
the project. Duration of Task A is 4 months, so the early finish for Task A is 4 (months).
The early finish time of Task A is the early start time of Task B and C because they are
the successors of Task A.

The early finish can be calculated using the following formula:
Early finish = Early start + duration
Similarly you can calculate the early start times and the early finish times for all tasks in
the diagram. The calculation must be done from left to right in the diagram until the times
are calculated for the last task.
The calculated values for this example are given below.
Task Predecessors Duration(months) Early start Early finish

A - 4 0 4
B A 2 4 6
C A 3 4 7
D B 2 6 8
E C 3 7 10
F D 1 8 9
G E,F 3 10 13
Table A-2
When you are calculating the early start for the last task, you will come up with two
values for the task G. (i.e. Task E early finish value of 10 and Task F early finish value of
9). When you encounter a situation like this you are required to take the higher value as
the early start for the successor. So in this scenario we will take the value 10 as the early
start time of Task G.
As shown by the calculation of the forward pass, the project will take 13 months to finish.
Backward Pass
The next step is the backward pass. In this step you work on the diagram from right to
left. This allows you to calculate the late start and the late finish for all tasks in your
diagram.
The late start is the latest time you can start the task without delaying the entire project.
The late finish is the latest time you can finish without delaying the entire project.
The last task of the project is Task G. As we calculated in the forward pass the early
finish time for this task is 13 months. This will be the late finish for Task G. Hence the
late finish for Task G is 13 months. You can find the late start for this task by subtracting
the task duration from 13. This gives you the value 10. This is the late start for the
project.
The following formula can be used to calculate the late start for each task:
Late start = Late finish - Duration
The late start for Task G becomes the late finish for its predecessors, Task E and Task
F.

Similarly you can calculate the late start and late finish for all tasks in the diagram. The
calculated values for Figure A-16 example are given below.
Task Duration(months) Late start Late finish

A 4 0 4
B 2 5 7
C 3 4 7
D 2 7 9
E 3 7 10
F 1 9 10
G 3 10 13
Table A-3
When you calculate the late finish for Task A, you will again come up with two values for
it. (i.e. Task B late finish value of 5 and Task C late finish value of 4). When you
encounter a situation like this you are required to take the smaller value as the late finish
for the predecessor. So in this scenario we will take the value 4 as the late finish time of
Task A.
Slack time
The last step is to calculate the slack time for each task in the diagram. The slack time is
the time you can delay an activity without delaying the start of any activity or the entire
project finish time. For example, if a task has a slack time of 3 in our example, this
means that you can wait for 3 months before starting that particular task. This is also
known as the float time of tasks.
You can use the following formulas to calculate the slack time of a task:
Slack time = Late start – Early start
Or
Slack time = Late finish – Early finish
We use the values we calculated in the forward pass and the backward pass to obtain
values for the slack times.
The slack times calculated for the diagram in Figure A-16 using the first formula are
given below.
Task Late Start Early Start Slack time

A 0 0 0
B 5 4 1
C 4 4 0
D 7 6 1
E 7 7 0
F 9 8 1
G 10 10 0
Table A-4

According to the calculations, tasks B, D and F each have a slack time of 1. This means
that all these tasks can wait for 1 month before they start.
You can now construct the CPM chart.
Each task/activity in a CPM chart is represented by a box called a node. Each node has
an activity number/a letter and a name. Apart from that the earliest start date, earliest
finish date, latest start date, latest finish date and slack time of each activity are also
shown in the node. The nodes are arranged in a logical sequence.
Figure A-17
The calculations done so far can be shown in a CPM chart as given in Figure A-18.
Figure A-18
The arrows represent the flow of time from one task to another. All CPM charts are read
from left to right to show the sequence of tasks.
As denoted in the diagram, the arrows show the flow of tasks of the project.
Critical Path
Once the slack times are calculated you can determine the critical path of the project.
The critical path of the project is the longest path of tasks to the end of the project
without delaying the entire project. All tasks in the critical path will have a slack time of 0.
So in other words, the critical path is the path where the tasks have a 0 slack time.
Considering our previous example in the Figure A-18, the critical path for the project is
the path through Task A-Task C- Task E- Task G. This could be shown in the diagram
by bolded arrows.

Figure A-19
Advantages of CPM
1. Plan the allocation of resources.
Consider the example in Figure A-19. Task B has a slack time of 1 month and
Task C has a 0 slack time. This means that after completing Task A we can wait
for one month before we start Task B. But Task C has to be started immediately
because it has a slack time of 0. This means that the valuable resources we are
going to allocate to Task B can now actually be used for another task. Likewise,
you can plan the allocation of resources for your project efficiently using this
method.
2. Focus on important tasks.
Again with the use of the slack times the project manager gains the knowledge
as to which tasks are more critical than the others. So they can focus their
attention on these important tasks to ensure that the project delivery time is not
delayed.
3. Minimise cost.
CPM can be used to calculate the optimal project schedule. This will in turn
minimise the cost for the project. For example, once you figure out which
activities have slack times, the project manager can allocate people from a
completed task to another without hiring additional personnel to complete
different tasks.


Group Development Project Appendix B: System Development Practices
B APPENDIX B
SYSTEM DEVELOPMENT PRACTICES
Systems and System Engineering

The word system occurs regularly in everyday discussion. We hear about PC systems,
air traffic control systems, banking systems, telephone systems, and I am sure you can
think of many other examples. So what is a system?
The Macquarie Dictionary defines a system generally as:
“An assemblage or combination of things or parts forming a complex or unitary whole”.

The IT environment has given system a slightly different meaning:
“An integrated composite that consists of one or more of the processes, hardware,
software, facilities and people, that provides a capability to satisfy a stated need or
objective.”
Using this definition, the concept of a banking system, air traffic control system and
telephone system become more understandable.
Since middle of the twentieth century, the complexity of devices designed and built by
humans has increased by many orders of magnitude. Examples are the aircraft made by
Boeing and Airbus industries, manned and unmanned spacecraft and the Internet. Even
modern cars with their satellite navigation and internal networking systems are technical
wonders compared to their predecessors of only a decade ago.
As the complexity has increased, so has the realisation that a new type of engineering
was required to ensure that all the components of the system work together. During the
last 50 years, a new profession, that of systems engineer, has been created along with a
new type of engineering - systems engineering.
Systems engineering has been defined as:
“The intellectual, academic, and professional discipline the principal concern of which is
the responsibility to ensure that all requirements for a human/hardware/software system
are satisfied throughout the life cycle of the system.”
It is an interdisciplinary field of engineering that focuses on how complex engineering

projects should be designed and managed. Issues such as logistics, the coordination of
different teams, and automatic control of machinery become more difficult when dealing
with large, complex projects. Systems engineering deals with work-processes and tools
to handle such projects, and it overlaps with both technical and human-centered
disciplines such as control engineering and project management.
In short a systems engineer is required to ensure that the components of the system
work together to meet the requirements identified by the client for as long as the client
operates the system.
It is important to understand that modern systems are rarely designed piece by piece.
What is known as a “Whole System” approach is used involving input from many
specialists such as software engineers, network engineers, hardware experts,
psychologists, testers, project managers and end users. Although the system
GDPLGA006a Computer Power Plus B-1

Appendix B: System Development Practices Group Development Project
engineering principles you will learn in this learning guide are primarily focussed on
website and network engineering most of the techniques and methodologies used can
easily be adapted for any type of system engineering project.
Adopting formal processes such as system engineering has become even more vital in
recent years as even mundane devices such as telephones and televisions have come
to have the ability to interconnect to form networks of devices. Without system
engineering the interaction and complexity of the systems these devices form would be
impossible to manage.
Over the past 50 years, there has been much research into understanding why system
development projects or the systems these projects have produced have failed. This
research has provided the basis for defining and standardising the processes and stages
for managing the development of systems. These are known as the System Lifecycle
(SLC) stages and divide the lifecycle of any system up into the following stages cycle as
shown in figure B-1.
Figure B-1
The cycle normally commences at the analysis stage and is seen as an ongoing process
even after a system is in use. The planning stage can involve the creation of a new
system, the replacement of an existing system or the update of an existing system. In
some projects involving new systems, planning will occur before analysis, but in all
cases it is always undertaken when an existing systems lifespan is approaching the end
of the cycle.
For business system or network projects these cycles are captured in the form of
processes called the System Life Cycle Processes. A subset of these, called the System
Development Life Cycle Processes, defines the development and installation of a
system. It divides the project into a series of tasks or processes related to systems’
design and production.
The main object at all of the phases of the cycle is to provide a functional system which
meets the requirements of the user. The user may be an organisation as a whole or an
individual. The requirements normally arise as the user has a business problem which
they would like to solve which may involve hardware, operating system, software, or the
network. This is why you will hear a system, operating system or software package
called a solution.
B-2 Computer Power Plus GDPLGA006a

As an example a company may like the ability to print out invoices to clients. The
problem is that the current system does not do this. System projects are a sequence of
tasks solving these sorts of problems to provide the solution. Good requirements
analysis is the key to this.
The development of reliable complex systems requires considerable attention to detail. It

is very easy to ignore issues early on that may impact at the end of the development
process and cause major problems for the user. As an example, a problem with the
initial user requirements will be magnified as you progress through the development
activities.
Here are some basic definitions for system development:

 Systems engineering provides the skills, methodologies and processes required to
design a complex system and ensure that it meets all requirements. Systems
engineering provides a systematic approach to handling design, development and
operational issues to ensure all the bases are covered in complex systems.
 Network engineering in the context of computer systems provides the skills and
processes used by a Network engineer to design the network (network operating
system and hardware) components of the system.
 Software engineering provides the skills and processes used by a software

engineer to design he software components of the system.
Project Management
Project processes are vital to the smooth running of a system engineering project. Unlike
many of the other activities, Project activities are only involved to get the system
implemented and do not continue once the system is successfully operation because
Project processes view the system as a once off discrete development. How are these
types of activities carried out and when do these types of processes occur during the life
cycle stages of a system? These processes occur during all the stages of the life cycle
or SDLC. The list in table B-1 below shows the project management activities and when
they occur.
Project Management Activity Life Cycle Stage

Establish the process - project definition to set out the scope of Planning and
the software project including the feasibility of the project, Analysis
availability of resources and an adequate time scale for delivery
project planning undertaken by the project manager to determine Design
the effort required to deliver the components, a schedule for the
delivery of components, assignment of responsibilities, the
infrastructure required, the quality system and budgeted costs for
the project
project execution is the management activity to control the Implementation
project and report project status
project review and evaluation is undertaken by the project Maintenance
manager to ensure that the product is developed in accordance
with the plans and meets the requirements
project closure is undertaken by the project manager when the Maintenance
product has met the contractual requirements and been delivered
Table B-1

Once the objectives or the problem of the project has been defined, and a feasibility
study carried out, and the development methodology selected, it is time to start planning
how the project will be undertaken. This is an important part of the development as a
project plan is a major component of the final proposal presented to the client. In fact it is
the major task in preparing the final proposal before implementation begins, since most
of the business and technical analysis work has already been done.
The project manager is the person responsible to management for the development
project. The project manager is usually provided with a team of specialists to carry out
the technical tasks required for the development.
The three main plans that a project manager needs to guide the project are:
 project plan
 configuration management plan
 quality plan.
Project plan
Project managers have three objectives:
1. to develop the deliverables that meet the agreed specification, are fit for the
purpose and meet the quality, reliability and performance objectives
2. to complete the development within the allocated budget
3. to complete the development within the agreed timeframe
To achieve these objectives, the project manager must develop detailed plans of how
the development will be done and what staff are required for the development tasks. The
project manager is rarely given all the required staff or sufficient time for the project, so
s/he must negotiate with the stakeholders to achieve an acceptable outcome for all
concerned.
The project plan is therefore the key document in the project. It allows the project to
move from the planning to implementation. It tells everyone involved where they are,
where they are going to and how they will get there.
Project plan development uses the outputs of other planning processes to produce a
document that can be used to guide both project implementation and project control.
The project plan is used to:
 guide project implementation

 document project assumptions
 document project planning decisions
 facilitate communications among stakeholders
 outline the key management reviews as to their content and timing
 provide a baseline for measurement of progress and project control.
The key issues that the project manager must document in the plan are:
 What is the project supposed to do?

 What are the deliverables?

 Who are the stakeholders?
 What is the proposed schedule?
 What are the roles and authorities?
 How will risks and issues be managed?
 How will tasks be allocated and issued?
 How will the configuration be maintained?
 What are the test criteria and acceptance procedures?
 What quality management system will be used?
 How will any subcontractors be managed?
With an understanding of these issues, the project manager is in a position to write a

project plan that includes:
 project scope - what will be done and what will not be done
 statement of deliverables
 a strategy for developing the deliverables
 an estimate of the effort required to develop the deliverables
 a project schedule of the activities showing their relationship to each other and the
planned delivery dates for the deliverables
 a quality plan stating how the project will develop deliverables that meet the
agreed quality criteria
 a configuration management plan stating how the project will record the
configuration of the deliverables and control the changes
 a budget showing project expenditure over time
 a log of all identified risks with the plans to mitigate the risks
 a log of all issues and a discussion of the implications of each issue
These planning activities are usually written up in a project plan document.
To construct a project plan, follow these steps:
1. Break down the project outcomes into groups of tasks. Break down the work
further into individual tasks. Write your tasks into a task list with headings to show
the related groups of tasks.
2. Identify the major milestones that are associated with tasks. A milestone is a built-
in checklist of a tasks completion. The milestone must be achieved or passed
before the project can move on from that point.
3. Estimate the start and end date for each task, i.e. task duration.
4. Determine task dependencies (tasks that rely on each other or must be done
before other tasks can begin) and draw a line between dependent tasks.
5. Estimate the resources required to complete the project tasks and allocate them to
a staff member.
6. Estimate the costs of the resources and develop a resource budget.
7. Determine quality management tasks and add them to the plan.

8. Determine communication management tasks and add them to the plan.

9. Determine risk management tasks and add them to the plan.
10. Determine procurement tasks and add them to the plan.
There are many different types of project plan documents, but they are all usually
modifications of the format based on the ISO standard for project management.
A typical one based on the standard for a large system development project would have
the Table of Contents shown in Table B-2.
Table of Contents Discussion

Title Page Document Title – “Project plan for …. Project”
Author “………..” Dated “xx/yy/zz”
Document Control This table should list the version, date and
author of the initial document release and all
subsequent changes.
1. Overview of the Project
1.1 Purpose, Scope, and Objectives An overview of what the project has been set
up to accomplish, how it fits with business
objectives and its relationship to other projects.
There should also be a statement of what is
excluded from the project scope.
1.2 Assumptions and Constraints A table of the assumptions and constraints with
which the project manager must work,
including any statements about staffing,
delivery schedules, new technology, links to
other projects, product dependencies and the
impact that these assumptions and constraints
would have if they were invalid.
1.3 Project Deliverables A simple itemised statement of the project
products and the planned delivery dates.
1.4 Schedule and Budget Summary A high level work breakdown structure (WBS)
of the project tasks including support functions
and sub-contracted work with their start and
end dates. The schedule may also be
presented with a GANTT or PERT chart to
show the dependencies between the project
tasks. The budget summary should show the
expected direct and indirect costs for
developing the deliverables with aggregate
expenditures over time (usually budgeted
expenditure by month).
1.5 Evolution of the Plan This section should indicate how the plan will
be maintained, disseminated and controlled.
2. References References to other documents about the
project or the deliverables.
3. Definitions and Acronyms Tables of all critical and interpretable words
with the definitions, acronyms and meanings
required to understand the plan precisely.
4. Project Organisation
4.1 External Interfaces List of all the organisations having interactions
with the project. It usually includes the user
community, operations and support groups.
Other individuals and groups that have an
interest or stake in the deliverables should be
identified.
4.2 Internal Structure A diagram showing the reporting structure of
the team members (organisation chart).

4.3 Roles and Responsibilities A description of the roles of the team members
and their responsibilities. Responsibilities are
generally set out in a matrix showing who is a
participant, providing input, accountable,
reviewing, or signing-off.
5. Managerial Process Plans
5.1 Start-up Plan Description of how the project will be started. It
could include information on how the project
will be estimated, proposed tools, techniques
etc. to be used for the project. It should include
a plan for any training required by the team
members, and the project infrastructure
requirements.
5.2 Work Plan Pointer to a separate planning document which
provides a description of the work breakdown
structure (WBS) tasks, schedule, budget
allocation and resource allocation. This is a live
document that tracks progress against time
and budget.
5.3 Control Plan Description of how the project manager will
monitor and control the project for
requirements, budget, schedule and quality.
5.4 Risk Management Plan Description of the known risks and how they
will be mitigated. It is usual to keep the risks in
a risk log document that can be updated as
required during the life of the project without
reissuing the project plan. Each risk in the risk
log should record what the risk is, who
identified it, when it was identified and the
mitigation strategy. The project plan should
contain a pointer to the risk log.
5.5 Closeout Plan Description of how the project will be shut
down. What archiving is required, and how any
lessons learned can be passed on to other
projects. The company may require a formal
analysis of the project performance against the
initial statements for deliverables, schedule,
cost and quality.
6. Technical Process Plans
6.1 Process Model Description of the development methodology
for the project.
6.2 Methods, Tools, and Techniques Brief description of any new or unusual
methods or tools that will be used to develop
the deliverables.
6.3 Infrastructure Plan Description of the infrastructure that must be
set up to support the project team.
6.4 Acceptance Plan Description of how the client will test the project
deliverables, the criteria for acceptance and
who is responsible. This may be a separate
planning document with a pointer to it in the
project plan.
6.5 Deployment Plan Description of how the system will be
integrated into the operational environment and
how the user community will be trained in the
use of the system. This may be a separate
planning document with a pointer to it in the
project plan.
7. Supporting Process Plans
7.1 Configuration Management Plan Description of how the project team will
identify, manage, audit and release system and
documentation components during

development, testing and at deployment. This

may be a separate document with a pointer to
it in the project plan.
7.2 Product Testing and Reviews Plan Description of how the system design will be
inspected for conformance to the user
requirements and the resulting system tested
for conformance to the design. This plan
should cover how each type of deliverable will
be tested and who is responsible for each
element of the testing processes. This will
normally be a separate document with a
pointer to it in the project plan.
7.3 Documentation and Work Product Plan Description of what deliverable and non-
deliverable documentation will be developed,
how it will be developed and who is responsible
for each element of the process.
7.4 Quality Assurance Plan Description of how the project will use the
organisation’s quality management system to
provide assurance that quality issues covering
adherence to plans, standards and processes
will be addressed during the project.
7.5 Project Reviews State how performance and technical reviews
of the project will be carried out and indicate
the schedule for these reviews.
7.6 Issue Management Description of how issues that arise during the
life of the project will be managed. This is
usually a separate issues log document with a
description of each issue, a discussion of the
implications and the management action to
resolve the issue.
7.7 Subcontract Management (Acquisition Description of how the acquisition of any
Management) Plan purchased components will be managed. This
includes the identification of potential vendors,
criteria for vendor selection, vendor contract
management, quality assurance for the
purchased components etc.
7.8 Process Improvement Plan Description of how the project team will review
their development process and use the lessons
learned to improve the development process.
Table B-2
This project plan table of contents is too comprehensive for all but the largest system
development projects, and many of the topics are predetermined by the organisation
hosting the project. However, it forms a good checklist of issues that must be addressed
by the project manager.
Since each client organisation may have its own standards for documentation and
reports, you will need to find out what these are. An organisation may have policies on
such things as the layout, format, and style to be used in any of its documents. This
information would normally be found in a ‘style guide’. Organisations may also have
standard templates for producing their technical documentation such as project plans.
If the organisation does not have any document standards or project plan standards, you
can use existing standards that the IT industry uses, examine a number of good
examples from other companies, or use your own.
The project plan is a “living” document, which will be revised during the life of the project.

Writing Plan Content

The project plan needs to be clear and easily comprehensible because those who will
use the plan will be project managers and members of the project steering committee,
who are not necessarily IT specialists.
While the project plan is the responsibility of the project manager, the Systems Architect
and other IT professionals on the project team will have input and contribute to parts of
the project plan.
Many technicians develop the bad habit of using overly-specialist terms or jargon that no
one else understands. While some terms are needed, jargon can hide the true meaning
and make technical writing less understandable. While specialist terms are necessary,
plain English makes technical writing easier to read, and glossaries can help explain
terms. Unexplained terms or overuse of jargon is a common fault of technical writing.
Good technical documentation clearly conveys its subject matter without errors or
ambiguity and by being easily and quickly understandable is easily usable by readers.
Up-to-date and complete technical documentation can save hours of later questioning.
Typical features of a well-structured and well-written document include:
 Content Listing - shows the user at a glance the overall contents and structure of
the document.
 Accurate – the document should contain factual and correct information.
 Organised - it should include headings, subheadings, indexes and table of
contents, glossaries etc. The language should also be clear and without
unexplained jargon.
 Clear - it should be easily understood by the intended audience.
 Concise - it should contain only relevant information.
 Complete - it should address all required aspects, and it should have all
information on the subject.
 Consistent - it must be consistent in the manner of style, format and presentation,
including in the use of terms and spellings etc.
 Objective - The text should be impartial and not introduce personal opinions.
Further guidance about how to write good technical documents can be found here:
http://www.hci.com.au/hcisite2/products/HCi%20Style%20Guide.pdf
The project plan and the final proposal should be a well-written and clear document and
demonstrate the features of good writing mentioned above.
Document Control
In order to ensure the quality and consistency of documents, clear and efficient
procedures must be in place to handle version control, change control, document
updating and distribution, as the project progresses. Therefore the design of any
technical document such as the project plan should allow for control of the quality of the
work, and for future changes, via a versioning system.

From the very start, design your documentation to allow for updating when necessary,
control of changes, and review. Good documentation is enforced through revision control
and checking of the documents by a third party. Copies will be made of your document,
and copies of copies, so using a good version numbering system will ensure only the
latest one is being used.
Can your organisation say where its documents are? Can it control changes that might
need to be made by the document’s users? If the document you designed is revised, is
there a clear procedure for withdrawing or destroying all superseded versions?
Procedures and instructions need to be maintained so only designated people can make
revisions. Without proper control of documents, this will be a difficult requirement to
meet.
If there is good document control, then the latest project plan will be an up-to-date,
accurate, and relevant document.
Work Breakdown Structure
A very important part of the plan that needs further explanation is the work breakdown
structure (WBS). Of the many methods available to define the activity and tasks that
make up a project, the one that is most used and easiest to understand is the work
breakdown structure (WBS).
The WBS is a useful tool for breaking down a lot of work into manageable pieces.
Because most projects involve many people and many different deliverables, it is
important to organise and divide the work into logical groupings based on how the work
will be performed.
Using this method, we represent the objectives, tasks, subtasks and work packages
using a hierarchical tree showing all the levels of breakdown. The top branch represents
the goal of the project and the bottom branches represent the individual work activities to
be performed.
A WBS can thus be represented in one of two ways:
 a graphical diagram very similar to an organisational chart of a company.

 a hierarchical listing like a table of contents in the front of a book or report.
The most common method used when breaking down projects into tasks and then work
packages is the top down approach.
The following are the five steps of the top down approach:
 Step 1 – divide the project into its major objectives.

 Step 2 – divide each objective into the tasks that must be done in order to
accomplish the objective.
 Step 3 – check that each task that must be done has all of the required
characteristics listed above. If it has one or more missing characteristics, then
divide the task into subtasks.
 Step 4 – repeat Step 3 until all subtasks have the required characteristics.
 Step 5 – make the lowest level of subtasks in the WBS hierarchy the basis for the
work packages that must be done to complete the project.

In smaller projects a bottom up approach is more suitable. This is where all the basic
tasks are determined; then they are grouped into linked tasks and then into stages.
An example template for a WBS listing is shown in Table B-3.
ID Task Duration Predecesso Start Finish Resources Costs

rs
Record here How What is the How early How What What are the
the required long relationship can each late can physical total costs to
tasks, will the (dependency) task start? each and/or complete
milestones, task(s) between each task human each task?
checkpoints, take? task and/or finish? resources
stages or milestone? are
headings. required
(must be
allocated)?
Table B-3
There are many software tools to assist in creating and managing the WBS. Microsoft
Project is one such software application. It has the flexibility to display a wide range of
project information in the WBS including relationships between tasks (predecessor
column), start and finish dates, durations and the cost of completing the tasks (fixed and
variable).
Project Effort Estimation

Effort estimation is a part of the project planning process. Without effort estimates, the
project manager is unable to establish a development schedule. The estimation process
has been studied extensively and there are many documented estimation techniques
available.
The only way to improve your estimation process is to use a variant of the classic quality
improvement process cycle. The cycle is - make the estimates, execute the project
collecting the project metrics, compare the estimates with the actual effort, learn from the
comparison and adjust the next estimation process in the light of the new understanding.
The starting point for all the estimation techniques is a detailed list of all the known tasks
in the project.
The simplest technique is the Expert Guess. For this technique, an expert who has
experience with similar applications, languages and tools estimates the effort for each
task. This approach works reasonably well provided the expert has good prior
experience and the tasks are all less than 5 effort days. The estimator provides an
estimate of the most optimistic effort, best guess effort and pessimistic effort for each
task along with a high, medium or low risk evaluation for the task. The best guess
estimate can then be adjusted in the light of the risk evaluation. If you can find more
than one expert estimator, the whole procedure can be repeated and the results
compared. This forms the basis of the next technique.
In practical terms, to apply the selected development methodology to an IT project, effort

estimation is usually done using a simple guessing technique based on experience with
input from members of the team. We will consider this method next.

Estimating task duration
Once the Work Breakdown Structure is completed, we have all of the tasks required to
complete the project. But we must use the Work Breakdown Structure to estimate the
work effort or time for each task, and the cost for each task.
When estimating task work effort, there are five options that you can use to gather
information to help you make the estimates:
 Ask the people who will actually do the work because they have the experience.
 Get an expert’s opinion. (For example, someone who isn’t working on the project.)
 Use an identical or similar task in a completed project as a guideline.
 If you have time and it is possible perform a test task.
 If all else fails, make your best guess.
In most cases the work effort, or time, to complete a task will vary if it is repeated over
and over again. This is true for even simple routine activities. For some tasks, the
variation may be small and for others it may be considerably large. You cannot predict
when these variants will occur and affect a project.
However, you could use a weighted average formula that takes variations of time
estimations into consideration. If the task that you are estimating has a proven well-
known completion time, then you will not need to use this weighted average. Having a
single estimate based on the established time should be sufficient.
One of the major reasons why poor estimating occurs is that there is usually a difference
between the work effort hours, and the elapsed or calendar duration required to
complete a task.
For example, a task that you estimated at four hours’ work effort might have to be
scheduled in two–hour slots over two days. Therefore, the elapsed duration for the task
is two days. Since we usually schedule projects in elapsed or calendar days, we must
take into account the distinction between work effort and elapsed duration when we
develop project schedules.
Some reasons for the difference between actual work effort and elapsed duration include
the following:
 weekends and public holidays

 coaching other team members
 non–project administration and meetings
 interruptions such as phone calls
 switch time, eg the time required to switch between tasks.
It is not unusual for these factors to account for 30–50% of an elapsed day. Therefore, it
is acceptable to find a work effort of one day taking an elapsed duration of two or three
days, depending on the particular project.

Risk Management
The project manager has to understand what the risks are at the start of the project and
continue to look for new risks during the life of the project. Much effort has been spent
recording interesting risks for all sorts of projects. However, there are a number of risks
that occur over and over again, and this makes them worthy of noting:
 imprecise requirements from the users

 idealistic requirements that exceed the user’s needs
 lack of staff
 unrealistic delivery schedules
 pushing the bounds of current technology
 controlling requirements creep
 problems with reusable components
 shortfalls in performance by staff and subcontractors
 product response time issues.
There are essentially five ways to manage risk. They are:
 avoid the risk when defining the project plan

 control the risk by close monitoring so that corrective action can be taken quickly
 assume conditions that avoid the risk and provide a mechanism for changing the
project plan if the assumption is wrong
 transfer the risk to the purchaser through the contract
 research the risk to reduce the probability of it occurring.
Cost Management
Cost management is a significant component of the project manager’s responsibilities.
But costing a project is not an easy task. All projects are different and therefore you may
not have a previous example to assist in costing the current project.
During the planning stage, the project manager is responsible for developing the initial
budget for the project, based on a best guess of the labour estimates and other costs.
They may refer to audit reports and budgets from previous projects, but these may only
provide ideas, rather than real costs. The estimate is usually termed the rough order of
magnitude (ROM) estimate with an accuracy of –25% to +75%. This estimate is used as
part of the feasibility study for assessing the viability of the project with a horizon of 3 to
5 years. The budgetary estimate is made closer to the start of the project and has an
accuracy of –10% to +25%. These estimates may be accompanied by a net present
value (NPV) analysis or an internal rate of return (IRR) analysis to demonstrate the
financial viability of the project.
The definitive estimate of costs is made at the start of the project and is based on actual
purchase costs for equipment and the project effort estimates. One of the key inputs to
this costing process is the detailed Work Breakdown Structure that is developed at the
start of the planning stages of the project life cycle.
There are usually four major cost areas that are involved in any task. They are:

 labour costs
 material costs
 other direct costs (travel, telephone, contracted services)
 indirect costs (company overheads, depreciation, etc)
These items are determined as part of the resource planning process based on the
work that must be carried out from the WBS.
Note: Resource planning is determining what physical resources such

as people, equipment, and materials are needed and in what quantity
they are required to complete the project. These are usually determined
on an individual WBS task level.
When you have added up all of the costs for all tasks and activities, you have a final cost
estimate for the project. This is usually presented to the project sponsor and
stakeholders that will be providing the funds and becomes the budget in the final
proposal.
The accuracy of this estimate should be –5% to +10%. It is exceptionally difficult to carry
out a system development project with this level of accuracy. The academic studies of
completed projects show that for large projects, about one third of all the projects
examined overran the budget by 150% to 200% and had time overruns of 200% to
300%. For this reason, it is important for the project manager to include a management
contingency or reserve in the budget (which is usually 10%).
During the project start up, it is important for the project manager to apportion the budget
against the project deliverables and then track the effort and expenses against each
deliverable.
The project manager will need a time recording process to record the effort against each
element of the work breakdown structure so that the % complete can be reported on the
GANTT chart. A simple accounting system will allow the effort and the expenses to be
accumulated and tracked against the project budget.
During project close down, the project manager may be asked to complete a financial
analysis of the project comparing the actual expenditure with the budget.
Configuration Management
Configuration management provides change control. It provides the tools to resolve
development problems that can arise when the user requirements change during the
project and manages change during the maintenance. A configuration management
system should be able to provide answers to questions such as:
 How many versions of the software or hardware or components are there?

 What changes were made to version x to create version y?
 What changes are outstanding for version x of the system?
 What notified faults have been fixed in the current release?
 What notified faults remain to be fixed in the current release?

 What are the version numbers of the software components in version x of the
system?
The discipline of configuration management is equally applicable to managing software,

hardware configurations, infrastructure, documentation and training materials.
Configuration activities include:
 recording the identification of each component

 controlling all changes
 configuration status accounting
 providing a method for evaluating a configuration and verifying that a particular
build contains all the required components with the correct version numbers
 providing a method for building a release containing all the components for
delivery to the operational environment
IT Projects
Now that you are aware of the system life cycle, we need to consider system
development projects in the context of the IT department.
A project can be described as:
A temporary endeavour undertaken by a team to create a unique product or service.
Temporary means that every project has definite start and end times. It is unique
because the project is not a manufacturing process producing many copies of the same
product, but rather a process to develop a particular product or deliver a specialised
service.
It is difficult to generalise on the organisational structures adopted by companies to

handle the definition, development and operation of a system. However, there are three
basic models:
1. Model A – Self sufficiency
In this business mode, the company funds an IT department that can deliver all the
system life cycle processes. The department can define, develop and operate the
company’s business applications and IT hardware. System development projects are
undertaken within this department.
2. Model B – Commercial off-the-shelf user
In this business model, the company recognises that most, if not all, of the required
business processes are the same as those needed by other organisations, and they
purchase commercial software or systems off-the-shelf. Their IT departments are able to
define requirements and operate the applications and\or hardware. They have a small
development capability that is responsible for customising the purchased applications to
the company requirements.
2. Model C – Outsourced
In this business model, the organisation has decided to concentrate on their core
business and contract out all their IT-related tasks. Their IT department will have a few

specialists who define high level needs and manage the contract. An outside
organisation provides all the staff and management expertise for the life cycle
processes.
The self sufficiency model was the traditional way companies operated. However, the
trend over the past 20 years has been to use commercial off-the-shelf software or
externally developed systems wherever possible (especially in medium to large
organisations), and to use systems developed in house only to satisfy unique business
requirements. This has seen the rise of two types of IT development companies: one
that specialises in developing generic systems that can be customised to suit a wide
variety of businesses, and IT systems consulting companies that specialise in the
development of unique systems for clients.
The outsourcing model has been adopted by some government departments and large
companies who believe that it is more cost effective to contract out the IT requirements
to a specialist IT company than to invest in an in house IT department.
Irrespective of the type of IT organisation, most systems and software are developed
within existing IT organisations that have well defined management structures for the life
cycle processes. Generally, system development project teams are created after the
need has been established and the management has allocated a budget for the
development.
What is a requirement?
After a feasibility study has been given approval, the next step in the preliminary stages
of a system development project is to develop a set of technical and system
requirements. This is a critical step in the project that will determine both the result of
development efforts and the success and acceptance of the final product. The more time
spent in this step getting these requirements right, the less time will be spent in
construction and testing steps redeveloping the system and rewriting code.
The more you know about what the client is trying to achieve, the better you will be able
to tailor a solution to meet their needs. Most clients will need to spend considerable time
talking about what they want. You will not be able to get a clear understanding of what
the client technical needs are in the first conversation you have with them. Generally,
this takes a number of meetings and discussions, and you must be flexible and willing to
adapt and change your emerging vision of what the system needs to do. The only sure
thing about requirements is that they change rapidly in the preliminary stages of the
project.
It is most important to spend this time with the client in the preliminary phase. It should
be included in the initial basic project timeframe, which should also allow for making the
changes that are certain to be required before you commit to an expensive path of
system redevelopment.
This step involves identifying the technical requirements. Once you understand this
various products can be investigated and a solution can be developed.
Who is involved?
As well as the client, who is the key player in this step, other stakeholders may be
important here as well, such as:
 IT support groups

 communications and other marketing groups

 groups who own software or hardware that needs to be interfaced or integrated
with your project’s system, e.g., corporate systems people responsible for financial
and/or annual reports etc
 your client’s customers or clients who may be affected by the change
 privacy and legislative groups
 people with specific needs, e.g., people with a disability or language barrier
 any other group or individual who may have an influence on the acceptability of the
product either directly or indirectly, e.g., unions or client staff groups.
To get the most accurate picture in the shortest time possible of what the system should
deliver, you need to get a broad sample of perspectives from as many groups of
stakeholders as you can. Sometimes the client will restrict the people with whom you will
talk for political or other reasons, and you must respect those decisions. However, it is
important that the client understands that the wider your audience, the greater the
opportunity for improvements in service and process to become evident. As in all
statistical activities, the wider the sample, the closer you are to the real answer.
A requirement is something that the system must be able to do or supply – an output or

a function. Some requirements are mandatory and some are desirable to have in a
system.
An example of a mandatory requirement is:
It is mandatory that the user interface includes access control mechanisms to restrict
entry to authorised users.
An example of a desirable requirement is:
It is desirable that the monthly performance management reports display statistical

information using graphical bar and pie charts.
Gathering Technical Requirements

Requirements can be categorised and viewed in a number of ways and this will influence
how you gather and record them. Let’s consider one way of categorising and analysing
the requirements.
An item of data, functionality, and process or system capability to be included in system

design either as a mandatory or a desirable component are all categories of
requirements. When you are gathering requirements this way, you will need to cover at
least the four areas listed to produce a complete set of requirements.
Requirement statements that are concerned with functionality of the system are system
requirements. Below are two examples of business requirements:
It is mandatory that the system only permits a customer’s personal information to be

viewed and modified by the customer or a delegate authorised by the customer.
It is desirable that customer purchase trends be made available to marketing staff for
promotion purposes.

These two requirements could be the same as the two stated previously as mandatory
and desirable requirements, except that they are not specifications of system
functionality. They are descriptions of what the functionality needs to do to support a
business process or policy. It is a subtle difference, but very important when creating
systems that utilise workflow or business rules to improve business productivity, which is
currently true of the majority of systems. It is the difference between what you implement
and how you implement it and, as a business or systems analyst, you need to be able to
distinguish the two.
There are many kinds of requirements (to be classified into desirable and mandatory),
some of which are data, process, functionality and system capability.
A data requirement could be something like this:
It is desirable that the software captures personal information, including name, address,
age, sex, and country of birth.
This requirement tells us a number of things about how the system has to work. There
needs to be:
 a data capture screen in the user interface to allow for capture of the data items
 verification that the data is correct
 a database to store the data
 a record or table in the database that links name, address, age, sex and country of
birth instances to a particular user identifier.
Part of the data requirements analysis is modelling how the data items interact with each
other. The data model is an important tool to assist in evaluation of your data
requirements. Some tools to assist in data modelling and data interchange include:
 Data Flow Diagrams (DFD)

 Unified Modelling Language (UML)
 Entity Relationship Diagrams (ERD)
 Electronic Data Interchange (EDI)
 Extendable Mark-up Language (XML).
Data Modelling is a separate subject that requires more treatment than can be given in a
short course such as this one, but to give you an introduction we will look at the basics of
one data modelling technique, data flow diagrams.
Two examples of process requirements are:
It is mandatory that the software enforces authorisation of procurement orders by the

user’s nominated supervisor before sending the order to the supplier.
It is desirable that a notification of late submission of assignments be sent to the

student’s tutor.
These requirement statements are concerned with timing and step by step processes.
This can also be called workflow or the flow created by the system through which work
must pass to reach completion. Process requirements go hand in hand with data
requirements. You will generally see how data passes through a system by examining

the processes and decisions made in business practice, and you can take advantage of
streamlining opportunities by spotting dead ends where data is being captured but not
passed throughout the system by a process.
The final requirement is the system capability. This requirement is concerned with such
things as system size and performance, load balancing and other more technical or
infrastructure components of the system. Two examples are:
It is mandatory that the software permits multiple user access to information stored in the
database.
It is strongly desirable that the software be available 24*7*365.
The first example says that the system must be designed to handle any number of users
accessing the database at any one time. This means the database should have some
locking features and other standard functionality to support multiple record update.
The second example says that the system should be available 24 hours a day, 7 days a
week, 365 days a year. This has an impact on the design for robustness, backup
arrangements and maintenance scheduling. Notice the use of the words “strongly
desirable”. You could implement a system without this feature or capability, but the client
would much prefer to have it included. Why is this sort of distinction important? For two
reasons:
1. Timeframe – determining what is of highest priority to deliver should the project

run out of time
2. Evaluation – if you are responsible for choosing an off-the-shelf solution that will
meet the client’s requirements, you need to be able to rank short-listed contenders
against their ability to meet requirements.
In these situations, the decision may be determined by which vendor can provide a
system that does support 24*7*365 and which vendor can’t.
A good time to stop determining requirements is when you’ve met the following
evaluation criteria:
 Comprehensiveness – you’ve covered all the known bases

 Non redundancy – not saying the same thing more than once
 Enforcement of desired business practice
 Re-useability – language is generic enough for the system to be useable across
the organisation or in many development processes
 Stability and Flexibility – minor changes in business practice or system platform
will not affect the requirements description. They are stable and flexible enough to
last as a description of the business for several years regardless of changes in the
business.
 Simplicity and Elegance – clear, concise and consistent
 Communication Effectiveness – having descriptions that communicate to
someone who is unfamiliar with the project, exactly what the client wanted to
achieve.

How do I write a requirements specification document?

Whichever of the different ways to gather the requirements you have used, these must
now be complied into a requirements document which will be contained eventually in the
feasibility study and the final proposal.
There are many different ways of writing the requirements specification document
depending on the style of the organisation for which you work. This makes it difficult to
present any one correct way of documenting requirements. However, there are a few
common themes that you need to incorporate to ensure the document is complete.
Before we get to the final product, let’s take a step back and look at the actual process of
collecting requirements.
Whenever you are talking to a stakeholder, from the first moment to the last, take
copious notes. These notes should include any statements on problems, wants, ideas,
political imperatives, money, risk, wishes, timeframe, resources, location, and any other
similar indicator that may influence the ability of a solution to deliver successfully.
Also when you analyse any of the existing systems involved in the desired system or
problem, you should also be documenting everything you find.
Use these notes when you start writing the requirements specification document. They
will indicate the full breadth of client’s communications with you and how the current
systems work. Without them, you will no doubt forget something. It’s important to be
thorough and auditable in this process to avoid embarrassment should a conflict arise
later.
Start writing the requirements specification document immediately, as it takes a

significant amount of time and attention to detail to finalise. Do not concern yourself with
repeated requirements statements in the first instance, but leave the clean up until you
are ready to present the first draft of requirements to the client.
There are two major categories of requirements in addition to those expressed

previously; high level and detailed requirements. Your document needs to present both.
However, the detailed requirements are usually defined after you have agreement on the
high level requirements.
The following is an example of a high level requirement:
It is mandatory that the system provides a user friendly and intuitive interface.
The following is an example of a detailed requirement:
The user interface must provide search by user id, surname, first name or telephone
number to assist in quickly and easily locating the users’ records.
When a client cannot decide whether something is mandatory or desirable, put it down
as mandatory. When they read it, they will know whether it is too harsh a requirement or
not. It is important to realise that the system will not meet the requirement specification if
it does not meet every mandatory requirement. If it can be negotiated, it’s not mandatory.
Be very selective with your classifications as the more mandatory requirements there
are, the more expensive the product will be.
Once you’ve categorised the requirements into

 high level and detailed

 mandatory and desirable
 business, function, data, interface, process, system capability (and perhaps others
such as inputs\outputs, security, audit, training, implementation, and reporting or
presentation)
 hardware and software.
you can create a document with complementary explanations formatted into these
headings. Always assess your document against the evaluation criteria presented
before, namely:
 comprehensiveness
 non redundancy
 enforcement of desired business practice
 re-useability
 stability and flexibility
 simplicity and elegance
 communication effectiveness.
This should provide a good basis for a beginner business or systems analyst - beginner
because it will take many years of practice to get it right. Until you feel confident and
have worked on a few major projects, it is suggested that you work with at least one
other experienced person and use each other as quality control. The risk of missing
something critical is diminished significantly with more than one mind working on the
problem.
The last and most important point is – no surprises. The key to success in requirements
analysis is to make sure the client knows what you’re going to present for approval
before you present it! Be sure to obtain the client’s approval every step of the way. Talk
through, and confirm acceptance of, possible solution alternatives with the client as you
go.
As you talk to your client and other stakeholders to gather their requirements, you will
start imagining ways of providing a solution to meet their needs. This could take an
infinite number of forms ranging from buying an item of off-the-shelf product, customising
bought software or writing fixes for existing programs, to developing something entirely
new or fixing a manual process with another slightly more automated process. There is
no right or wrong solution to a problem. Three criteria are used for evaluating different
approaches open to you and the client for solution development: is the proposed
solution acceptable to the client, is it effective, and is it efficient.
You should always evaluate alternative solutions so that the client understands why you
are proceeding down a particular path. The client decides the solution based on a
number of choices, and therefore always has the power of veto and always assumes the
risk. As a consultant, you will recommend a solution and argue on the basis of a number
of criteria we’ll examine shortly, but you must not be the decision maker – that is the
client’s role. It is important to evaluate alternative solutions because the client may
recognise something in an alternative solution that was not evident in the requirements
stage, and the alternative solution may be closer to their requirement than the one you
would recommend.

Who is involved?
There are a number of other people who need to be involved in the evaluation of
alternatives. These include owners of systems that are being integrated with, or
interfaced, the proposed system, any outsourced help desk or infrastructure suppliers,
any stakeholders providing input or receiving output from the system, and the
stakeholders funding the project.
You need to involve these people to gain initial acceptance and inform them of the
impact your project may have on their territory. Once again, the rule is – no surprises. If
everyone is fully informed, they have no excuse for failing to make you aware of potential
problems in the recommended solution, and they certainly have no excuse to
compromise the project after development has begun. Manage the process through
communication and go to reasonable lengths now, and you will ensure your project’s
validity throughout the life cycle.
What do I do?
In this step, you need to talk with your client and other IT experts about how you would
develop a solution based on the specified requirements. This will require research into
what is available or what alternative processes could be used.
If the system involves hardware, in researching alternatives you will need to consider
these issues:
 Is the hardware compatible with any existing systems it needs to work with?
 Will the hardware support a wide range of formats of data?
 Can the hardware be supported by existing staff? Do they have the expertise?
 Is the budget enough to cover new hardware?
 What diaster recovery systems will be required and can these be developed within
budget?
 How long will it take to purchase and install the hardware? Will additional staff be
required?
So too where the system involves new software, the following questions need to be
answered:
 What are the licensing requirements and costs?
 Is the software use per machine or per user?
 Is there a stable current release?
 Is the developer well established
 Can the source code be modified if required?
 Is the software compatible with existing software used by the organisation?
 What security\authentication methods does it use?
The different ways of achieving the required solution need to be documented and
compared against a number of criteria to evaluate which one is going to work best for the
client.
Some of the key criteria are:
 cost

 timeframe
 risk
 resources needed
 licence arrangements
 intellectual property issues
 centralised vs decentralised implementation and management
 closest fit to the requirements statements
 level of client involvement in the project management
 contractual issues
 benefits expected and competitive advantage to be gained
 level of reputation of involved vendors in the industry
 the client’s understanding and previous experience in this environment.
There will be many more criteria depending on the specific project and the political
climate of the client’s organisation at the time. You need to ascertain from the client what
the “bottom line” is. This will give you two pieces of critical information:
1. what will be the deciding factor between two very close solution alternatives
2. what factor you should be emphasising when comparing alternatives (in

particular, how you should “sell” your recommendation).
This information will influence your choice of recommendation. When you are reasonably
confident about your choice, discuss it with the client and with an independent observer
to check the reasoning behind your decision making. Sometimes they can highlight
assumptions that you have not tested. As the recommendation in the feasibility study is
the final product of this stage of the system development life cycle, it is a good idea to
have your work reviewed before you begin trying to get approval to proceed any further.
How do I do it?
In further analysis, your main aim is to ensure you haven’t missed any key requirements
and to start developing different ways of approaching the solution. Generally, you will
have one main path to the solution that may not achieve all the requirements. The
alternatives will be minor modifications to the main path that will achieve specific
requirements, should the client decide that they are a priority. You may also approach
building alternatives using the following methods:
 Consider three options: high cost or high risk development; medium cost or
medium risk development; and low cost or low risk development. You’ll generally
find that high cost means low risk, and low cost means high risk in system
development terms, although this is not always the case.
 Use different vendors or platforms to achieve the same outcome, for example
building a Linux based MySQL database vs building a Windows based SQL Server
database.
 Compare off-the-shelf solutions vs customised off-the-shelf solutions vs fully in
house developed solutions vs outsourced developed solutions vs upgraded
existing solutions.

 Choose solutions that are developed in a phased approach, or solutions that are
developed in a single effort and implemented all at once.
 Always remember that a valid alternative is to do nothing!
There are many approaches to developing alternatives for your client’s consideration.
Even if you think there are no reasonable solutions, document them anyway – it is
ultimately the client's decision which solution to adopt, you can only make
recommendations.
Document the solution alternatives, add the requirements statement and provide a
cost/benefit analysis. Also provide a basic project plan and budget at this stage for the
feasibility study.
There is no point in writing down solutions without comparing their strengths and
weakness, and highlighting the opportunities and risks involved. If you are
recommending an expensive solution, pay particular attention to the cost component.
Make sure that the client is aware of good reasons why they should spend more money
on a particular alternative. Sometimes it is very difficult to convince clients that money is
not the only deciding factor in this decision process. One method is to demonstrate how
the recommended solution will contribute to the client organisation’s strategic plan and
key performance indicators. This always has a positive impact at the executive level
when it comes to decision making.
There are many ways of completing a cost/benefit analysis, but the explanations are
outside of the scope of this course. It is worthwhile studying how to do a formal
cost/benefit analysis, as there will be occasions when you will need to justify your
recommendation to the smallest detail. A scientific method of cost benefit analysis may
save your reputation in this situation. In most cases, a simple direct comparison of
measurable costs with a qualitative argument on hidden costs and inherent risks
compared to obvious benefits across the factors of acceptance, efficiency and
effectiveness will suffice.
In the end, the decision is not yours to make, and you must abide by the decision of the
client. Always keep in mind your “plan B” to manage a situation should the client make a
decision with which you are not completely comfortable. Perhaps it is such a poor
decision in your judgement that you need a way of extricating yourself from the situation.
Build this into your contract with the client from day one.
Once the feasibility study containing the requirements analysis and solution design with
alternatives has been completed, you need the client to decide whether they will go
ahead with your recommended approach.
This is not the end of the analysis and design work, because when the client gives
approval to proceed past the feasibility study then further analysis and more detailed
requirements development may need to be performed as well as to prepare the final
proposal for the chosen solution.
Making the recommendation

The final proposal is the last step in the analysis and development stages. The end of
the preliminary stages in the development life cycle is the defining point in system
development – deciding what it is you are going to deliver for the client and getting
approval to implement it.
It is crucial that you manage the client from the beginning of the process so that you
spend minimum time and money trying to convince them of the best way to proceed. The

key success factor in this phase is communication. The more practice you get and the
more rigorous an observation you make of other analysts trying to do the same thing, the
better you will become. Unfortunately, this is not a skill that can be taught online or
through a classroom. It is something to be developed with experience.
Keep the client informed of your thinking throughout the entire process so that there are
no surprises in your final recommendation. Once you’ve compared and evaluated the
options open to the client, decide which one best fits what the client needs.
Generally, this is a middle ground solution and one that provides the best value for the
client’s investment rather than the cheapest solution. There are a number of statistical
techniques (that are outside of the scope of this course) that you can use to help
determine a scientifically precise course of action. However, if you haven’t used a
precise and formal methodology, these may well be a waste of time. It would be
worthwhile to gain a working knowledge of these formal techniques for your own benefit
as you may be required to implement them in some organisations.
The more common technique is to weight each of the criteria with an arbitrary indicator
of their importance to the client, then select the solution that meets more of the important
criteria than any other. If one criterion is heavily weighted, this can often lead to an
obvious choice. For example, if money is the only priority, then the low cost solution
should be decided on unless there are very good reasons not to. By this stage, if there
are good reasons, you should have convinced the client as well. Most importantly, try
and read what the client is leaning towards, but do not make a recommendation just
because that’s what they want to hear. Always remain professional and be able to argue
your case.
Documenting and presenting the recommendation

There are a number of ways to present your recommendation. If you are a good oral
communicator and a persuasive public speaker, lean towards the presentation medium
(e.g. a PowerPoint slide show with the key points for and against highlighted). This is
probably the most effective way to reach an audience of four or more decision makers. If
your strength is in written communication, write a project system document that is little
more than what you would include in a PowerPoint presentation, but with the speaking
notes included. The main headings to cover (not in any particular order) are:
 key outcomes from requirements gathering and specification exercise

 process of short listing and selection of candidate alternative solutions
 evaluation criteria and understanding of priorities including cost/benefits analysis
and risk matrix
 recommended solution including a graphical representation
 next steps (or what you want the client to do now, i.e., sign off).
Give the presentation to a third party for review before presentation to the client. This
may highlight potential weaknesses in your argument and may present questions which
you should have answers to on the day. This is the last step before the main project
development work begins and much time and money are invested, so take the time to
make sure you’ve got it right. A very good piece of advice is to make sure that whatever
solution is chosen, you have covered the risk to yourself of the client making a poor
judgement.
Remember the following when making a recommendation:

 Do not make the decision yourself. The client is the decision maker and they have
the final say in what the deliverable should look like. If you have stayed in touch
with the client you will have minimised the risk of being held responsible for a poor
decision by the client.
 Do not present the recommendation without a well thought out argument to
support it.
 Do not present a recommended solution that you wouldn’t be happy implementing
yourself.
Project Proposal Document

The client will usually require a final proposal report of some kind in additional to the
presentation and\or project summary document which is more of a sales document for
your solution to the project. The final proposal on the other hand is a more thorough
document which will contain information from the feasibility study, the detailed project
plan, and some detailed solution design information. You need to have it approved
before beginning your project.
A project proposal is a detailed description of a series of activities aimed at solving a

certain problem. The proposal should contain a detailed explanation of:
 justification of the project
 activities and implementation timeline (WBS)
 methodology
 human, material and financial resources required
The structure of the project proposal (including the content and length) is determined by
the nature of the project as well as by the clients’ requirements. There are many different
formats that could be used, but your proposal should be tailored to a specific client and
that client’s needs. The purpose of the proposal is to 1) introduce yourself, 2) summarise
the prospective client’s needs, 3) describe your products, services and costs, how you
will solve the need, and finally, 4) provide information about your organisation, your
credentials, and your capabilities.
Here is a generic format proposal that could be used as a guideline for an IT project:
Title page
A title page should appear on proposals longer than three to four pages. The title page
should indicate the project title, the name of the vendor organisation (and potential
partners, if any), the place and date of project preparation and the name of the client to
whom the proposal is addressed.
Project title
The project title should be short, concise, and preferably refer to a certain key project
result or the leading project activity. Project titles that are too long or too general fail to
give the reader an effective snapshot of what is inside.
Contents page
If the total project proposal is longer than 10 pages it is helpful to include a table of
contents at the start of the document. The contents page enables readers to quickly find

relevant parts of the document. It should contain the title and beginning page number of
each section of the proposal.
Executive Summary
Many readers lack the time needed to read the whole project proposal. It is therefore
useful to insert a short project summary - an executive summary. This should include:
 the problem statement;
 the project’s objectives;
 implementing organisations;
 key project activities and timings;
 the total project budget; and
 recommendations\solutions.
The summary should be compiled after the relevant items already exist in their long form
in the rest of the proposal’s sections. For a small project the summary may not be longer
than 10 lines. Bigger projects often provide summaries as long as two pages.
Background
This part of the project describes the social, economic, political and cultural background
from which the project is initiated. What caused the project to be required and the
reasons why? It should contain relevant data from research carried out in the project
planning stage or collected from other sources. The writer should take into consideration
the need for a balance between the length of this section and the size of the overall
project proposal.
Project Methodology
The project proposal should describe the strategy chosen for solving the problem and
precisely how it will lead to improvement. The methodology or approach that the project
will follow should be outlined in this section. The stages and steps that the project will
follow and what the client can expect to occur are discussed.
Client Objectives
The first issue to deal with is naming the objectives. This is also known as the project
goal/aim or the projects’ purpose. Often one major “goal” is declared and then broken
down into various objectives.
Project Goal (or overall objective)
This is a general aim that should explain what the core problem is and why the project is
important, i.e. what the long-term benefits to the client are.
Project Objectives
The objectives should address the core problem in terms of the benefits to be received
by the project beneficiaries or client as a direct result of the project as shown. Project
objectives provide a more detailed breakdown of the project goal. A project will likely
have multiple objectives.

Current System
Overview
There should be a description of the current system and the way it operates. This
information was gathered during the analysis stage. This should include all the
components that make up the system and its current features and outputs.
Problem Statement
The problem statement provides a description of the specific problem(s) the project is
trying to solve, in order to “make a case” for the project, i.e. what negative implications
affect the client. There should also be an explanation of the needs of the client that
appear as a direct consequence of the described problem.
Solutions and Evaluation
Rationale should be provided for the project.
Alternatives
The alternatives that were considered in the feasibility study are outlined here. This is a
summarised version of what was in the feasibility study, to show the various options that
could be implemented to solve the problem and the evaluation of them. The
components, costs, advantages and disadvantages for each alternative are discussed.
Evaluation
This section is where the alternative solutions are evaluated and compared against each
other in terms of costs, benefits, and how close they meet the objectives and
requirements for the project.
Recommendation
This is where you summarise the alternative solution that you recommend that the client
choses and justify your choice as the best way forward.
Project Results
Results describe the services or products to be delivered to the client. This is what the
project management is promising to deliver. The results are more detailed than the
objectives and the goal, and should be possible to measure through the use of objective
indicators.
The results should address the main causes of the problem that the client faces. To
ensure results are relevant, the project manager should have correctly identified the
client’s needs.
The results of the project should be tied back to the project’s objectives. Indicators
provide the project team with a quantifiable basis on which to judge the project’s success
in reaching its objectives. The specification of indicators acts as a check on the viability
of the results and project objectives. It forms the basis for a project monitoring system.

The Implementing Organisation
This section should describe the capabilities of your organisation by referring to its
capacity and previous project record. Describe why exactly your organisation is the most
appropriate to run the project, the constituency behind the organisation and what kind of
expertise the organisation can provide. If other partners are involved in the
implementation provide some information on their capacity as well.
System Description
Describe the current system in terms of its components, processes, and outputs. Then
describe the new system. This should cover client objectives and requirements that the
new system will solve, the systems functions, the limitations if any, and the system
processes and tasks. This will include design plans and data modelling.
Project implementation
The implementation plan should describe activities and resource allocation in as much
detail as possible. It is exceptionally important to provide a good overview of who is
going to implement the project’s activities, as well as when and where. This information
all comes from the project plan document.
Deliverables and Milestones
These are what the new system will achieve for the client and the major checkpoints
during the stages of the project. Timing (dates) for the achievement of the milestones are
given here so the client knows when to expect activities to occur.
Implementation Approach
This is where detail is provided on the steps that the project will follow. While the WBS
lists these in detail, here you provide an outline of the flow of the processes involved.
This is the application of the methodology that you have earlier discussed.
Activity Plan (schedule)
The activity plan should include specific information and explanations of each of the
planned project activities. The duration of the project should be clearly stated, with
considerable detail on the beginning and the end of the project. This is basically the work
breakdown schedule (WBS) for the project.
The activity plan can also be expressed as a Gantt chart.
The information should be clear and in a readily understandable format.
Resource Plan
The resource plan should provide information on the means necessary to undertake the
project. Cost categories are established at this stage in order to aggregate and
summarise the cost information for budgeting.
Basis of Estimates
The basis on which the work rate and work effort required for tasks is explained. This
enables the client to see that the schedule, resources required, and budget are
reasonable estimates.

Budget
Income is the amount of financial assets and contributions used as sources of support
for the project. If the funding is sourced from just the direct client, the income side of the
budget may not be shown. However, many projects have more than one source of
support. The income side should show the share of contribution of each of these
sources.
Expenses are all the costs that are anticipated to occur during the project’s
implementation. Regardless of the calculation and classification criteria used, the project
costs should present a reasonable reflection of the activities presented in the project
proposal.
The two main costs are direct costs and operational costs. Direct costs are associated
with a certain activity (e.g. organising a workshop). Operational costs are related to
internal activities of an organisation and are considered fixed costs in the short term (e.g.
staff salaries, rent, utilities, etc).
Project Roles
A description should be given of the project personnel, the individual roles each one has
assumed, and the communication mechanisms that exist between them. Who is involved
and with which task and who is responsible for the different aspects of the project should
be listed here.
Testing and Training
An important part of a project is testing each component of the system as it is developed

as well as the functions of the system. The proposal must show what testing will be done
to show that the system will meet the deliverables. The testing approach and who is
responsible will be listed. Training plans including the test processes and any test data
that will be used can be introduced even at this point.
The client requires staff to be trained to use any new system, so the proposal should
outline what training will be performed, by whom, and when. A training plan including
development of documentation should also be covered.
Communications Approach
Communication is very important in a project. Hence a communications plan for the

duration of the project should be part of the proposal. This will show what information will
be distributed and to whom and when.
The schedule of project progress and financial reports could be set in the project
proposal.
The project report may be compiled in different versions to meet the needs of the
audience they are targeting. A member of the project steering committee requires
different information from that a team member.
Quality Assurance
It is important that the project’s tasks achieve a quality result and all the parts of the
system are produced to meet the quality expectations of the client and stakeholders. To
do this a quality assurance plan is required, which sets out the indicators of quality and
how they will be measured and reported. There should also be procedures designed to
correct identified quality problems, and these will be documented in this section.

The basis for monitoring is set when the indicators for results and criteria are set. The
project proposal should indicate:
 how and when the project management team will conduct activities to monitor the
project’s progress and quality;
 which methods will be used to monitor and evaluate;
 who will do the evaluation; and
 what will be done if quality indicators or criteria are not met
Risk Management
Risks can cause the project to go off track in terms of the schedule, requirements,
criteria, and budget. Hence it is important to identify the risks, their probability of
occurrence, and what actions will be taken if they occur.
There thus should be a risk management plan to identify and outline procedures to
handle risks.
Appendices
The appendices should include all the information that is important, but is too large to be
included in the text of the proposal. This information can be created in the planning
phase of the project or during the feasibility study, but often it is produced separately for
the project proposal. The usual documentation to be annexed to the project proposal is:
 analysis related to the general text in the main proposal;

 policy documents and strategic papers;
 detailed system design and examples;
 more detailed plans for risk, quality, training, work tasks, and budget;
 information on the implementing organisations (e.g. annual reports, success
stories)
Remember that the format discussed above is not the only way to structure a final
proposal and you will find many variations of this in practise.
The final proposal is a formal document, so your writing needs to be professional. Be

clear and concise and use correct spelling, punctuation, and grammar.
Sign-off
Once you have made all the changes to the final proposal document and updated the
version of the document, you then need to ensure that you can get sign-off from all the
stakeholders. Final sign off is usually only granted after the feedback has been
incorporated into the document.
If someone is required to sign-off only the changes to the original document, then you
will have to identify what the changes were to the people who are signing-off the
document.
There are various methods for gaining signoff (which depend on the processes in your
organisation), but the most important outcome is that you have a signature as proof that

someone else has read the material and is happy to take responsibility to allow the
document to be published.
If the client doesn’t sign off, then it’s “back to the drawing board” and probably a good
experience from which to learn. This does happen quite often, and it’s not always the
analyst’s fault. It may be that the political climate is so uncertain that the client just can’t
make a decision right now. In this case, you will still have a document that the client can
use when they are ready, and if you’ve done it right, it should remain relevant for some
time to come.
If the client does sign off on the proposal, then you’ve done a good job. Now it’s on to
the next stage of the life cycle and the actual task of system implementation.
System or Solution Design

When you have your system specification clear and a solution is selected, there is a
great temptation to begin work on the solution immediately. Stop! Think! You need to
design your solution first.
In the detailed analysis phase, you would have learned all you could about the problem,
analysed the stakeholders’ requirements in detail, and considered a range of solutions.
You will have already considered and discarded a range of possible solutions and finally
settled on a solution that:
 is acceptable to the stakeholders

 is technically feasible
 is achievable within the budget, time and environmental constraints
 will perform within the acceptable performance range.
Stakeholders are important groups of people or individuals who can have an influence
on, or are affected by, the development project. Some stakeholders have their own
objectives and views, which may differ and conflict with others. Stakeholder analysis
identifies all the parties who are directly or indirectly affected by the project. It sets out
the issues, concerns and information needs of the stakeholders with respect to the
project. This includes not only the traditional shareholders (owners and users), but also
some new groups that the insights of environmentally responsible development tell us
must be consulted in decisions that affect them.
In recent research1, it was determined that when development projects failed, they did so
because of a few common factors. These are set out in Table B-4.
The Standish Group International, Inc. “CHAOS: A Recipe For Success”

http://standishgroup.com/visitor/chaos.htm

Factors Percentage
1. Incomplete requirements 13.1
2. Lack of user involvement 12.4
3. Lack of resources 10.6
4. Unrealistic expectations 9.9
5. Lack of executive support 9.3
6. Changing requirements and specifications 8.7
7. Lack of planning 8.1
8. Didn’t need it any longer 7.5
9. Lack of IT management 6.2
10. Technology illiteracy 4.3
11. Other 9.9
Table B-4
Good system design will involve the end-user and other stakeholders, define the
expectations, document all the requirements and provide the basis for a sound planning
process. With an adequate blueprint before the development proceeds, all stakeholders
will be aware of what is intended for delivery. Many project failures could have been
prevented had proper attention been given to the design process.
The design step culminates in the creation of the blueprint, a highly detailed plan that will
be used to implement the system. To function adequately as a blueprint, the design must
meet the following equally important objectives:
 The design must show that your system will completely and accurately satisfy the
stakeholders’ requirements.
 The design must clearly communicate to the programmers of the system how the
stakeholders’ requirements will be implemented.
Armed with your detailed analysis and requirements statement, you can begin on a
detailed design. The preliminary stages are important because you not only need to
make sure you understand how each piece of the solution will fit together, you need to
be able to communicate that knowledge to the others who will build and/or maintain the
system.
System Specification
A basic system design document should cover each of the main sections listed below:
1. Introduction
2. Database Management System Specifications
3. Module Definitions
4. Screen Designs
5. Menu Network/Screen Navigation
6. Report Layouts
7. System Interfaces
8. Error Handling
9. Help System
10. Appendices.

Introduction
This places the development of the system in its proper context. In keeping with the
expectation that the reader knows nothing of the development task, the introduction
covers the major decisions and agreed standards that will govern the development.
It should at least cover the following elements:
 System Overview - what is being developed and why

 System Objectives - what the project is intended to deliver
 Confirmation of Scope - what the development project intends to cover
 System Constraints - the limits on the system and the project
 Measures of Success - how we will know we have succeeded
 Quality Assurance (QA) - how we will assure that we deliver a quality product
 Target Audience - the intended audience of the design document
 Documentation - other documents the reader should consult
 Methodology - the development model used
It is advisable to write the introduction twice. In the pre-design draft, you document your
understanding of the design task. When you review and edit the introduction, you are
preparing to present the system as you have designed it to the development team and
system owner.
Database Management System Specifications

Describe the database environment in which the system will operate. This should include
a description of the tables and data elements in a data dictionary. Support the data
dictionary with an entity relationship diagram or other conceptual view of the database.
Module Definitions
Module design is the process of packaging the interface, procedure and database
specifications into module specifications. The objective during module design is to create
modules that are adaptable and easy to maintain.
It is unlikely that any project will attempt to develop a new system without first breaking
up the task into easily manageable portions. Each module can be likened to a
department in a company or section in a shop charged with offering a unique set of
services on a particular theme.
System Development
System development refers to the actual implementation of the system design through
writing DBMS scripts for creating the database (or dragging and dropping for more
modern interfaces), coding the application and building the user interface. By now, you
should be fully familiar with the techniques of successful system development. In the
professional world of system development, it isn’t enough to build your system cleverly
or quickly. You need to build your system strictly to the design specified by the designer.
Because the developer writing the system design document is likely to be involved in
creating the system, there is usually a temptation to document only enough to support

the developer’s own knowledge of the system design. Staff changes, commercial
considerations etc. might mean that the person who creates the system design may not
be available to provide additional knowledge of the system.
Just as a builder has little leeway to be creative when following a building plan, a system
developer has little room for creativity in building a system. However, if the design is
vague, you are inviting the developer to fill in the gaps for you. Your developers may not
have been party to the preceding phases of requirements analysis, system specification
or design, but they are highly creative problem-solvers and delight in finding new,
innovative or even “cool” programming shortcuts to achieve the end result. Too often,
this introduces problems for the developers, integrators and maintainers who follow
months or years later.
A successful system design document will be written with the whole system development
lifespan in mind. The system design document and the reference material must be
complete and sufficiently detailed to allow a developer, unfamiliar with the proposed
system, to construct or enhance the system without additional advice.
As a developer charged with building a system, you need to focus on different

objectives, and a much shorter time frame than the designer. In the same way that an
architect or an engineer designs a structure for a particular purpose over the entire life of
the structure, a system designer has to consider the range of potential issues that will
affect a system over its life. To build it as designed means to build it to the specifications
with attention to the design elements that meet performance, quality, maintainability and
other utility goals.
Inadequate design leaves opportunities for misunderstanding and misinterpretation to

affect the development. The designer has a responsibility to provide the developer with
enough direction to build the design successfully, and therefore needs to be mindful of
the range of issues that confront the developer in the absence of adequate design.
Testing
Before the developed system can be delivered to the client, it must go through rigorous
testing to verify that the specified requirements have been fulfilled.
Generally, there are three main types of testing:
1. Unit testing–the rigorous unit testing of individual components of the system in

isolation
2. Integration testing–the rigorous testing of higher-level components or modules as
they exchange data between each other
3. User Acceptance Testing–the highest level testing of a full system by the client
before acceptance of the finished product.
To perform any of these tests adequately, a test plan needs to be developed in tandem
with the system design to ensure that test cases adequately cover the requirements of
the system. The plan would determine the boundary conditions, or legal values, of the
business rules used in each module and test that the rules are coded correctly. The use
of a plan allows the reviewer to exercise the software systematically in an attempt to
discover any areas that may contain bugs.
Most systems are designed with only “perimeter” data validation in place. Data entered
through an input field or from an external system is often rigorously filtered and
validated, whereas data coming from the database or from another module is often

trusted to be in the accepted format. Problems arise when a perimeter rule is defeated or
bypassed and invalid data is entered into the database. When that data is used later by
another module or subsystem, the problems may only then surface.
By using artificially contrived data rather that real-life data, the tester forces the software
to test these rules in an attempt to discover unexpected combinations of values that will
throw a system into turmoil. Without this form of testing, billing systems could send
customers bills for $0.00 (error in threshold values), accept updates of 0 items (a typing
mistake?), demand updates every 0 days and so on.
It is also useful to include erroneous values such as negative numbers where positives
are the rule, letters in place of numbers, odd characters like “ ! @ # $ % ^ & * \ | ` ~ é â ”
and two-digit years.
By creating a test plan and the associated test cases in parallel with the design
document, you will confirm your understanding of what the system should and should not
do. Testing should not be an afterthought at the end of the system development phase.
It should be part of a consistent approach to controlling the quality of the final product.
In developing a software product, it is not enough for it to just work as designed. It must
fulfil the role for which it was originally intended. Clearly there needs to be some way of
determining the suitability of a product before it reaches the hands of your client.
Validation is a formal process of review that determines whether the requirements and
the final, as-built system fulfils its specific intended use. Validation should happen at the
end of every step in the software development process so that the system has a higher
likelihood of succeeding. Typically, an independent person would conduct the process of
validation as they are more likely to uncover problems and issues with the product or
system.
Benchmarking and Acceptance Standards

Benchmarking in software development is the selection of an accepted standard of
excellence and the measurement of your own product’s attributes against that standard.
It is not the same as rating the raw speed of a product, but rating those attributes that
actually make a difference to the user of the system.
3D video cards might be designed to deliver a certain number of triangles per second to
the screen, but a generally accepted benchmark of performance is frames per second in
a demanding game like Quake. Similarly, CPUs might be rated in terms of cycles per
second (MHz or GHz), but performance is best measured against the WinBench or
SysMark benchmarks, depending on your application.
The act of benchmarking is not so much in the measuring, but in the selection of the
particular metric, or measure in which you are trying to excel. For a database application,
performance may be measured in the number of transactions per hour that it can
process, or the time taken to return search values, or the number of concurrent users it
can support. But if the client is concerned with the number of keystrokes needed to
perform a function, or the number of times they have to move their hand from the
keyboard to the mouse, other measures of excellence are of little consequence.
The challenge is to benchmark your system against a standard of excellence that is

valued by the client so that in meeting that standard, you assist your client in achieving
their business objectives. Benchmarking experts will counsel that you should look
outside the box of the product’s immediate context. By examining your client’s business
context, a suitable measure should be found.

Typically, a client will know what is acceptable in terms of performance, but if that
expectation exceeds the current best practice model, you need to be prepared to
educate your client, or create best practice!
Implementation
Implementation is the stage of a project in which the developed application is installed
for operation by the end-users. It is a crucial time in the project. Despite the most
rigorous analysis, development and testing of the application, the true test of success in
the eyes of a client is always in the operational use of a system. During implementation,
it will be scrutinised by elements of user management and staff who have not been
involved in the development and may not be fully aware of the reasons for change, or of
any compromises or limitations that have been agreed for the first release. Expectations
will be high, especially if there has been a long development. There may be publicity
associated with the ‘launch’ of the new software.
Implementation is therefore a stage in the project that requires careful planning and
management, and one that should include a build-up of communication to a broader
group of the user organisation to assist with their understanding and acceptance of the
new system.
So, how do you ensure that your well-developed application is properly implemented and
well-received by the users?
There are several activities that you must initiate earlier in the project to make
implementation easier. Consideration of infrastructure restrictions, software distribution
methods, data conversion and user training during the design and development stages
will lead to requirements for the implementation. Naturally, there needs to be a project
plan to ensure activities such as training, issue of documentation, data migration and
software installation are scheduled and completed.
Beyond that, there are the issues of management of expectations, and dealing with
individuals who may be opposed to the change, or who have difficulty coping with new
technology. These are change management issues, and handling them is critical to the
success of the project. There are companies who specialise in dealing with change
management, and it may be appropriate to engage their services, especially for larger
projects with many users or sites.
Implementation sites can vary from a single location with a small set of skilled users
(e.g., a scientific application in a research organisation), to a large organisation with
many sites and many users (e.g., a direct sales organisation with order centres in all
major cities). A smaller site may be easier in terms of communicating with the users, but
they are likely to be more demanding in the functions and quality of the application. A
larger site has the challenges of training and supporting a large number of users with
varying abilities. If the application is intended to standardise processes, the less
standard sites will be harder to implement as they will experience significant changes to
their business processes, and are therefore more likely to oppose them.
Documentation
Ideally, the documentation for the application should be available before commencing
implementation. Unfortunately, this is not always possible, as production of
documentation takes considerable time. Also, the application development will most
likely continue up to the time of implementation, and even into it, as problems and
enhancements are found.

Nevertheless, you should insist on drafts of the following manuals (where appropriate)
being available for use during the training and early operation:
 System Operations Manual - for the infrastructure group to understand the

installation process, requirements and such things as the location of critical files
etc. It covers routine system administration tasks such as user account
management and backup processes that have been delegated to the infrastructure
group. It may also include a service level agreement (SLA), if required, between
the application support time and the infrastructure group.
 Database Administration Manual - for the database administrator (DBA) to
understand the database schema and fundamental operation (indexing, searches
etc.) for database support and tuning. This will be especially important if the
organisation has a dedicated DBA who looks after all databases on their system
and who will not have been closely involved in the application development.
 Data Administration Manual - One or more senior users are often given
responsibility for the integrity of the data (as opposed to the integrity of a database
itself, which is the DBA’s responsibility). These users may have extra privileges to
change system data, but may feel unsure in that role, as they are often not IT
specialists.
 User Manual - the manual the users will reference during their routine operation of
the system.
The documents described above are long-term documents that will eventually be issued
in final versions and subject to version control and update as the application stabilises.
NOTE: If it is not possible to produce drafts of these manuals for the

training, it would be well worth reviewing the maturity of the application. If
it is so ill-defined, or changing so much, that these manuals cannot be
provided, is the application ready to be released to users?
Training
When considering training for a new system, you have two main options: formal
classroom training, or on-the-job training. A secondary option is to provide self-paced
training. This is less preferable for a new application because all the users are new and
there can be no peer support.
Formal classroom training is generally used for larger projects in which the users have
had little exposure to the application before implementation, and where many user errors
can adversely affect the production system. For very complex systems and large user
groups, it may be necessary to provide a completely independent training system with
dummy data.
Development and delivery of training in complex applications for large groups is a major
activity, and the employment of an experienced and skilled training coordinator to
develop the method, curriculum and schedules is recommended.

On-the-job (OTJ) training is more personal, but is also more resource intensive. Note
that there is a difference between OTJ and on-site support. OTJ should still have a set
curriculum and goals to ensure the training is consistent and complete.
Don’t forget training for staff with special roles: the infrastructure group, the DBA and any
user staff with special data administration roles.
The timing of training is important. If it is given too soon before system implementation
(the rollout), users will forget what they have learned. Also, the application may change
between training and the rollout.
Planning
As a project progresses, the project plan for future stages is continually reviewed and
refined. More detail is entered and better estimates are available as a result of
experience and understanding from earlier phases. So, just before the implementation
stage, and as part of the normal project management process, you should undertake a
detailed review of the plan to finalise all of the activities that are required for
implementation.
The major activities that may be required for implementation are:
 installation
 data conversion or acquisition
 training
 documentation
 user rollout. Often referred to as “going live”. This is usually a milestone achieved
by executing all the other implementation activities.
 support
 transition to routine operation and maintenance
 recording and reporting
During detailed project planning, you will break these activities down into small work
packages (tasks) which are assigned to individuals. You will identify the resources
required for each task and make sure they are available.
Project handover
The outcome of many projects is a working system to be handed over to a client to

operate. For example, at the end of a network deployment project there is a network to
be operated and maintained.
Project handover is the formal completion of the project manager’s obligations.

Handover is completed to ensure the customer is satisfied with the project deliverables
and project support options are in place. The project manager’s obligation to the client
stops once the project product or system has been formally accepted by the client.
Before handover can be completed, stakeholders will need to formally approve the
product or system. This may be done by the project manager demonstrating the
completed product meeting requirements.

Project reviews
Project reviews are important as they are fundamental in answering some questions
about the conduct of the project for the benefit of future projects. The purpose of a
project review is to determine if:
 the project was completed to quality, time and cost targets and if not why not
 there are lessons to be learnt
 are there any follow-on actions from the project
Answers to these questions should be documented and presented to management.
Reviews can cover many areas, but two common ones are:
1. Project manager’s final report
The project manager’s final report should be produced at the completion of the
project by the project manager. The following issues are usually addressed:
 Project performance — comparing achievements to the project plan

 Administrative performance — reviewing administrative practises with the
organisation
 Team performance — providing a confidential report to senior management on
team members’ effectiveness
 Techniques of project management — reviewing the methods used for
estimating, planning and control.
Recommendations for change should be made, if appropriate. Things that worked

well should also be noted so that they may be continued in future projects.
2. Post-completion report
The post completion report is conducted to find out whether the promised benefits
have been delivered and - if not - what should be done to achieve them.
The best time to carry out such a review is as soon as possible after the project has
had time to start showing the planned benefits. For example, if a promised benefit
was to reduce the number of collusions on a network, this should be noticeable and
measurable at the completion of the project.
Documentation
At the end of a project, a large amount of documentation may need to be handed over to
the appropriate people.
The project team should determine - in consultation with the stakeholders - who should
receive all the documentation and other assets accumulated during the course of the
project.
This documentation includes complete lists of all project deliverables, showing how they
fit together and how they were designed and tested. The documents should show how it

was intended that the product should be used and maintained. Storage and security of
hard and soft copies of project documentation should be agreed upon and procedures
on archiving designed.


Group Development Project Appendix C: Windows Live GDP Guide
C
APPENDIX C
WINDOWS LIVE GDP GUIDE
Introduction .............................................................................................................. 2
Windows Live Services ..................................................................................................... 2
Create GDP Folders ......................................................................................................... 3
Windows Live Groups ............................................................................................. 3
Team Group ...................................................................................................................... 3
Manage members ............................................................................................................. 4
Configuring options ........................................................................................................... 4
Manage a group calendar ................................................................................................. 5
Viewing agendas and creating to-do lists ......................................................................... 6
Join A Group ..................................................................................................................... 8
Send an e-mail to the group ............................................................................................. 9
Start or respond to a discussion ....................................................................................... 9
Have a group conversation in windows live web messenger ........................................... 10
Windows live Group skydrive – share documents ................................................ 10
Uploading Files ................................................................................................................. 11
Uploading using the standard upload page ...................................................................... 12
Uploading by Dragging and Dropping Files ...................................................................... 12
Viewing and sorting Files .................................................................................................. 13
Downloading from skyDrive .............................................................................................. 13
Setting access permissions for sharing Folders ............................................................... 14
Granting Group permissions ............................................................................................. 14
Granting Individual permissions ....................................................................................... 14
Storing your Browser Favorites on skyDrive .................................................................... 15
Office Web Apps ...................................................................................................... 15
Work on Shared Documents ............................................................................................ 17
View and Restore Document Versions ............................................................................. 18
GDPLGA006a Computer Power Plus C-1

Appendix C: Windows Live GDP Guide Group Development Project
Windows Live Calendar ........................................................................................... 19
Organise meetings with the Windows Live Calendar ....................................................... 19
Change a meeting to a recurring meeting ........................................................................ 19
Other Ways to schedule meetings ................................................................................... 20
INTRODUCTION
Computer Power's student e-mail system uses Windows Live. This Windows Live
student e-mail service is available for all students. Computer Power has partnered with
Microsoft (Microsoft Live@edu program) to offer you a customised
@mail.computerpower.ac.nz student e-mail account hosted by Windows Live.
Using this service you can send and receive e-mail from virtually any web-connected
computer and have one e-mail address for life - as a student you may keep and use your
Computer Power Windows Live account after graduation or the completion of your
educational goals with Computer Power. You also get access to a number of other
services such as Calendar, Groups, and SkyDrive.
Many of these Windows Live services are very useful to assist you as you participate in
a Group Development Project (GDP) team.
This guide is intended for students who are participating in a GDP team project and who
will use the Windows Live services to collaborate and communicate throughout the
project. It is highly recommended that you take advantage of these services as they
make it very easy to run and participate in the team project. It will also make it easy for
you to communicate with the GDP Supervisor and for them to see what the team are
doing.
For this reason the GDP Supervisor will setup a Windows Live Group and deposit
important GDP documents via the Windows Live Group.
WINDOWS LIVE SERVICES

A number of the Windows Live Services you have available using your Computer Power
Windows Live e-mail account are highly useful for the GDP team and its project. These
are as follows:
 Outlook Live - Sending and receiving e-mail, and scheduling meetings in the
calendar with team members.
 Windows Live Web Messenger - Stay in touch and talk via instant messaging
and exchange photos and documents.
 Windows Live SkyDrive - Store and share files with students – a Group is given
5GB of free storage, which can be protected with a password.
 Office Live Apps – use simple versions of Microsoft Word, Excel, OneNote
notebook, and PowerPoint online. Make live edits of documents stored on
SkyDrive.
 Windows Live Groups - Create online groups for collaborative projects, and
academic clubs, teams and more.
C-2 Computer Power Plus GDPLGA006a

Specifically for the GDP project, the GDP Supervisor creates a project group using
Windows Live Groups, and then invites all the other GDP team members as well as the
GDP supervisor to be members of that group. This will allow everyone to post items to
the Windows Live Group site, communicate via e-mail, share files from their SkyDrive,
start Discussion boards, and use Web Messenger to communicate in real time.
Windows Live Groups is used since it includes document storage as well as calendaring
and communication features.
CREATE GDP FOLDERS

To make it easy for team members and the GDP Supervisor to access and share files,
the GDP Supervisor will create a number of folders on the GDP Team Group site (which
are stored in the team’s SkyDrive). The folders are as follows:
 Project Reports – this folder can be used to store the reports for each stage of the
GDP project. This allows team members to work on the reports and put the reports
here for the GDP Supervisor to review, and then the GDP Client can be sent a link
(by making the file publically available) to the file in order to read it.
 GDP Documents – This folder can be used by the GDP supervisor to store the
supervisor and client marking schema, so the GDP team has access to these to
ensure that they meet the requirements. The GDP Supervisor can also put other
documents in this folder, such as guide to writing a Final Project report.
 Communications – this folder can be used to store meeting minutes and important
e-mails that the Communications Officer of the team is required to keep.
 Team Profiles – this folder can be used by the team to store and complete the
team profile document required at the start of the project.
The Team Leader will be able to create additional folders as required.
Individual team members and team members working together on documents can also
use their own SkyDrive to store and share documents, but the GDP teams’ final team
documents should be stored on the GDP teams Group site.
WINDOWS LIVE GROUPS

This part of the guide will provide instructions on using Windows Live Groups, Outlook
Live, SkyDrive, Windows Live Calender, and Web Messenger to collaborate and
communicate during the GDP team project.
TEAM GROUP
The GDP Supervisor will first create a group for the team project.
The name of the group will be CPxxxGDP_zzz where xxx is your Institute Auckland =
Auk Wellington = Wel Christchurch = Chr, and zzz is your team number.
Each group gets its own Windows Live Profile, Calendar, SkyDrive folders, and Photo
albums. This makes it easy for group members to set up meeting using the calendar,
and share documents that the group is working on. Groups can also have discussion
boards that make it easy to share your ideas with the group, and discussions can be

saved online for others to see. Once a group has been setup these features make
Windows Live Groups really useful for a GDP team.
Each group also gets its own website address http://groupname.groups.live.com and e-
mail address groupname@groups.live.com. If you send an e-mail to the group e-mail
address, all the members of the group will receive the message by default.
To logon to the group site the steps are:
1. Visit Windows Live Groups at http://groups.live.com/ Sign in with your

9xxxxxxx@mail.computerpower.ac.nz (where 9xxxxxxx is your student e-mail
number) e-mail address and your password. Click the Sign in button.
2. Click View your groups, and then click the name of the group.
You can also access your group when you are logged on to your e-mail account, by
clicking Office, then Your Groups from the top of the screen.
MANAGE MEMBERS
The team member who is selected as the Team Leader will be given rights to manage
the Windows Live Group for the team.
When you create a group, you can invite someone to become a member of the group.
You can set permissions for who can see the group, and you can manage members by
accepting or declining requests to join the group. By default only those invited and part
of the group can see the Group – it is best to leave it this way for a GDP project and not
change the permissions, so this guide will not show you how to change the permissions.
The group’s owner will be the GDP Supervisor and the Team Leader will be a co-owner
who can also change the role of other members.
Thus the GDP Group Team Leader shares the responsibility for approving or inviting
new members, monitoring photos, or other tasks related to managing your group.
Owners and co-owners can change the role of a member. It is a good idea to make the
Deputy Team Leader of the GDP team, a co-owner of the Group.
To change a member's role, the GDP Team Leader should follow these steps:
3. Visit Windows Live Groups at http://groups.live.com/ Sign in with your

9xxxxxxx@mail.computerpower.ac.nz (where 9xxxxxxx is your student e-mail
number) e-mail address and your password. Click the Sign in button.
4. Click View your groups, and then click the name of the group.
5. Click Membership.
6. Click the checkbox next to the member whose role you want to change (in this
case your fellow student in the GDP team who has been made the Deputy Team
Leader).
7. Click Change role, and then click Owner, Co-owner, or Member.
CONFIGURING OPTIONS
Now that your group is underway, you might want to adjust a few of the options Windows
Live provides to make your group even better (only an Owner and Co-owner of the group

can change all of these options). To explore the options you have for your group, click
on the Options menu link on the group page.
Under Group options, you have six main categories to choose from: General, E-mail,
Group Conversations, Personal, Leave group, and Delete group
Starting with General options, you’ll see many of the choices displayed here that were
made when the GDP Supervisor first configured your group. However, there are a few
more things you can set that customise the group a little more.
The new options you can set include adding a group message that will be displayed
below your group name on your main web page, changing the group picture, describing
more about your group, and setting permissions for both the group calendar and
files/photos (these will be considered below). The group options can be updated with a
different group picture, a message, and a new theme.
The General options contain the most choices for changing your group. But there are
other options to consider as well. Here is a brief discussion of the other options you can
set:
 E‑mail: Turn group e-mail on or off, as well as manage members who are either
banned from sending group e-mail or who are not receiving it because of delivery
problems or if they have opted out of receiving it.
 Group Conversations: Enables you to turn off group conversations in Windows
Live Messenger for groups of up to 20 members.
 Personal: Where you or any member can opt out of receiving e-mail messages
from the group.
 Leave group: Where you or any member can decide to leave the group.
 Delete group: Where you as a group owner can decide to delete the whole
group.
MANAGE A GROUP CALENDAR

The group will have a group calendar, which all members of the group can view. The
calendar that is built into Windows Live Groups makes coordinating everyone’s schedule
much easier. The calendar used by Windows Live Groups has most of the same
features as the personal calendar. Also anything added to the Group Calendar will show
up on the calendars of all the other members of the group, too. Thus the Group calendar
is automatically shared between group members.
When a group is created, anyone who is a member of the group can add an item to the
group calendar. Owners and co-owners can choose to limit who can edit the group
calendar. For a GDP team it will be best if only the Team Leader (Owner) and Deputy
Team Leader (Co-owner) can add meetings to the team calendar.
Windows Live Calendar doesn’t try to distinguish between meetings, appointments, or

other types of commitments and simply refers to them all as events.
Add an item to the group calendar as follows:
1. Visit Windows Live Groups, logon, and click View your groups, and then click the
name of the group.
2. In your group, click Calendar.

3. Click New, then Event.

4. In the Add an event window, type the information about the event, including what
the event is, the date of the event, the start and end times, whether to be sent a
reminder about the event, and where the event is taking place.
5. Click Save.
To limit who can edit the group calendar the steps are:
1. Visit Windows Live Groups, click View your groups, and then click the name of
the group.
2. Click Options, and then click Group options.
3. On the General page, next to Calendar, do the following:
To limit who can edit the group calendar, click Only the owners and co-owners
can edit the calendar.
The calendar web page for your group has a lot of very useful capabilities. Windows Live
provides helpful popup calendars and times to choose from as you create your event. If
you want to add additional details, such as adding an event charm (a small icon shown
for the event), making the event recurring, or adding an extended description for the
event, just click on the Add more details link.
One of the handiest features of the calendar is the ability to show multiple calendars in
one view. To do this, click on the Your calendars link on the left side of the calendar web
pages and then check each calendar you want to view or check all calendars. You’ll see
the entries from each, colour-coded on one calendar.
Windows Live makes it easy to avoid scheduling conflicts between your personal plans
and your group plans.
The Group’s calendar is used the same way as you normal Windows Live Calendar.
Further information on how to use a calendar to schedule GDP team meetings can be
found in the Computer Power Student E-mail System Student Guide (which is located in
Section 1 of the Computer Power Student IT Systems Guide).
VIEWING AGENDAS AND CREATING TO-DO LISTS

You can also use the group calendar to create To-do lists of tasks that need to be
accomplished by the group.
When you select the Agenda tab, you will see a list of upcoming events from the group
calendar (see Figure C-1). You can select the date range to view.
Another handy calendar feature is the to-do list, which is displayed when you select the
To-do list tab. The Windows Live service can help you manage to-do lists for the group
calendar. As Figure C-2 shows, the to-do list shows upcoming tasks that need to be
completed by their title, due date, and status.

Figure C-1
Figure C-2
In the to-do list, upcoming tasks are listed under the Upcoming heading and completed
tasks are listed under the Done heading. Tasks have three basic states:
 Not started - A task that has not yet been started
 In progress - A task that you are working on but has not yet been completed
 Done - A completed task.

When you create a task, you can specify a priority to indicate the task’s relative
importance. You can set start and due dates. You can also add reminders so that you
are notified a specified amount of time prior to a task’s expected due date.
Each task is colour-coded to the calendar to which it relates and can also have a priority
indicator to the left due date. High-priority tasks are shown with an exclamation point.
Low-priority tasks are shown with a down arrow. Normal priority tasks don’t have a
priority indicator.
You can create a task by following these steps:
1. When you are working with the group calendar while signed into the Windows Live
service, select the To-do list tab.
2. Click the Add a To-do link. This displays the Add a to-do dialog box.
3. In the What text box, type a title for the task.
4. If the task is not for your default, primary calendar, click in the Calendar list and
select the calendar with which the task should be associated.
5. If desired, use the Priority to set the task’s relative priority as High, Normal, or
Low.
6. Use the Due date options to specify the date when the task must be completed.
Optionally, you can specify a time the task is due.
7. To set the task status, set a reminder or add a description, click the Add more
details link. You’ll then be able to use the Status list to set the task’s status, the
Send Reminder list to specify when a reminder should be sent before the due date,
and add a description of the tasks.
8. Click Save to add the task to your to-do list.
Any uncompleted tasks created on the group calendar are displayed under the
Upcoming heading. You can change a task’s status by clicking the current status and
selecting a different status. When you mark a task as done, it is displayed under the
Done heading. However, by default, completed tasks are hidden and you must click the
Done heading to retrieve the list of completed tasks.
When you complete tasks, you may want to delete them. You can delete a task by
clicking the related Delete button. You can delete all completed tasks by clicking the
Delete all link and then clicking OK when prompted to confirm.
JOIN A GROUP
To join a group when you're invited:
 Open the e-mail invitation you received, and then click Join.
Or
 Visit your Windows Live Home page and join the group that you've been invited to
as follows:
1. Visit Windows Live Groups at http://groups.live.com/. Sign in with your
Computer Power Windows Live ID.
2. At the top of the page, click View invitations.
3. On the left side, click Groups.

4. Click the group you want, and then click Join.
SEND AN E-MAIL TO THE GROUP
the group. If necessary, sign in with your Computer Power Windows Live ID. If the
group has e-mail enabled, the e-mail address for the group appears at the top of
the page.
2. Click on Hotmail at the top of the screen, then create a new message, address it
to the group e-mail address, and then send it to the group.
You must send the e-mail from the same Windows Live ID that you use to participate in
the group.
As groups get larger and larger, it can be difficult to remember everyone’s e-mail
addresses. With Windows Live Groups, however, you have one single e-mail address to
remember to contact everyone in the whole group. It’s easy to remember the address.
It’s the same as the groups’ name, followed by @groups.live.com.
If you recall the group options discussed previously, any member of the group can
decide to no longer receive group e-mail. This option is set by clicking on the Personal
link on the left side of the web page. The owner or owners of the group can see who has
opted out of receiving group e-mail by clicking on the E-mail link on the options page.
Any member who opts out of receiving e-mail from the group will not receive a message
that you send to the group’s e-mail address.
START OR RESPOND TO A DISCUSSION

Anyone who is a member of a group can start, read, or add to a discussion.
To start a discussion:
the group.
2. In your group, click Discussions, and then click Start new discussion.
3. Click in the Title box, and then type a title for the discussion.
4. Click in the edit box, and then type your discussion.
5. Click Publish.
6. Click Invite people.
7. In the To field enter the name of the person from your GDP team whom you want
to get an opinion from and write a message.
8. Click Send.
To read or respond to a discussion:
the group.
2. Under Discussions, click the title of the discussion that you want to read.
3. To add your thoughts to the discussion, click Reply.

4. Click in the edit box, and then type your response.

5. Click Publish.
HAVE A GROUP CONVERSATION IN WINDOWS LIVE WEB MESSENGER

Groups with up to 20 members can have group conversations. Any member of the group
can initiate a group conversation using Web Messenger or Group Discussions. When
you turn off group conversations, you can't turn them back on for this group, so it is best
NOT to turn off group conversations for the GDP group.
To start a conversation using Web Messenger, logon to your Computer Power Windows
Live account, click Mail on the top menu, and then right click on Contact List shown on
the left hand side and choose Chat. If this is the first time you have used Web
Messenger then you will need to sign up for a Messenger account (see the Computer
Power Student E-mail System Student Guide on how to do this). Choose one of your
contacts to chat with (only available if one of your IM contacts is online and they have
accepted an invitation from your to become a IM contact). You can also choose to chat
with the contact for the group e-mail which will allow you to chat with any group
members who are online.
WINDOWS LIVE GROUP SKYDRIVE – SHARE DOCUMENTS

Every team member can share a file with anyone in your GDP group from their personal
SkyDrive. They can then set permissions for access to files. Files can also be placed on
the team’s SkyDrive for sharing between members. This feature is very useful when
team members are collaborating on parts of the GDP report, or even the whole GDP
Report document.
A good idea is for the Team Leader to create a number of folders on the Groups
Windows Live SkyDrive (see the Create GDP Folders section in this guide), and then
share these folders with the other team members in the group. The GDP Supervisor will
create some folders for the team at the start. GDP documents can then be stored in
these locations, which the GDP Supervisor will have given access to. Individual team
members can work on documents and upload new documents from their computers or
own SkyDrive, or update documents already in the share to the GDP Windows Live
Groups SkyDrive site.
With shared folders and a Groups SkyDrive, the whole group can upload, download, and
collaborate with each other on documents and other files.
1. Visit http://yourgroupname.groups.live.com/ and login with your Computer Power

Windows Live account and it will load up the group site.
Or
Visit Windows Live Groups at http://groups.live.com, logon with your Computer

Power live account, and then click View your groups, and then click the name of
the group.
2. Click on the SkyDrive link on the left of the screen.
Because SkyDrive is the backend to Windows Live Photos, any photos that you upload
to the Windows Live Group using the Photos link automatically reside there. Uploading

other content to SkyDrive can be as easy as dragging and dropping the files from your
computer onto the Web.
If the folder already exists on the Groups SkyDrive, then open it, and skip to Step 6. If
you wish to create a new folder on the Groups site, continue on with Step 3.
3. Click on Create Folder.

4. Fill in the Name field. Use the drop-down menu to indicate with whom you want to
share the folder. Options are: Everyone (public), My network, Just me, and Select
people. To add your team members and the GDP Supervisor, you the Select
People option, to add them from your Contact List contacts. You can also control
the level of access that they are given, but you will want your team members to be
able to read and add new document as a minimum.
5. Click Next.
6. Now add files to the folder. Simply drag and drop files into the Drop files here
area. Or, you may click on Select files from your computer to browse folders.
7. Click Upload when you have selected the files you wish to upload.
8. Click Send a link.
9. In the To field, enter the team members and GDP supervisor Computer Power e-
mail addresses or add them from a Category (a Windows Outlook Live Contact List
Group). You can include a message about the files.
10. Do not select Don’t require recipients to sign in with Windows Live ID,
otherwise every person who you send the link to will be able to provide the link to
others who can access the folder without being in your team. Since you only want
the team members and the GDP Supervisor to access the files, you do want them
to sign in with their Computer Power Windows Live logon.
11. Then click Send. You will receive a send confirmation.
You can also create Groups in Outlook Live Contacts (these are not the same as
Windows Live Groups or Outlook Live Contact List groups), which function the same way
as Categories, but they will not appear as contacts in Windows Live Groups, SkyDrive,
or Web Messenger. Using a Contact List Groups is better, since the Contact List Groups
(not the same as a Contacts Group) created in Windows Outlook Live, are available to
you in all other Windows Live services and appear as user Categories that you can
select in Windows Live Groups when sending messages or creating invitations.
If you wish to create a group in your address book in Outlook Live to store contacts, see
here http://help.outlook.com/en-us/140/bb899467.aspx for help.
UPLOADING FILES
SkyDrive folders are good for storing and organising things, and you can upload pretty
much any type of file to the folders on your SkyDrive. The main limitation is that the
maximum file size you can upload is 50MB. The other limitation is that you are limited in
total storage space to 25GB.
There are two ways to upload a file. There is a standard upload page and there is a
Windows Live Upload tool that can be used. Either method will let you upload your items.
The Windows Live Upload tool gives you the ability to do it by dragging files from your
local system and dropping them within an area on a page within your browser. In the
following sections, you’ll learn how to use both ways to upload an item.

UPLOADING USING THE STANDARD UPLOAD PAGE

When you first create a new folder, you are prompted to start adding files. At that time,
you can click the link to begin the process. Alternatively, to start adding files to your
SkyDrive, you can first go to the folder where you would like to upload them. Once there,
you can click on the Add files option. In either case, the result should be nearly the
same.
You have the option to upload up to five files at a time. To upload a file, click on the
Browse button. This will open a standard Windows dialog box. You can navigate to the
document, or other file that you want to upload to your SkyDrive. Once you’ve found it,
select it and click Open. This will place the filename in the dialog box. Once you’ve
selected a file, the Upload button will be enabled so that you can begin the upload
processes. You can choose to select additional files or upload them at any time. Once
you’ve entered up to five files, you can click the Upload button. This will start the
uploading process.
You should note that very few details are given during the uploading processes.
Additionally, if you are uploading large files, the process can take several minutes,
depending on your Internet connection. You can look at the browser status bar to see
part of the status of the upload. Otherwise, you have to sit and wait.
Once the files have been uploaded, the folder where you started the process will be
redisplayed with the new items in it. You should note that these items have been copied
from your computer. Thus, they now reside in both places. This means that you can
manipulate them on your SkyDrive, and this will have no impact on the files on your local
computer.
UPLOADING BY DRAGGING AND DROPPING FILES

Microsoft Live SkyDrive has an easier way to select and upload files. You can drag files
from your local computer and drop them onto a location within a browser window. This
drag and drop option can be used as an alternative to the standard upload dialog in the
previous section. To enable dragging and dropping in SkyDrive, you need to install the
Windows Live Uploading Tool.
Go to any folder on your SkyDrive and click Add files. At the top of the window you’ll
see an Install the upload tool option. Click on the Install the upload tool option. This will
start the process for installing the tools by displaying a prompt asking if you want to run
or save a file. Click the Run button to get the installation started. You should then follow
any instructions presented. Once the tool has been installed, the dialog you see for
uploading files will have changed.
You can now drag files from other Windows applications such as the Windows Explorer,
or from your Desktop onto this browser page and drop them into the area marked as
Drop files here. Because you are using Windows dialog boxes or your desktop, you can
use standard Windows selection techniques to select more than one file at a time.
As you drag the files over to the browser and their icons are added, be aware that the
files have not yet been copied. Rather, they are simply ready to be copied. The top
portion of the dialog now shows the icons for the files that are to be uploaded. The area
to drop new files is now smaller and is below the icons. You can continue to drag and
drop additional files into the drop area. If you find that you dragged and dropped a file
you didn’t want to upload, you can click the X in its upper-right corner. This will remove
the item from the file uploading tool, and thus it won’t be uploaded.

Once you’ve selected all you want, you can begin the upload process by clicking the
Upload button. The uploading tool shows you the progress of the upload as well as
provides a button that you can use to stop the uploading processes. Once the uploading
is completed, you will be shown the SkyDrive folder with the new items added.
VIEWING AND SORTING FILES

Once you’ve added many files to a folder on your SkyDrive, it can begin to get a bit
cluttered. To help with this you have options for viewing what is in a folder as well as for
sorting what is in a folder. You generally have three options for viewing the items in a
folder on your SkyDrive. The view options are for Icons, Details, or Thumbnails. You
can change the view by selecting the View drop-down menu above the file icons within a
folder. The default view is Icons.
Similar to changing the view, you can also sort the items in a folder. To sort items, you
can use the Sort by drop-down list provided in the folder navigation. This will let you sort
your files in a variety of ways. To do a simple sort, you can select Name, Date, Size, or
Type, and the items will be sorted accordingly. Once you are satisfied with the order, you
can click the Save button to be returned to the folder. If you decide you don’t want to do
this custom sort, then you can click the Cancel button to ignore any changes you might
have made.
Manipulating your Files
You have the ability to directly manipulate files on your SkyDrive. To do any of these
actions, you should first select the item you want to delete, move, copy, or rename.
When you click on an individual item, it will be displayed on a page with a menu to
perform each of these actions. There might actually be additional items displayed. For
example, if a photo is selected, then there will also be menu options for doing a slide
show, for tagging, and more. If there are more options, they will be placed under a More
drop-down list.
Once you select a folder, you can choose a subfolder if one is available. You can also
choose to create a New folder in which to place the item. Selecting New folder within
the path box will allow you to create a new folder in which to place the copy. Once you
have selected the folder where you want to place the file, you can select the option to
copy the file into the folder. The folder you selected will be displayed with the copy
presented. The copy will have the same name as the original file, so you might want to
rename it. T EE
DOWNLOADING FROM SKYDRIVE

You can download an individual file, but you also have other options for downloading
files. When available, these will be presented in the options on the page you are viewing.
On folder pages with multiple items, you will be given the option to download all the files
as a compressed zip file.
To download a zip file, you select Download as zip file from the options. This might be
under a More drop-down or under a Download option on the More drop-down. Once you
select this option, you will be given a standard file download dialog box. Once
downloaded the compressed file will contain all of the files from the current folder.

SETTING ACCESS PERMISSIONS FOR SHARING FOLDERS

When you create folder and put files on SkyDrive, you can use different levels of
permissions. The permissions that are set in a folder at the base level of your SkyDrive
carry through to subfolders. Therefore, if you create a folder in the existing Public folder,
its permissions will be the same as the Public folders, which is public (everyone) by
default. Similarly, if you create a new folder in the Documents folder, then it will have the
same permissions as the Documents file.
In a subfolder, you can view its permissions by selecting the View Permissions option.
From the next page you can then determine who owns a folder and where the
permissions originate. If you want to change the permissions to a folder, you need to
change the base folder’s permission. You do this by first selecting the folder. Once
you’ve selected it, choose the Edit Permissions from the options that are presented.
This option might be located under the More drop-down. You will then be presented with
a page that will allow you to set the page’s permissions.
From this page, you can change permission for groups or for individuals. Also you can
click on the Clear these settings option to clear the customised permissions. You need
to click the Save button to finalise the changes.
GRANTING GROUP PERMISSIONS

From the Edit permissions page, you can set permissions for a group of people. There
are three primary types of groups you can set; everyone, a network, or a category of
people.
You can check the Everyone option to provide access to the most people. In this case,
you make the folder, any subfolders, and all contained items publicly available to
everyone. That means the world can view your files, but they don’t have access to
change them.
You can also choose to give permission to your network of people by checking the box
next to My network. This allows people in your Windows Live network to access your
files. These are people in your Windows Live Web Messenger contacts and Windows
Outlook Live Contact List contacts. If you select to give this group access, you can then
choose, to give this group access to either view files or to actually change and delete
your files. Therefore you need to be careful about what documents you give this level of
access.
Additionally, if you choose to give your network access, then you can also choose to
give your extended network access to view your files. Your extended network includes
your network and the contacts of those in your network.
The third group type that you can give access to is Categories. If you’ve set up
categories (which are Groups in your Windows Outlook Live Contact List contacts), you
will have the ability to select them and assign rights to them.
GRANTING INDIVIDUAL PERMISSIONS

If you want more control over who gets access to the files in a folder on your SkyDrive,
then you can assign access to individuals. To add individuals, you can either select them
from your contacts one by one, or you can enter their name or e-mail address into the
box for Individuals.

If you want to select them one at a time, then you should click on the text, Select from
your contact list. This will present a list of your contacts to select from. Each name will
be listed and can be selected by clicking the check box to the left. That will place the
name below the People box and then allow you to select whether the individual can view
or edit and delete files in the given folder and its subfolders.
You can also give permission to individuals who are not contacts in your profile. You do
this by specifically entering their e-mail addresses into the box specified on the page,
and then pressing tab or enter. This will add the individual and again allow you to
determine if they can only view files, or if they can edit and delete them as well.
Once you’ve set up the individuals and their permissions, you can click Save to save the
changes. If you added permissions only to individuals, you will be prompted to send a
notification to the people you added. If you don’t want to send a notification, you can
click the Skip this button to continue back to the folder with the new permissions in
place.
STORING YOUR BROWSER FAVORITES ON SKYDRIVE

In addition to storing files on SkyDrive, you can also store your favourites on SkyDrive.
Favorites are links to web pages and web sites that you like or want to keep track of.
You can add favourite links by adding them to one of the Favorites folders on your
SkyDrive.
Adding favourites is just like adding files. In folders set up for holding favourites, you will
be given the option to add or create a favourite just as you are given options to add
folders in the regular folders. When you click the link to add or create a favourite, you will
be prompted to enter a web address, name, and description. Once you save this
information, it will be stored in your Favorites folder for you to access later. When you
add a favourite, it will be listed in the Favorites folder.
OFFICE WEB APPS

Microsoft Office Web Apps are online companions to Word, Excel, PowerPoint, and
OneNote that give you allow you to work with your Office documents from virtually
anywhere with a supported browser.
To work with Office Web Apps and store files on the Group’s SkyDrive the steps are:
 Visit http://yourgroupname.groups.live.com/ and login with your Computer Power
Or
the group.
 Click on the SkyDrive link on the left of the screen.
 Click on any folder to open that folder to view files in the folder.
 Click on any line in the folder (don’t click on a files’ name, otherwise this will open
the file in View Mode) to select it. This will give you a number of options (see
Figure C-3) on the right hand side. You can view the file in the browser (using
Office Web Apps), edit it in the browser (using Office Web Apps), or open it with
the application if you have a local copy of the Microsoft application on your
computer.

Figure C-3
 If you click on the files’ name this will open the file in view mode (see Figure C-4).
From the View mode to enter Office Web Apps Edit Mode which allows you to
create content in the file, click Edit in Browser within the View Mode.
Figure C-4
 To create new files on the Group’s SkyDrive, simply click the icons for the office
application you wish to use at the top of the screen beside the label Create: (see
Figure C-3). This will take you to the Edit mode (see Figure C-5) and allow you to
create content in the new file. To open documents for editing in the Microsoft
Office application (if it is installed on your local computer) click Open in
(application) within the View Mode.

Figure C-5
New files can also be created by clicking Office at the top of the screen and making a
selection from the menu that appears. You can then use the Office Web App to write and
create content in the file just as you can in the Office Suite applications.
If the yellow security bar appears in Office 2010, click Enable Editing to edit a SkyDrive-
based document. When finished, click Save to synchronise changes back to the
SkyDrive folder.
NOTE: Files in the Office Open XML file format (.docx, .pptx, .xlsx, etc.) can
be opened and/or edited in Office 2007 and Office 2010. Office 2000, Office
XP, and Office 2003 users must install the Microsoft Office Compatibility
Pack from the Microsoft website in order to open these files.
Depending on the version of Office you use, certain features may remain
unavailable.
.
You can also follow the same steps from your personal SkyDrive to create new office
. and store them on your personal SkyDrive.
files
WORK ON SHARED DOCUMENTS

Windows Live allows you to use Microsoft Web Apps to edit documents online and to co-
author documents online with other group members.
With co-authoring in Office Web Apps and Office 2010, multiple authors can edit a single
document at the same time and stay in sync with each others' changes. SkyDrive-based
Excel and OneNote files can be co-authored in the browser using Office Web Apps.

SkyDrive-based Word and PowerPoint files can be co-authored using the Office 2010
applications.
To co-author an Excel file the steps to do this are:
 In the Class Project shared folder, click the New dropdown menu. Click Excel
workbook.
 Type a name for the new file.
 Click Save. The new Excel workbook will open automatically in the Office Web
Apps edit mode.
 To edit the file, type directly in the body of the workbook or use the tools available
in the Ribbon.
 You will be notified when another user opens the Excel file from SkyDrive. To see
other users who are active in the workbook, click the co-authoring notification
status area in the bottom-right of the window (see Figure C-6). Any changes
between users will save and update in near-real-time.
Figure C-6
 Click X at the top-right to close Excel Web App.
Word and PowerPoint documents can also be edited the same way, but if you want to
carry out shared editing, then when you have opened the file in Office Web Apps, you
must then click on the Open in PowerPoint or Open in Word buttons to allow this. This
will open the file using a local copy of Microsoft Word or PowerPoint from your local
computer. Thus you must have Office installed locally to allow co-authoring.
VIEW AND RESTORE DOCUMENT VERSIONS

If you wish to go back to an earlier version of a file that you created or edited using
Office Web Apps, you can do so by following these steps.
 Visit http://yourgroupname.groups.live.com/ and login with your Computer Power

Or
the group.
 Click on the SkyDrive link on the left of the screen.
 Click on any folder to open that folder to view files in the folder.

 Click on any line in the folder to select it (don’t click on a files’ name, otherwise this
will open the file in View Mode).
 On the right hand side, click on Version history (see Figure C-3).
 Use the version list to browse previous versions of the document.
 Click the version you want to restore. Click Restore.
WINDOWS LIVE CALENDAR

Besides using a Group calendar, you can also use your own calendar to keep track of
your personal GDP tasks or meetings.
ORGANISE MEETINGS WITH THE WINDOWS LIVE CALENDAR

1. In Windows Live click on the top drop down menu. Click on the Calendar.
2. Click the Month tab and select the date for a meeting with your GDP team or a
member of your team, or the GDP Supervisor.
3. To change month click the arrow> next to the arrow <back.
4. Click on the drop down menu New.
5. Click on the Event.
6. Enter the name of the meeting for the project in the What field.
7. Enter the location of a meeting of the group or group members in the field Where.
8. Enter the initial and final dates and time fields Start and End.
9. Click Add more details to invite people to appear at the event.
10. Click Invite people.
11. Enter e-mail addresses of people who would like to invite to the event and click To.
12. If you click the To, the tab People, tick the contacts you want to send them a link
or column option Select All.
13. Click Close.
14. Drop down menu click Send Reminder.
15. Click to select No Reminder or early period of the remainder.
CHANGE A MEETING TO A RECURRING MEETING

You can also make a meeting into one that occurs regularly as follows:
1. Select the meeting on your calendar.

2. Select Set recurrence.
3. Click on the drop down menu Occurs.
4. You can choose how often the meeting would take place. Click Weekly for
example.
5. Click the Ends button to select when the meeting will cease to be repeated. You
can set it to stop after a certain number or certain dates.
6. Click Save.

The meeting will be visible in your calendar.
OTHER WAYS TO SCHEDULE MEETINGS

You can also use the Outlook Live Calender to schedule meetings. For help with this see
http://help.outlook.com/en-us/140/bb899606.aspx.
You can also use the Outlook Live Scheduling Assistant to schedule meetings. Help with
this can be found at http://help.outlook.com/en-us/140/bb899639.aspx.
Further information on using Windows Live Groups and the related Windows Live
Services can be found in the Computer Power Student E-mail System Student Guide.

COURSE AND WORKSHOP EVALUATION SHEET
Your comments help us improve course objectives, content, and instruction.
Name(optional): __________________________ Course Title: Group Development Project
GDP
Qualification/Shift: ________________________
Date: ___________________________________ Campus: ___________________________
Objectives
Did the course/workshop meet its stated objectives?
 Yes  No If no, please explain
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Did the course/workshop meet your needs?

 Yes  No If no, please explain
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Course/Workshop Evaluation
How would you rate: Poor Fair Good Excellent
Course/Workshop content 1 2 3 4
Quality of instruction 1 2 3 4
Overall satisfaction 1 2 3 4
Relevance of Activities 1 2 3 4
Suitability of Training Facilities 1 2 3 4
Quality of Facilitation 1 2 3 4
Usefulness of Learning Guide(s) 1 2 3 4
Usefulness of Resources 1 2 3 4
Comments and suggestions for improvement

What did you think was most beneficial about the course/workshop?
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
Continued on the next page.
What did you think was least beneficial about the course/workshop?
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Please identify by topic any information that should be added, deleted or improved (e.g. form,
clarity, pace, depth, sequence) and explain.
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Please add any extra comments you may have in the space below.
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
___________________________________________________________________________
Thank you for taking the time to complete this form, we use the information gathered to
continually review and improve the courses and workshops to make them as relevant and
useful as possible.

Gdplga006a PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gdplga006a PDF

Загружено:

Авторское право:

Доступные форматы

®

Group Development Project

Edition Released: January 2012

Publication No.: GDPLGA006a

SECTION 1: PROJECT ORGANISATION ................................................................. 1-1

Topic 1: Introduction .................................................................................................... 1-2

Topic 2: Making a Beginning ....................................................................................... .1-8

Topic 3: Project Deliverables ..................................................................................... 1-17

Topic 4: Communication ............................................................................................ 1-22

Topic 5: Assessment.................................................................................................. 1-26

SECTION 2: PROJECT FUNDAMENTALS ................................................................ 2-1

Topic 1: Definition of a Project ..................................................................................... 2-2

Topic 2: Project Constraints ........................................................................................ .2-3

Topic 3: Project Overview Statement ........................................................................... 2-5

Topic 4: Development of the Project Workplan .......................................................... 2-13

Topic 5: Monitoring and Controlling Progress ............................................................ 2-18

Topic 6: Closing the Project ....................................................................................... 2-20

SECTION 2: WORKING IN A GROUP ....................................................................... 3-1

Topic 1: Elements of a Group ...................................................................................... 3-2

Topic 2: Leadership ..................................................................................................... 3-6

Topic 3: Group Decision Making .................................................................................. 3-7

Topic 4: Establishing a Strong Team ........................................................................... 3-9

SECTION 4: ADMINISTRATION ................................................................................. 4-1

Topic 1: Team Personnel Problems ............................................................................. 4-2

Topic 2: Summary ........................................................................................................ 4-4

APPENDIX A: RESOURCE MATERIAL ....................................................................A-1

APPENDIX B: SYSTEM DEVELOPMENT PRACTICES .............................................B-1

APPENDIX C: WINDOWS LIVE GDP GUIDE .............................................................C-1

 Determine and confirm a client’s business expectations and needs

 GDP Trigger (GDT) – 5 hours

GDPLGA006a Computer Power Plus iii

 GDT Final Exam (Compulsory) – (0%)

 GDP Project (Compulsory) - (100%)

Assessment for this course is made up of 3 main items:

iv Computer Power Plus GDPLGA006a

Learning guide layout

Hot tip icon

GDPLGA006a Computer Power Plus v

Day Reference Topic Subject Time Dates I will Date

S4 T1 Team Personnel Problems 10

vi Computer Power Plus GDPLGA006a

On successful completion of this section, you will be able to:

1. Explain how the GDP is set up

GDPLGA006a Computer Power Plus 1-1

The Group Development Project is Different!

However, as an IT professional, you will almost certainly be required to work in a team.

The GDT and GDP Combination

 Group Development Project Trigger (GDT - 5 hours)

 Group Development Project (GDP - 45 hours).

What the project is about

1-2 Computer Power Plus GDPLGA006a

Your Goal for this Course

Feedback from previous GDP students

The GDP applies in industry more than we might think.

GDPLGA006a Computer Power Plus 1-3

I really learnt a lot.

Comment: Here’s the End Of Project Report and Review.

This exercise is bound to impress any prospective employer.

Employers like the GDP.

Communication is a major factor for success!

The GDP has helped us grow into stronger individuals.

I’ve seen documentation similar to what we worked on in the GDP.

1-4 Computer Power Plus GDPLGA006a