Things that WORK: Production process: Programming split between high level project work and low level tasks. Weekly work plan assigns staff and communicates decision making points. PM(s) helpful. Delineation between design and technical teams. Get projects done quickly. No major communication barriers; production group located together. Bug tracking system in place. Knowledge: Willing and talented staff. Flexible staff able to handle sudden issues. Richard's fusebox like framework. Source code control system.

Things that WORK:

Production process:

Programming split between high level project work and low level tasks.

Weekly work plan assigns staff and communicates decision making points.

PM(s) helpful.

Delineation between design and technical teams.

Get projects done quickly.

No major communication barriers; production group located together.

Bug tracking system in place.

Knowledge:

Willing and talented staff.

Flexible staff able to handle sudden issues.

Richard's fusebox like framework.

Source code control system.

Things that DON’T work: Communication: Gap between design & tech; designers involvement in project stages and design tasks assigned to programmers. Process: "Brain strain" when change from urgent tasks to other longer term work. Need to use industry accepted software development processes. Quality control: no structured testing process. Standard variable naming conventions and scopes (space or tabs in code) Supporting Systems: Lack a system to support and enhance development & hold project data. Equipment & technical references out of date. Lack a high level project-wide development view of projects. Knowledge: Hard to apply fixes and share (design) source codes. Ad hoc staff development. Restricted ability, or barriers, to raise or implement new ideas.

Suggestions: Version Control: Restricting programmers to make specific changes in the CSS may slow the whole project progress. Instead: allow tech team to make small changes (if necessary) BUT HAVE TO comment the changes in the CSS or template so that it can be rolled back to the correct version. Create a backup of CSS/ template/ objects/ scripts and post it in UTSOnline by creating a section(s) for keeping backup of every project. Standardised administration site layout/template. There should be another place like bug track for "Request Tracking" to hold small changes from the client for programmer to select tasks and clients to confirm approval.

Suggestions:

Version Control:

Restricting programmers to make specific changes in the CSS may slow the whole project progress. Instead: allow tech team to make small changes (if necessary) BUT HAVE TO comment the changes in the CSS or template so that it can be rolled back to the correct version.

Create a backup of CSS/ template/ objects/ scripts and post it in UTSOnline by creating a section(s) for keeping backup of every project.

Standardised administration site layout/template.

There should be another place like bug track for "Request Tracking" to hold small changes from the client for programmer to select tasks and clients to confirm approval.

Suggestions Process: Define different difficulty levels (eg. programming hard/middle/easy or design hard/middle/easy) and consider their priority (high,middle,low urgent), then meet to discuss how to assign the tasks and supply the "task map" so we all have a clear idea what we are doing, how and when required. Intermediate person between programmers and designers who have the ability to communicate effectively in both direction, like a kind of link between them so both sides can agree the best solution for the situation Technical direction and context: Projects divided into smaller sized tasks need a map to describe relationships between those small tasks and our goal. An "Innovation" day every 2 week for team to demo new ideas.

Suggestions

Process:

Define different difficulty levels (eg. programming hard/middle/easy or design hard/middle/easy) and consider their priority (high,middle,low urgent), then meet to discuss how to assign the tasks and supply the "task map" so we all have a clear idea what we are doing, how and when required.

Intermediate person between programmers and designers who have the ability to communicate effectively in both direction, like a kind of link between them so both sides can agree the best solution for the situation

Technical direction and context:

Projects divided into smaller sized tasks need a map to describe relationships between those small tasks and our goal.

An "Innovation" day every 2 week for team to demo new ideas.