HomeMy WebLinkAbout1988-0500.Ford & Tratnyek.90-11-29 ONTARIO EMPLOY¢-S DE LA COURONNE
~ CROWN EMPLOYEES DE L'ONTARIO
GRIEVANCE. C,OMMISSION DE
SETTLEMENT REGLEMENT
BOARD DES GRIEFS
180 DUNDAS STREET WEST, TORONTO, ONTARIO. MSG 1Z8- SUITE2100 TELERHONE/T~'L~-PHONE
180, RUE DUNDAS OUEST, TORON. TO, (ONTARIO) MSG IZ8 - BUREAU 2100 (416) 598-0688
500/88, 523/88
IN THE MATTER OF AN ARBITRATION
Under
.THE CROWN EMPLOYEES COLLECTIVE BARGAINING ACT
Before
THE GRIEVANCE SETTLEMENT BOARD
BETWEEN
OPSEU (Ford/Tratnyek)
Grievor
- and -
The Crown. in Right 'of Ontario
(Ministry of Community & Social Services)
Employer
BEFORE: J. Emrich Vice-Chairperson
M. Vorster Member
A. G. Stapleton Member
FOR THE K. Whitaker
GRIEVOR CounSel
Ryder, Whitaker, Wright & Chapman
Barristers & Solicitors
FOR THE S. Wh'ite
EMPLOYER Counsel
Legal Services Branch
Ministry of Community & Social
Services
HEARING: October 12, 1989
December 7, 1989
June 5, 7, 1990
Placed Oefore the panel were two grievances claiming cIassific~4ticn at
the higher level of the Systems Officer 3. It was agreed by the par. ties
that the grievance of Mr. T~atnye~ would be treated as representative, and
the evidence pertaining to ~is grievance would be determinative of t, he
outcome of both grievances.
Since Janusry 21, 1985, the grievor has Peen claSsified as a Systems
Officer 2 (S02) in t~e Management Systems and Services Group, Administrative
Services Category. His position title is Programmer/Analyst and he iworks in
t~e Systems Development Section of t~le Strategic Systems Develo~nent Branch,
in the Information Systems and Applied Technical Division of the M£n~istcy of
Co~u~ity ~nd Social Services. In ~ay, 19~k3, he was assigned to work as a
member of the ~eam working on th~ Service Provider £nventory Project (S~£).
The grievor c~aims t~at the wor~ he performed while appointed to
project would 'enti6te him to the higher classification of Systems Officer
(S03). 'In the alternative, if the grievor's work does not properly
either the S02 or $05 class standards, th~ Union as~s the Board ~o o,~der
the Employer to find or create a classification that would De appropr'iate,
in accordance with the remedial powers approved Dy the Divisional Court
sitting in review of the Board's decision in OPSEU (Carol Berry et al.) and
Crown in RiEht of (tlt~io (Ministry of Com~n~ity ~nd Px~cia~ ~er¥ices),
2T~/83 (reasons for judgment released March 13, 1986).
'Pne Service' Provider £nYento~y (SF~) was desisqed to operate as
repository for i~.formation concerning entities o~erating with govern~Yent:
fielding or raider license from the Ministry and providing services within the
mandate of the Ministry to administer - for example, Children's Aid.
Sobieties, and children's mental health and treatment centres. There wei,e
several phases to the project. From May 1986 to the summer of 198'7, a
version of the inventory was designed and developed for microcomputers using
the personal compute~ language PC Focus. This was an independent data base,
not meant to interconnect with other computer systems. In August, 1987, all
of t~e pro~ect 'team, except fcc the grievor, switched to developing t~e SP£
for use o~ a minicomputer system. The g~ievor remained ~or~ing ca the
mic~ocompute~ version doing the roll-up of data from the area version, to
the regional and corporate versions and developing five read-only corporate
versions. /he grievo~ moved to ~he microcomputer phase of t~e SPI project
in August, 1989. However, ~ne gravamen of the grievor's case is .that the
work he performed on the microcomputer versio~ of S~£ warrants his
classification at the S05 level.
Shortly after the g~ievor filed his g~i. evance on April 6, 1988, a icc
audit was conducted and a new Position Specification was der@loped in July,
1988. The grievor took exception' to certain .aspects of the description' of
bis work as represented ~y the new Position Specification, although it was
acknowledged to De more accurate t~an ~he Position Specification dated
December 27, 1983. Ihe July: 1988 Position Specification describes the
grievor's work as follows:
2
In his testimony, the grievor indicated that he found himself workir~=~
~lder very loose supervision and independently of the other project
members. He acknowledged that ne r@ceived technical guidance from
White, the Project Leader. He also agreed with the purpose stated for,
position in Section 2 of t~e Position Specification, although b~ point'ed out
that he ~or~ed alone and not with otaer team members. He stated that of
duties and responsibilities outlined in Section 3 of the Position
Specification, he performed most of the ~asKs set fort~ in' suDseotion
5(3), 5(4) and 5(?). He indicated that he did no~ carry out t~e tasks se~
forth in 5(1) to any grea~ e~tent, although he ~ad regular con,act with Jonn
Van V~iet who acted as a user representatiw during' the project. In respect
to suDseotion 3(2) of the Position Specification, the grievor admitted~ that
he did not provide comments or suggestions as to the physical data Das~
design, nor did ~e wor~ with user representatives ~o define the genera'.l
system security of the application. He. did not carry out any related
special projects as described in subsection J(5) nor did ~e provide
technical guidance and training to junior programming staff as se~ curl,in
3(~), nor did ~e perform other related duties as descrioed in Section
The grie~o~ ~estified t~a~ t~e sKi~ls and wnowledge, outlined in Section 4 of
the Position Specification pertained to expertise wit~ minicomputers,
whereas his special expertise is with microcomputers using DOS and PC Focus.
However it is the class standard which is the determinative document !
for Classification. The 8card wil~ review the evidence in respec~ to the'
class standards applicable to ~he grievor's current cYassification and
target classification by Drea~ing down the relative descriptive elements of
these class standards to the compensaDle factors of: 1) scope of wor~;. 2)
5
supervision; 3) accountability; 4) impact of er.rots; 5) ~nowledge and
s~iils; and, 6) contacts.
1. Scope o£ Wori~
S02 SO5
Computer prog~mmmers ... senior progrsmme~s who ...
~ponsiOle for design of small design, develop and maintain very
programs or modules for large la.rge or complex computer-
programs' and for coding, programs ie. using a large numDer
testing, modifying and of files and performing a large
._m~_intaining computer programs, variety of computations, and
These employees may also capable of generating many
participate ia minor systems different output reports for a
analysis and design activities, large and diverse user group.
T~e m__~in dispute between'the parties centred upo. n whether the nature of
the programming carried out by the grievor could be characterized as large
o~ complex or whether it st%ould be characterized as a module of'a la~ge
program involving mi~or systems ~nalysis and design.
In chief and in qross-examihation, the grievor testified Ghat he was
required to program the entire SPI application for t~e roll-up of data from
the area office to the regional a~d then corporate levels. Furthermore, he
was responsible for creating corporate versions with a read-only function
(t~at is a program with the c~eabe, update and d~lete functions removed).
The grievor characterized the program as large, involving 20 to 25. logical
entities with 10-15 taOles, a large number of computations which stretched
the limits of memory in PC Focus, and which had the capacity to generate 50
to 1OO '.reports for a large and diverse user group. The grievor added that
although he was given no formal design requirements with illustrative flow
charts, b~ was made aware of t~e user requirements Oy his predecessor,
Howard Yin, and performed the requisite analysis and design informallf to
achieve the desired results in programming. He admitted that the original
corporate level version of the program with create, read, update and d~le~e
functions and taOles was designed by Greg Doran, but the grievor explained
that ne nad to develop extraction routines to create the read-only cor~porate
version, in so doing, the grievor relied on work ne had done when creating
an area version. He further acknowledged that in the process of creat:ing
t~e read-only corporate version, he was able to utilize T5% of the lin~s ,of
bode developed for the area and regional versions.
Mr. White was the Project ~eader for SP£ and was the person to whom the
grievor reported. He testified that ~ne grievor was nog responsiOke
general or detailed data design worK, but was responsible for program
design. Mr. Whigs defined general design as those tasks performed at tSe
outset of a project that specify want t~e entire system wil~ loo~ li~e. He
described this design doc,.,~ent as a tool for planning amd costing the '
Pro~ect. Mr. White described a "detail design" as t~e expansion of the
general design to incldde more functions. He defined program design as
entailing the mapping, translating and expansion of portions of t~e de~ailed
design into computer code. Mr. White produced a .document setting forg~ the
logical data model which illustrates the logical entities involved in the'
enti~e SP£ application and the relationships between the logical
~r. White claimed that the grievor was not responsible for crea~ing or'
modifying the logical data model for SP[. He explained gna~ tD~ grievor was
responsible for the program design for the roll-up of data from the ar~a,
to region to corporate office levels and for creation of a read-only-
corporate version wit~ fla~s fo~ contentious issues and fiscal subsidies.
H~ acknowledged that only the grievor and his predecessor in that
assignment, Howard Yin, had worked on these aspects of programming.. Mr.
White characterized the nature of the programming for the roll-up of data as
of mid-level complexity and the programming for the read-only corporate
version as of low-level complexity, since it primarily enbailed the deletion
of functions from the area and regional versions.
Mr. White explained that there is a relationship between the size and
comple×ity of a programming tasK. One measure of the size' of a computer
application is the nUmOer of logical entities upon whY'ch it operates. He
explained t~at as the number of logical entities increases linearly, the
numDer of relationships between these entities multiplies as a square.
Thus, the number of logical entities and number of. relationships between
these entities contriOutes to the logical complexity of a program.
Mr. White further noted that at the time the grievor was programming
for ~£, he was programming for a stand-alone personal microcomputer system
without any connection to other computer systems. Such communication, time-
sharing or connectability'would increase the technical complexity of the
programming task and may introduce security requirements, which the grievor
admitted he did not need for his assignment. In terms of logical
complexity, Mr. White estimated that a large project would involve more than
100 logical entities, a mid-size project would include 50, and a small
project would involve 5-10. The logical data model for SPI filed in
evidence shows 1~ logical entities involved in this entire application. ~rhe
grievor estimated that the SPI program included 20-25 logical en~ities.
The grievor offered no evidence in repl~ to contradict the numDer of logical
entities shown on the logical data model filed in evidence Dy Mr. White.
8
Finally, in cross-exam~_nation, Mr. White acknowledged that it wa~s the
grievor's job alone to build the computer code for the roll-up of data
the area, region, to the corporate versions and for the five differen~t read-
only corporate versions. For this latter function, Mc. White estimated t~at
80~ of the lines of code would De reproduced from the area version; ~he
grievor estimated 75%.
The preamble to the Systems Officer Series provides some guidanc.~
differentiation of the levels within the series. The following extra,cts
seem relevant to the issue of the size and complexity of the ~P[ project as
a whole and of the responsibilities and bas~s required of the g~ievor::
'The Systems Development Process
The high cost of technology for large computer systems
projects has necessitated a formal methodology for systems
development, wi~h clearly defined responsibilities at each project
phase. However, the same general methodology is applicable ~o
all systems development projects, regardYess of whether they are'
strictly manual, use automated office equipment o? complex
computer technology. The levels in the series reflect not only ~
increasing accountaOility and technical complexity, out also
increasing responsibility for the broader phases of this process,
In standard systems methodology the proOeCt development cycle
is composed of three major phases: (1) planning, (2) design, and
(5) implementation. On a large proOect, prior to t~e planning
phase a project proposal outlining the general systems oDjective~
and gross cost estimates will De prepared for approval Dy the
systems priority setting group in the ministry, or in some casesi
Dy Management Board. FollowinE this approval stage, the project'
is initiated.
1) ~he ~lanning phase involves an analysis of the client's
requirements and general definition of t~e oOjectives of ~he
system. On large projects t~is is usually carried ou~ by a highly
experienced systems analyst, who is often subsequently assigned to
manage b~e project. ~his step is usually followed up by an
advisability s~udy, ~o clarify objectives and loo~ at alternative
systems solutions: the segments of the system where automation '
could ~e beneficial to the client; availaO~e eqdipment and
software alternatives; t~e effects systems c~anges wou~d ~ave
within the organization, as well as the impac~ on other wor~ units
9
or systems; an approximate estimate of the development time and
costs involved, end the terms' of reference for tendering for
services. Once again, this is usually handled at a senior level,
often by the project leader or a senior analyst working Under
his/her supervision. The various alternatives are presented,
usually in written form, to the client, who then gives a formal
direction regarding how to proceed. Such projects will cons$itute
a major activity and resource commitment for the systems'
development group, and the formal agreement of the systems
director is usually required as well.
On a small project the planning phase is much less formal:'
the advisaOitity or "feasibility" s~udy is done by the analyst who
will also do the system design. Although alternatives may be
presented in a written form, an agreement to proceed with any of
these is usually arrived at throug~ informal discussions between
the analyst and the client.
2) The desi~;~ p~ase begins with a detailed analysis of the
client's requirements, moves through an investigation of-the
client's current work processes, makes recommendations for
organizational or functional changes, end w~ere a computer or
other automated systems is to Oe used, develops a general design
framework for this. This stage is ~sually referred to-as
"Dusiness/£unctional design", or "general systems design". On a
larKe system this activity is frequently carried out by a team~
and a senior analyst is often assiFj~ed pro~ect leadership ~,
functions.
'ihe next activity, detailed analysis and des.ign, is concerned
with t~e development of detailed procedures for-preparing,
entering and processing data. A detailed systems specification is
produced, wt~ich becomes the basis for the design of compute~
programs for the system. However; on manual or automated office
systems projects, and on small EOP projects, ~eneral systems
design and detail desiKn are often indistinguishable, and the
analyst will cover Ooth in the same ste~.
In a computer system the next activity will be programming
'design, resulting in programming specifications. [n large
computer systems, ~'progrsms" will be composed of a number of
program modules, each of wP_ich defines for the computer the
proc. edures .~o be followed in processing data. The overall
programming design is usually assigned to a senior programmer, who
will delegate tb~ design of individual modules ~o other
programmers, Put who has overall responsibility for the
integration of these modules, as well as for supervising all
programming end testing activities. In a smaller system, where
the program requires only a small .number of modules, program
(~esi~n, codin~ and testin~ may be performed at the proKrammer
level, under the ~eneral supervision of an analyst.
~0
3. The final phase, implementation involves staff at all levels.
Programmers'will work with computer operations and client staff in
testing the programs, and in drawing up procedures manuals. They
also provide training for users, for example, in how to input
documents to the computer, and how to ma~e changes and
corrections. Systems analyst.s are responsiOle for ensuring taat~
users onderstand the system and are able to work with it, ~nd that
all systems components, as well as any interfaces with other
systems are wor~ing properly.
'I~ project leader has a continuing liaison role with the
client throughout the project development cycle, from-initial
requirements definition right through to final system acceptance,
by the client.
Although smaller projects or maintenance projects follow the
same basic process, there are fewer review points and a less
formal structure. Maintenance work focusses heavily on
programming, and maintenance programmers and analysts will
frequently have more ongoing contact with their client groups than
will those at corresponding level, who are engaged exclusively on.
development.
Another factor which is useful in determining the complexity
of computer systems analysis or programming taS<s is the
requirement for specialized knowledge in a particular applications
area; et. certain engineering and research applications require :
knowledge of mathematical or statistical techniques in addition
to programming or software knowledge. Pr6jects in~ these areas are
usually "s~aller" in cost and assigned manpower, Dut the user
requirements are difficult to formulate' without a good
understanding of the client's discipline, and the analyst or
programmer must apply this knowledge, both in development and
testing the system.
(emphasis 'adde d)
From a review of the foregoing evidence, the Board concludes that
although the SPI pro~ect as a whoi~ could Oe characterized as "large",'~
that term is used in the pr~amDte and text of SO2 and SO5 series, the ·
grievor's responsibilities in creating the lines of code for the roll-Up
read-only corporate version of SPI were not large or complex. Certainly,
the formal phases of the SP£ project, were structured as a large 'project,
with a project leader and a design p~ase of 2.5 years ~o obtain a consensus
concerning user data requirements and to generate a systems design with
seventeen logical entities.
The evidence of the parties agreed on the fact that the numDer of
logical entities is a reliable indicator to differentiate large programs
from small programs. In this connection, ~r. Wbite, who has had
considerable expe~ien, ce with a oroad range of programming p~ojects,
indicated that SP£, with seventeen logical entities, ought to be
characterized as neither large or small, but as mid-sized. 'thus, although
the extent Of programming the grievor performed reached the upper limits and
strained the capaDilities of the PC Focus language, in which the suite of
programs wer~ written, the constraints of the language selected is no't
necessarily a reliaDle indicator of the size of the program.
in terms of very large or complex programs, Mr. White gave as
examples, the Comprehensive Income Maintenance System and the Financial
Information System. By way of contrast, Mr. White concluded that the
programming duties performed Dy t~e grievor were not large o~ complex. Mr.
White explained that the PC Focus ~egional and corporate versions of SPf on
which the grievor worked were used primarily to generate mailing lists.
These progr_~m~_ were ~edesi~ned subsequently to allow fo~ greate~
accessibility ~y regional ~nd oo~po~te useF$ fo~ policy analysis 8nd
deci sion-ma~ing.
'the grievor staunchly maintained that his work involved t~e entire SP~
application, ~nd consequently entailed the use of a large numar of files,
.performing a large numDer of computations, and the generation of 'many
different output reports for a large and diverse user group. However, in'
cross-examination, Mr. White pointed out t~at with tae exception of two data
12
elements - the contentious issues flag and fiscal suOsidy flag, the ~same
reports were generated at the cor~porate level as at the regional level. He
ac~nowl.=dged that it was administratively difficult to maintain and a~end
the five different corporate versions, Out he did not equate such difficulty
with size or complexity of the programmin~ tasK. Rather, Mr. White p~inted
to the volume of data or volume of memory processed, as a measure of the
size of the program. Althoug~ the numOer of lines of code built doe. sinot
equate with the numDer of operations or computations performed, t~ereican be
a positive correlation between these building OlocKs of a program. H~o~ever,
complexity is influenced Dy the commonality of elements in the program, s.
Thus, two programs may require a large numoer of lines of code Out Doth ma~
contain a great deal of repetition in the lines of code, since they may
differ in only a few significan,t respects. Mr. White was abl~= to provide
quantifiaOle measures distinguishing large, programs from small w~ich he
characterized were measures of s~andard acceptance. Mr. White offered, the
following as indicia of a large program: a large program uses a million~
lines of code and is capaDle of generating a billion records with mem6ry.
capacity of 100 megaoytes with tee addition of virtual memory. By ~a~ of
contrast, Mr. White indicated that the corporate version of SPI would De
written in 50-~0,000 lines of code, storinE aOout 20,000 records usin~
a~out ~K)O ~iloOytes of memory. ~he grievor did not dispute that such'
measures were standard in reply evidence.
Although the class standards for S02 and S05 give a descriptive
differentiation of small and large programs (number of files, computations,
capacity to generate output reports for a large, diverse user group) these
parameters have been given no quantification in comparative terms. No'doUbt
the aspects of the SP£ application ,upon which the grievor worked seemed
larger and more complex than other wor~ he has performed i~ the past.
Indeed, on this factor, the evidence would appear to indicate that the
grievor's, work verged upon the upper reaches of tr~ S02 class standard.
Given that Mr. White's qu.antification does not contradict but can De
interpreted as fleshing out the descriptive distinctions between large and
small progrm~s found in standards, and given that such measures were not
refuted in reply, the Board finds it wily be guided by ~. White's evidence
in this regard.
fhe Board finds that the grievor ~as not met the onus upon him to
convince the Board on a balance of probaOilities ~hat the .work he performed
falls within .the S05 class standard in respect to the scope of work,
2. Su~ervlsi~
Wor~ is performed, under general Wor~ is performed under general
supervision of a more senior direction of a project leader or
progrsmmer or analyst, with supervisor. ~On large projects
technical guidance and assistance (where business/£unotional design
given on more complex is a major component) a general
applications, design problems, or design specification~will be
on software programming prepared by others, On a smaller
assignments which require pro~ect criteria for deta£1ed
detailed knowledge of the design programming or systems design may
~nd special features of major De_ Obtained direct from the
operating or software systems client.
components.
l%ae evidence pertaining to 6his factor indicates that the grievor
worked with considerable autonomy to develop t~e detailed programming
requi~ed to execute the roll-up of data and to create the various corporate
versions. 'l~ne grievor indicated that he did not receive any doc~entation
14
specifying a general or detai~ed design, but he acquired an understan,ding of
the functions of the SP[ application and c~ient requirements from
conversations with Howard Yin, James White and from John Van Vliet wh9 was
seconded to the project team as a user representative. ~v~. Yin was
classified as an SO5 and ~ad wor~ed upon the same aspects of the pro~ect
prior to the grievor's assignment. The grievor discovered that the work
wb_[ch Mr. Yin had performed did not meet the functional oO~ecbives of~ the
program and could not be utilized. ~r. White acknowledged that he did not
question the grievor's 3udgment on that issue, Out ~elied upon the grievor's
assessment.
Although Mr. Wb_%te indicated that he spoke with the grievor about
technical aspects or proOlems of his wor~ three or four times a month,
grievor estimated the frequency of cont. act as once a month; the 'grievo. r
distinguished other occasions when the grievor would suDmit time sheet, s,
vacation'requests or other such administrative material to i~r. White.~
Indeed, althoug~ the grievor acknowledged tha~ he consulted Mr. Saddiqui .on
a few occasions to obtain advice about proolems, particularly with
corporate versions, it is clear on the whole of the evidence that Mr. :White
was regarded Dy the grievor as his supervisor, although Mr. Saddiqui was
nominally the grievor's immediate supervisor. Mr. White indicated that he
contacted the grievor directly and would file a monthly report on the
1
p~ogress of the pro~ec~ Oased on information supplied to him by the
grievor. No other evaluation, progress reports, agenda or deadlines were
imposed upon the grievor Dy Mr. White. ~v~r. White indicated ~hat he wa.s
satisfied that the grievor knew what was required in respect to the-
assignment and it was up to the grievor to devise how those results or
15
expectations would be met. 'me grievor acknowledged that he sought and
obtained ~ec~nical guidance on difficult technic~l questions from Mr.
White, and more rarely from Ltr. Saddiqui.
O~ the basis of the foregoing, the Board concludes that the grievor was
left to work in a responsible, autc~omous manner under the general guidance
of the Project Leader, [~r. White. ~he grievor obtained the information he
needed to develop programming for the roll-up and corporate versions from
Mr. Yin, Mr. White and from the user representative on t~ SP£ Project ~ream,
John Van Vliet. Th~se findings would tend to favour placing the grievor at
the SO3 level on this factor. However, the evidence was also clear that the
grievor was given tecb~nics~ guidance and assistance on more complex design
problems.
rD~ ~D5 standard contemplates that a designer/programmer will be
working directly with a client ~o obtain the criteria .for detailed design.
in the grievor's .case, h~ did not work directly wi~n clients, 'out with a
user representative especial£y recruited for his £~mi~iiarity wit~"
computerized systems and the service provider system. Furthermore, the
eVidenc~ indicates that despite the lack of any do¢,,mentation specifying
either the general or detailed design, the grievor was informed of the user
requirements and functional objectives Dy ~r. W~i~e, ~r. Van Vlieb and ~r.
Yin. Some of the grievor's design wor~ was derived from general design wor~
done by ~eg Doran. ?he distinction betweea the S02 and S05 standards as bo
b~e nature and quality of the supervision i~ that the higher classification
ca~ries with it greater autonomy and responsibility, with less re~=uYar
scrutiny as to progress on matters of greater complexity and scope.~
Tne Board concludes that although tae grievor was given consider,able
latitude ~y t~e Project Leader to accomplish the tasks of detailed design
and programming for the roll-up and corporate versions of CPI and
maintenance of this suite, of programs, the grievor should remain classified
at the S02 level on this factor having regard to the technical guidance
assistance he received on a regular basis.
5. Ae~ot~abili~y/Im~aot of Errors
S02'
These employees are accountable Completed worR is expectedl to'be
for meeting functional obi.actives technically accurate and
in the d~sign o£ applications operationally efficient, with'.
programs and procedures within review occurring only at
the framework of a detailed scheduled pro,eot checkpoints to
systems specification, or in the ensure that client requirements
evaluation, testing ~nd are met. T~ese employees are
modification of software and accountable for the quality '~ld
program produc~s within the practicality of design of ·
frameworR of a service agreement detailed system or programming
with a client. Errors would De s~ruotures and logic to meet
detected at regular c~eckpoLnts requirements criteria, incYudLng
before, results become-serious, . the selection, adaptation and
but could result in delays in integration of software into the
implementing programs or software design; for exercising pro~ec~;
product changes of inappropriate control over assigned pro~ect.
software, phases, and for overseeing,
testing and installation of
computer programs and procsdures.
Design errors would Cause serious
set-backs or d~llar losses in
installing systems, and
inefficiency in design Or Lac~% of
sensitivity to the user
environment could result in
functloclal problems with the
system and in higher opera~ing
costs.
The evidence disclosed that the grievor was solely responsiOle for
developing tl~e code required to execute the SP£ roll-up and the varioua
If ,
corporate versions of the application. The functional objectives and
logical design in general te~ms were provided to the grievor, albeit without
a documented detailed systems design, the g~ievo~ was instructed verbally
as to the user rec½uirements criteria £or SP£ and he p~oceeded to 'oui~d the
requisite lines of code. As he did, be was evaluating, testin~ and
modifying these lines of code ~o ensure tna~ the user'crite~ia were me~ in
an integrated, efficient, consistent and practical fashion. 'the ~rievo~ was
not responsiote for any budge~ conb?oZ o~ tLme deadlines over assi~ed
pro,eot pb_a~es. Rather this control ~as re~ained by Mr. Whi~e, although
tb. is authority was exercised in a collegial and non-authoritarian fashion.
At the time the gcievo~ ~o~ked on this suite of p~og~ams, his p~og~ess was'
reviewed on a monthly basis ~y Mc. White who ~rusted the grievor's
judgement, integrity and expertise to ~epor~ accurately on the progress
Pae suige of p~og~ams developed ~y 'ghe gpievo¢ using PC Focus on a
stand-alone micEocompuge~ system wece never utilized by ~ne MinistPy excepb
as a developmental progotype in the Hamilton acea office alone. Indeed, in
t~e.subsequent phases of t~e project, the program was amended £o¢ use..with
a minicomputer system with enhanced memory,' connecbability and accessibility
ag all levels of the Ministry system. E~rors by the g¢ievo~ could ~esulg in
delays in implementing the suite of programs .in the Hamilton aCea office by
Mr. Van ~liet. it was admitted by the g~ievo~ tbab e?~o?s would cesult in
loss of gime ~athe¢ than in highec operating costs or functional pcoblems
in operating the system Minisgry-wide oy the p¢o~ecged ultimate usecs o£ the
S~£ system; The Board tbece£o~e concludes gbag notwithstanding the high
level of expertise demonstcated oy the grievo~ in developing and testing the
18
PC Focus version of the SP£ microcomputer programs, the accountabilit~ and
responsibility for errors assumed' by the griever is consistent with his
classification at the S02 level.
4. gno~led~e and ~ills
SO2
Knowledge and ~<ills required Kno~;ledge and a<ills reqfiired
include a good understanding of include: a sound knowiedge of
data processing and systems standard large-scale data
analysis concepts and fu£1 processing programming
competence in standard applications, and full compet~nce
application or software in standard and specialized
programming languages. These languages for such applicati(x~s,
employees m~st have a good and in all phases of programming
understanding of how to develop from design through installation
programming structure and detail and maintenance of programs,
logic, and De fully competent to: including selecting, adapting and
implement, test and integrate integrating software into a
programming routines and system; and/or sound practica].
procedures; prepare conditions knowledge and competence
and programs to generate testing detailed systems design
of systems faults and user and techniques and processes as
machine procedures, evaluate and applicable to computer, automated
modify standard software and manual systems, including.
packages, program products, development of user and machine
debugging aids and utilities; procedures and forms. A sound,
develop clear documentation and knowledge of data storage ~nd.
procedures, and define restart retrieval methods and an
and recovery procedures for understanding of data base,
operators and users; and prepare ' concepts is required to analyze
time and cost estimates for data requirements, develop,and
assigned activities. A sound implement methods for collection,
F~nowledge of job control language organization and s~orage of data,
is required to establish and to implement standards and
statements for integrating and procedures for data management..
testing programs, and a wor~ing A practical understalding of
Knowledge of interactive mini-computer and large computer
terminal uses and data storage hardware and software
and retrieval methods is needed capabilities is required to
to determine data processing and design and implement systems or
data entry requirements for computer functions appropriate to
'computer programs, file design the environment. A sound
utilities, knowledge of current computer
programming methodologies and
19
standards, and leadership s~ills
are employed in coordinating
activities of assigned staff and
ensuring proper programming time
and cost estimates, project
scheduling and control.
Consulting and report writing
s~ills are also needed, and some
positions require s~ills in
marketing systems and facilities.
The evidence disclosed that the grievor was recruited to this p'roject
for his expertise in PC Focus which was the programming language selected
during the planning phase of the project as the~suitaole software, for the
hardware selected of a microcomputer. It was not until much later in the
SPI project, when the limitations of this choice 'of hardware and software
Oecame apparent, that the hardware was changed to minicomputers.
Unfortunately, the grievor did not have the same level Of cOmmand of
software, hardware and prograrmming methods for the minicomputer.
'Pne logical data model and data requirements were sett!_=d during the
p~an~ing phase. Furthermore, the grievor admitted that he did not
demonstrate on t~is project full competence or' authority over the
selection, adaptation, and integration of software into the system which the
S03 class standard contemplates.
'the grievor ~as not ~esponsiole for developing user documentation, nor
was he required to utilize leadership s~ills, since there were no assigned
staff working for him. FurtHermore, the grievor ~as not res~nsiOle for
preparing time and cost estimates, or project scheduling, reports as
contemplated in the S03 standard. Dhe grievor ac~nowl~=dged t~at he was not
required "to implement standards and.procedures for management,, nor ,~as it
necessary for ~he grievor's work to utilize s~ills in marketing systems..
2O
However, this latter s~ill has more relevance to those positions requi~ing a
stronger client and business orientation, than for the sort of posi~[o9· held
Oy the grievor. Finally, the grievor~ could not in his evidence demonstrate
"a sound k~nowledge of current computer programming methodologies and i
methods". '~
On an overall comparison, it is apparent that the SO~ level requir?s
s~ills and knowledge to enable control ~o be exerted over all phases .o~
programming from design to installation and maintenance, with responsibility
for time a~d cost aspects of the work· '£he 'grievor exhibited an excellent
knowledge and competence in the collection, organization and storage o~
data· However, on review of t~e wnole of the S03 standard on this factor,
it is apparent that t~e grievor's knowledge and ~ills, although
considerable in PC Focus on microcomputers, is not of the breadth and depth
which the S03 class standard contemplates.
': I
5. C~tacts
'Ihere is ongoing contact with ~Dnere is frequent and regular
data centre staff, client staff contact with users and' line
and co-wor~ers, to exchange management to discuss and advise
information and. resolve problems, on detailed system and
and occasional ~contact with user programming requirements an~ to~
and line management to discuss provide user training. There is
detailed programming ongo.lng contact with co-workers'
requirements, and to provide and data centre staff to exchange
support on technical matters, information, discuss and resplve
ihey occasionally participate in problems, and to provide
user training and provide technical guidance and revie?.
technical guidance to junior
staff. · ~
21
The grievor testified that he had frequent and regular contact with
John Van Vliet, who was recruited to the P~o~ect Team to function as a user
representative and community liaison. Mr. Van Vliet was recruited to the
SPI Project as a user representativ~ because of his knowledge of the.
Ministry bureaucracy and familiarity with computerized systems. These
contacts were unmediated Dy tbs Pro~ect Leader. Ehe grievor testified that
bis contacts with Mr. Van Vliet were on a daily basis during the init.iai
phases of analysis and design of the lines of code required for the roll-up.
As the design phase was completed, the contacts with ~r. Van Vliet tapered
off to 'five or six times a month towacd the end of the project, in terms of
frequency, the Board is prepared to. accept that the griev°r's contact with
Mr. Van Vliet should be considered as frequent and regular.
However, as is apparent from the S35 class standard of accountability,
responsibilities'at the SO~ level encompass design, installation and
implementation o£ large or complex programs intended for use Dy a large and
diverse user group. Such a user group can De expected to encompass a wide
dispersion of competency or familiarity wit'h computerized systems and
programming. '~hus, the task of an anaYyst/programmer cYassified at the SO)
level woul~ be to translate the technical problems of such a large and
diverse user population into terms which would De ¢o~prehensiole to ~hem 8nd
which would be responsive to ~heir underlying proDtems~
'l~ne panel notes that occasionally the grievor wouYd be contacted by
users' in the area office at Hamilton and by members of the C[ien~ Service~
Branch for explanation and solution of technical proDlems. SuDsequently,
these complaints and questions were diverted to Mr. 'White, in accordance
with a formal complaints procedure. Having regard to t~e fact that ~r. Van
Vliet was the only user representative with whom the Eri~evor had frequent
and reguIar contact and that his other contacts were occasional, the paneL
concludes that tho nature of these contacts ~'e cor~istent with g~
griever's current cl~sif[catim at' the ~2 level.
In summary, the Board finds that the griever ~as not estaolished
his worm falls outside of the scope o.f the S02 class standard. However the
Board would hasten to add that t~e griever impressed the panel as a
~nowledgea01e, responsible and dedicated analyst/programmer. In all
likelihood, an opportunity will soon arise for the griever whereby he ~can
compete and win a position at the level he seeks. '~he Board can only
reiterate that in this case the evidence was insuCficient to prove tn~t
reclassification is appropriate..= In_the reshlt, tne grievance, is dismissL=d.
Dated at Kingston, Ontario, tD~is29th day ofNovem~er , 1990.
Jane F_ ~mrich C~k3:LIperson
Menno Vorster " Memoe r
· Arne Staple~on ~ · ' MemOer
2)
? - ~--~/( ~"~ ~ (Re,er lo back o¢ ~o~m ~u, ~_ .plefion ~nsiru~ions)
z I / I Sr. P~fect Le~e~ L ~7-t525~04
I ·
· N.S, P~conteges of till spirit on eich clut) ire ipprQxtlltlons onty. TIM illacatton often fluctuates doe ~o
Skills ~ ~l~p r~ar~ ~ N~orm job it full wM~ I1~1, (l~le ~Mtory cr~r~lls or li¢~, il ~ti~lil ~
~ S~i~l ~ --
Position responsible f~r the ~alysis, design, development, testing, modificac~o[
and ~c~entation of ail progr~ing as~ig~encs.
Position receives Cech ical guidance and assistance on more complex applicatiors,
design Problem, or on software progr~ing assignments..
Position account~le for mss%lng functional objec%ives in the design of
applications, program~, ~d' procedures.
ella Ty~ Mi~IGr'I ~
0-1072 Ifl.. toll
nOTIES JOin i~LATED TASKS (ConS'd}
techn tqu et; ~,
r~ulrlihtJ b~:
editing r~u~ramn~s, functlo~llt~ screen 4~s~ etc.
· ~-- sllectlng us~ effective io~utton Iff consultJtl~ utth ~ tlchntcll consultint ind other prDject st&fl,
tJpleufltlng fln~l solutl~ Including dKulentitlofl, klttt~ i~ ~tflcntlafl~
eas~ clarification.
· Centre ~ d~t~tci Sti~lltlcs (CCJS}.
· dl~nsirltl~g ptojKt prototy~ to CCJS. .,~
SOS requlr~ntS.
keeping ~bq~t of current techfllcil 1
;r,,IKLS gO ilXO~ (Cqnt'd)
.norou~ vorklng knovledgo of O~C WIS utlllttie, VNS operating s~stel, end EOT edttor; kfiovlldgelnf rol&tlonaT ('ate
sase N4fllgMent $ystlu such 4~ INn.S (pr~ferr~}, or 0~; Ko. ledge Of other progr~(ng llngu4g~s and
.oftu~e ~ucts t~ desirable (e.G. 'C' languid. ~80L, etC. J. ~tllty to co--nicaea fitch the end-users during
,~vlroflM~t~ Shlr~qg tflfor~ttQn i~ CO~nlCatl~g vtth CQ~klrs and minigeleflt ts esse~t141.
DfllC~-6Z~Q