Category: Case Study

Case studies 10th week was a presentation from each group on the progress of their applications. Considering the career paths of most graduates from this course will not place a high value on presentation skills, I thought the standard was quite good. I am not 100% sure what the purpose of this assessment was but all the groups managed to ‘fake’ it pretty well.

Now all we have to do is submit the technical documentation on Thursday and then start preparing the final prototype. We have not received assessment criteria for either of these which is verging on irritating.

Week 9 of case study had no seminar. The tutorial was focused on assessing group progress thus far.

We are doing OK but still have some major hurdles. Upon review of our work thus far some major floor stand out and issues with moving to a working prototype. I imagine over the mid-semester break a full work over of the project will be required before moving to a working prototype which represents 30% of the final mark for the subject.

Case study’s week 8 lecture looked at documentation. This feature has been recognized as a critical factor for IS success and as a major separator between professional and amateur work.

Some key documentation includes:

• User Manuals (End User, Staff, Administrator)
• Installation Guide
• Integration Guide
• Troubleshooting Procedures
• Operational Procedures
• Test Plan + Test Results

For complex Information system completing all of the above documents in full detail would be very costly and time consuming which is a major reason why documentation is rarely complete.

For our Web Application we are required to complete the documents with a lite version test plan.

Case studies seventh week was a tough one. A large group submission was due which took a lot of time and planning, however the end product was not of a very good standard.

Although this can be frustrating it is worth analyzing why we, as a group failed to return a high quality submission. I have identified some of the factors that played against us:

Team Management factors:

• Lack of motivation – At each stage of the assignment we all lacked motivation (some more than others). In ‘real-life’ environments there is generally either a financial motivator or ethics (in the case of volunteers).
• Lack of a common goal – Not all of our team has the same goal for the subject, so whilst a team member may be achieving their goals the group may fall short of other members’ goals.
• Lack of defined consequences –  If a team member failed to perform, there was not defined consequence. This is something we should have defined clearly.

Individual factors:

• Ability and Knowledge – Most companies have a minimum of 5 weeks training plus 3 month probation for any complex jobs. I can now understand the value of ensuring team members possess the tools they need to do a job. Relying on team members to ‘pick it up as they go’ can work out well but is very risky.
• Clear communication – If something is not going well it is the responsibility of the team leader to identify this and amend it. Staying calm and positive may not be the best way to communicate impending disaster.

There is a lot more to team dynamics than this but these are some small points that I took out of the last task.

Week 6 of case study consisted of a lecture and tutorial by Enjoo Lim. The lecture reviewed the basics of Database design which was a nice refresher. Points covered were:

• Conceptual modelling
• Logical modelling
• 1st normal form
• 2nd normal form
• 3rd normal form

After last semesters assignments going to BCNF is a fairly straight forward operation. From our experience on this assignment it is clear that if you dont get the conceptual model right none of the subsequent stages will go smoothly.

The tutorial gave us some time to work in our teams on the task due the following week. At the time of writing this I am compiling our Functional Specification report. There is a clear difference in the level of each teams memebers submissions, to the level that to attain and even level throughout the report would require redoing entire sections. From doing this assigmnet I have found that Object Oriented modelling for Web sites does not fit the same as for a stand alone java program. I will need to do some research on modelling for web systems.

In week 5 of Case Study we discussed risk. There are a number of risks associated with system development, most stemming from:

• communication between client and  developers
• team issues within development team
• inability of client to clearly define and agree on system requirements

Reviewing these risking and mitigating or managing them is critical for the success of system development.

In regards to Project we are working on as a team I am really finding that it is taking too much of my study time for the lesson that working in teams is difficult. At present my main goal for the unit is to pass whilst preventing it from adversely affecting my grades for other subjects.

Case study’s fourth seminar analyzed the Functional Requirements Document,  ensuring student have the knowledge to complete task 3.

The main features of a Functional requirements document are:

• • Database design
  • Business Logic Layer design (Best completed using UML in most cases)
  • Interface design
  • System requirements

The purpose of a Functional Requirements document is to reconcile what the client wants and what you plan to build. Once a client signs of on a Functional Requirements document, system design can be completed.

In the tutorial we continued work on our own Functional Requirements doc, after working on it almost all weekend I am still only about halfway through…

Time dedication to this subject was also discussed in the tutorial, I understand there is no exam for the subject so we should be spending more time on it. At present I am spending about 75% of my study time on this subject which is an issue for me. Will try and get most of the work done this week so I can complete other subject assignment next weekend!

Case study this week saw a review of some factors that influence the success and failure of projects. Specifically, the myki project undertaken by the Victorian state Gov’t.

There were some Critical Success Factors:

• Top Level Management Support
• Appropriate Training
• Top Level Project Team
• Organizational Change Management
• Implementation team
• Steering Committee

I find it a bit leery to conclude from the point about that to make a project successful it simply must have all of those factors clearly defined. Obviously there have been countless projects succeed before a consulting firm decide to label the common phenomena of successes. With that in mind the causality of the point above on the outcome of the project come into question… are the point above something that can be put in place to help ensure Project success OR will a successful project foster the development of the points above. I imagine that the actual causality is not a one way street but the point is that having a consultant come into your company and pontificate the importance of those dot points is unlikely to provide significant improvements.

From my experience I would argue that critical success factors are:

• Accurate definition of the issue that needs to be solved
• Cohesion amongst all parties involved (achieved through specification document and a single final decision maker)
• Capable individuals
• Macro-management of capable team members
• The ability to remove non-functioning member from the team

The tutorial comprised of group work, meetings and presentations. The next submission is due this comming Thursday.

We got our first submission in on time this week. There were however some issue with version control, but we learnt our lesson and this submission is not hugely important. The next task our group of 4 faces is the submission of a Business Case proposal. 

Our discussion has been positive with good insights from all memebers. I am however a bit concenred that we lack the technical skills to implement a ‘working prototype’ of the system. This concern is compounded by the fact that our seminars will not at any stage cover anything technical.