Silver-Owl Keeping an informed eye on your projects

Silver-Owl

Keeping an informed eye
on your business
Silverstar Software Ltd.

Our values

Be straightforward
Avoid buzzwords
Our values - Be straightforward - Avoid buzzwords

Workflow and Change Control including Fault tracking and Process management

Screen size

This website is designed to accommodate users with a 1024x768 screen size.

If you have a larger screen and the images below look slightly out of focus CLICK HERE to see larger, clearer images.

Summary

You can describe and track work that needs to be done
or record and track the resolution of faults or problems with Silver-Owl

How to use this section

You can either read through and scroll down through the screen images and associated commentary
or go direct to the bit you are interested in by clicking on the links below:

All users are able to the following if they need to, potentially on a day-to-day basis:

Describe and update details of a piece of work
Provide optional supplementary information
Sign-off a Work Item at the end of each stage, or withdraw it
Use the powerful Index to find relevant Work Items

Project Managers might do this on an occasional basis:

Track work on specific Systems and Modules if you wish to
Track which work was incorporated into each 'Drop' (Release/Version)

Senior Managers would do this occasionally:

Define Templates that each Process or type of work must follow

Work to develop or change Systems or Modules is carried out by 'Change Teams' for 'Sponsoring Team'

Change Teams and Sponsoring Teams are just like any other Project Team, and can be the same people or team

Each Work Item starts with a Title and is related to a system and assigned to a Change Team

It may relate to anything; fixing a fault, changing or creating something new

Work Items may even be used to record dealings with an external customer or supplier

 

The requirement of the work or change is described or may be referenced in an external document

As the work progresses through the stages required by the template it is following ...
... an assessment of the work required, plus costs, effort, timescales etc. may be added

Progress may be documented, and as each stage is completed, it is signed off

 

Users can optionally document reasons why a change should, or should not be carried out

These can include functional benefits, or technical issues or conflicts that might arise

These factors can be used by a review body to decide if the proposed work should go ahead

 

As work is progressed you can optionally identify the modules that have changed, and why

This offers a useful audit trail for the future

 

If questions arise as the work is progressed, they can be documented as Queries

You must indicate the stage by which each Query must be resolved, otherwise it cannot be signed off

 

Whilst waiting for a Work Item to be progressed, a temporary Workaround can be documented

This is particularly useful if the work relates to fixing a fault

 

The Sign-off history is recorded and can be viewed at any time, forming an audit trail

This shows when each stage was signed off and by whom, plus who started and finished the work

 

A Work Item can be withdrawn by giving a reason ...
... or can be 'Sent Back' to a previous stage as long as the reason is documented as a Query

This negates the signoffs between the two stages, although they remain in the Sign-off History

 

All Work Items are included in an Index which can be filtered by Sponsoring or Change Team

The Index shows key data and can be sorted on any column

A Sequence Number, allocated by the Change Team, indicates the intended order of work

 

Work and Change can be carried out on Systems

A System may be a computer system, a Quality Methodology, a set of related documents or forms etc

Each System may be divided into Sub-Systems and/or Modules, if required

 

Each System may consist of any number of Modules, of any Type you define

These are used to help you keep track of which elements of a System get changed, how and when

Modules can be anything, e.g. documents in a Quality System, I.T. code and files, reports, forms etc

Use of modules is optional when using Silver-Owl

 

All work (new development, changes or fault fixing) may be documented as a series of Work Items

Each Work Item is incorporated into a 'Drop' (or new version or release)

The manager responsible for each System can define each drop

 

You can see which modules have changed in each Drop, and which Work Item caused the change

Another similar screen details progress on work items not yet finished in each drop

They can exclude completed tasks to make the easier to read

 

All work follows a process, and Silver-Owl allows you to define up to 250 process Templates

Each Template can have up to 250 stages which you can define

Each stage consists of entering or updating certain information about the work done, or to be done

At the end of each stage, you indicate who must 'sign-off' the work to show that it is complete

 

Various pieces of information are common to all Templates and their presence may be validated

Additionally, you can define some supplementary fields which may be different in each Template