Professional Documents
Culture Documents
Gdplga006a PDF
Gdplga006a PDF
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.
CONTENTS
i
Table of contents
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:
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:
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.
A more detailed breakdown of each assessment component and its weighing is provided
below.
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.
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.
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.
HELPFUL INFORMATION
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.
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.
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
Final Assessment
1.0 SECTION 1
PROJECT ORGANISATION 100 mins
OBJECTIVES
TOPICS
1. Introduction
2. Making a Beginning
3. Project Deliverables
4. Communication
5. Assessment
TOPIC 1: INTRODUCTION
15 mins
Welcome to the Group Development Project Trigger (GDT) course and the Group
Development Project (GDP) course.
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.
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 GDP course appears in your qualification schedule as two separate entries:
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.
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.
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
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.
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.
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.
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.
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…
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.
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!
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.
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.
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:
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.
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
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!
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.
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.
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.
Within these phases are several review steps where the team’s performance is
assessed.
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
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
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:
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.
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!
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
Problem
Definition
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
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.
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.
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.
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.
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.
So in summary here is a list of the submissions that must be made as part of the GDP
course:
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.
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.
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.
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.
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).
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.
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.
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.
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.
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:
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.
Table 1-2
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.
Table 1-3
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.
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
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 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.
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
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.
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.
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.
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.
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 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.
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.
Identify all the stakeholders within the business as well as external stakeholders
who may have an interest in or be affected by the system.
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.
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.
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.
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
<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
Timeframe
Resources
Conclusion
Figure 2-2
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.
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.
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.
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.
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.
Site Preparation
Clear and level site 5 days All
Building Construction
Build Foundations
Pour Concrete 2 days Yuri & Haobi Readymix Concreters
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
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.
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.
In Appendix B you will find guidance on creating system design and implementation
plans.
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.
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:
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.
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
TOPICS
1. Elements of a Group
2. Leadership
3. Group Decision Making
4. Establishing a Strong Team
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.
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.
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.
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:
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:
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.
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.
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.
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.
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.
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:
4.0 SECTION 4
ADMINISTRATION
15 mins
OBJECTIVES
TOPICS
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
DFD Guidelines
In addition to the above rules, you should also keep the following in mind when
designing DFDs:
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.
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.
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.
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:
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.
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:
Or
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.
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.
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.
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.
B APPENDIX B
SYSTEM DEVELOPMENT PRACTICES
“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.
“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.”
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
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.
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.
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.
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.
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
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 key issues that the project manager must document in the plan are:
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
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.
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.
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
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.
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.
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.
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.
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:
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.
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).
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.
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:
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:
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.
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:
What are the version numbers of the software components in version x of the
system?
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.
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.
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.
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
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.
It is mandatory that the user interface includes access control mechanisms to restrict
entry to authorised users.
Requirement statements that are concerned with functionality of the system are system
requirements. Below are two examples of business requirements:
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.
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 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.
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:
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:
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.
It is mandatory that the system provides a user friendly and intuitive interface.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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:
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.
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.
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:
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.
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 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.
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.
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.
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.
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.
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:
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.
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.
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
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
Reviews can cover many areas, but two common ones are:
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:
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.
C
APPENDIX C
WINDOWS LIVE GDP GUIDE
Introduction .............................................................................................................. 2
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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).
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:
In progress - A task that you are working on but has not yet been completed
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.
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.
1. Visit Windows Live Groups, click View your groups, and then click the name of
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.
To start a discussion:
1. Visit Windows Live Groups, click View your groups, and then click the name of
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.
1. Visit Windows Live Groups, click View your groups, and then click the name of
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.
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.
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.
Or
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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
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.
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
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.
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
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.
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.
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.
Objectives
Did the course/workshop meet its stated objectives?
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
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.