International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
Teaching of Essential Professional Skills Required by IT Graduates
Carin Venter
School of Computer Science and Information Systems, Faculty of Natural and Agricultural
Sciences, North-West University
South Africa
Abstract
Information technology (IT) professionals, such
as software developers, require more than technical
skills, e.g. software design and programming, to
excel at their profession. Software developers work
in diverse and cross-functional teams; they must, for
example, elicit appropriate business requirements;
design and develop suitable software artefacts, and
provide training to end-users. A delicate balance
between technical and non-technical (professional)
skills are key to software success (or failure). IT
students must thus acquire necessary professional
skills, in addition to technical skills, to be wellrounded and productive employees upon entering
workplaces. This study reflects on a BSc/BCom IT
degree offered at a leading South African university;
it aims to determine whether IT students acquired the
mandatory non-technical skills that they needed. So,
the researcher interviewed recent IT graduates to
reflect on the professional skills they felt they lacked,
and incorporation thereof into the curriculum.
Actions were then taken, based on the responses of
the participants, and teaching of professional skills
was successfully incorporated into the curriculum.
1. Introduction
Individuals that choose IT-related careers are
usually naturally technically oriented. They are thus
typically interested in the options (and challenges)
offered by field the science, technology, engineering,
and mathematics (STEM) [12]. Similarly, software
developers choose this career because they enjoy the
technical challenges accompanying the development
of new software artefacts. They must acquire very
specific and specialised skills. As examples, they
must have solid analytical, problem solving, software
design and programming skills. They learn these at
tertiary education institutions such as universities;
the institutions must continuously provide sufficient
quantities of (suitably qualified) graduates for the
Copyright © 2019, Infonomics Society
continually increasing demands of the growing IT
industry [11].
Unfortunately, literature indicate, and have been
indicating for quite some time now, that software
development projects often fail; it is a world-wide
trend indicating a continuing struggle to design,
develop and deliver successful (user-acceptable)
software [9; 16]. It seems that developers generally
develop software that are technically good; however,
it may then still fail due to low acceptance rates by
end-users, when users reject it simply because they
feel that it does not meet their specific needs [2; 5]. It
is thus “other” (non-technical) factors that lead to
software failure and, to circumvent it, the “other”
issues must be identified so that developers can adapt
and work towards software development success.
Non-technical issues will require specific nontechnical skills; these must be identified to enable
developers to learn these skills, so as to effectively
deal with “other” issues impacting negatively on
project success—the researcher will refer to these as
“professional skills” for the remainder of this paper.
So, in this study, the researcher aimed to identify
the professional skills that recent graduates, which
are currently working as software developers, felt
they were lacking upon graduation, and entering
their workplaces. The aim is to identify the nontechnical skills that hindered them to develop useracceptable software for end-users, in order to enable
the university to incorporate it into the IT degree.
The researcher applied critical social heuristics, as a
reflective practice, to reflect on the research problem.
This paper is organised as follows: Section 1
introduces the study. The research problem is stated
in Section 2. Section 3 discusses the action research
approach that was followed. Section 4 gives a brief
overview of the key concepts of the study, i.e.
professional skills required by software developers;
the IT degree explored in this study; and critical
social heuristics, positioned in the critical systems
thinking paradigm, as the theoretical lens applied in
this study. Section 5 discusses the outcomes of the
interview; it identifies the professional skills that the
1541
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
graduates lacked. Section 6 discusses the actions that
were taken, i.e. next steps following on the outcome
of the interviews in terms of incorporating teaching
of professional skills into the IT curriculum. Section
7 reflects on the outcome of the study and, lastly,
Section 8 gives a summary and conclusion.
2. The problem statement
It has been pointed out that academic institutions
may fail to adequately prepare students for industry
and their future places of work [19]. It is crucial to
continuously reflect on what is required from
students upon entering industry, so that institutions
can respond timeously, so as to effectively create the
next generation workforce [20]. Considering this, the
researcher maintains that software developers that
completed typical IT degrees may have obtained
sufficient technical skills during their tuition;
however, they did not necessarily acquire mandatory
non-technical (professional) skills that are also
required from them to be successful in their future
careers, upon entering industry.
The IT industry grows at a tremendous rate and,
as such, the demand for IT professionals, including
software developers, grows daily. Post-secondary
educational institutions do their best to keep up with
the demand [11]. They endeavor to continue to
deliver accomplished graduates that are ready for
industry; however, something seems to be amiss. The
trend of software development projects that,
according to literature, continue to fail indicate that
software developers struggle to design, develop and
deliver software that is technically good as well as
user-acceptable; literature affirms that these software
mostly fail due to low acceptance rates, i.e. when
users feel that their needs have not been met, rather
than due to technical infeasibility [2; 5; 9; 16].
Empirical data gathered for this study supports
this premise: Students that are admitted for an IT
degree must generally have strong technical and/or
academic backgrounds, and hence must meet high
minimum entry criteria; at the university where the
study was conducted, entry criteria for academic
programmes that aim to prepare IT professionals,
e.g. software developers, are also reasonably steep;
examinations are equally difficult. For example, at
this university, analysis of the IT curriculum’s
content and delivery, that consists mainly of software
design, development and implementation, confirmed
that assessments include frequent testing of theory
and appropriate practical application of a range of
software planning, design and development, as well
as abstract and functional programming concepts.
Upon completion of this degree students should thus
be able to develop efficacious software for end-users.
Employers refer to students that graduate from
this university as “strong software developers and
programmers”; they are in demand and reaped up by
Copyright © 2019, Infonomics Society
industry upon graduation. The participants chosen
for this study were all recent graduates that are
currently employed as software developers. All of
them have impeccable academic records. The author
of this paper therefore safely presumes that these
graduates were (technically) sufficiently prepared
upon graduation.
Yet, the participants (recent graduates) confirmed
that struggled to develop user-centric/user-acceptable
software; they often have to do re-work on projects
when end-users seem to endlessly change scopes/
requirements for software projects to include what
they (the developers) perceive as new, emerging
requirements. However, the end-users continue to
insist that the requirements are not new, and that they
(the development team) merely failed to understand
appropriately from the onset of the project. This
causes problematic issues such as schedule delays,
budget overspends, uncertainty, conflict, and low
morale within and amongst development teams, and
also conflict with management as well as end-users.
This correlates well with the literature confirming
some of the major stressors of IT specialists, i.e.
“Deadlines: issues relating to the need to complete
projects within schedule”; “Coworkers: power
struggles and conflicts that may result from working
with others”; and “User demands: pressures put on
staff by users, such as dealing with the IS user
interface” [6].
Hence, the questions that the researcher aims to
answer in this study are: What other, non-technical
(professional) skills should the IT students be taught,
to enable them to effectively deal with the nontechnical aspects that negatively impact upon their
ability to design and develop software that end-users
will accept and use, without re-work, schedule delays
and budget overruns? And how could teaching of
these be effectively incorporated into the curriculum,
i.e. without over loading students with too much
additional study material?
3. The research approach
The researcher applied an action research (AR)
approach. AR is an interactive form of knowledge
development - it is practical and participatory, and it
focuses on change/intervention [4]. AR was suitable
for this study - the researcher was able to intervene
in the identified problem context; plan and take
suitable actions; and also evaluate the effectiveness
of these actions that aimed to improve the stated
problem, and answer the research questions.
The study was structured according to similar AR
work, as proposed and conducted by authors that also
work in the IT fields [3; 4]. Holistic and reflective
research entails three elements: a method (M), which
embodies an underlying theoretical framework (F)
that is to be applied to improve/resolve an identified
1542
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
problem, i.e. an identified area of concern (A)—the
FMA framework is illustrated in Fig 1 [4].
Figure 1. FMA Illustration: Elements in Research [4]
Secondly, AR phases as prescribed by [3] were
followed and combined with the FMA framework of
[4] as follows: first, problem context, i.e. the area of
concern (A), was defined; second, relevant actions
were planned by means of a method (M) and guided
by a theoretical framework (F) to improve upon the
problem (A); third, actions were taken, as planned;
fourth, outcomes of the implemented actions and the
extent to which the research questions were
answered and the problem (A) was resolved through
(M) were assessed; and fifth, learning was specified
and the next iteration of action planned and executed.
The execution of the AR steps in this study are
discussed next.
3.1. Definition of the area of concern
The area of concern (A) is discussed in Section 2;
it gives an overview of the problem statement and
states the questions that this study aimed to answer.
Also, key concepts of the study are discussed in
Section 4 to create a shared understanding of these.
3.2. Action planning
To plan the action(s) to be taken to improve the
identified problem context and answer the research
questions, the researcher did an in-depth case study
in a company that employs a number of recent
graduates from the university where the study was
conducted. The case study approach is suitable for
research, such as this and in this context, i.e. to focus
on a single instance of an area of investigation that
aims to obtain rich and detailed insight into relevant
complex relationships and (e.g. organisational)
processes [14]. In this case, the researcher wanted to
explore the perceptions of recent graduates that
successfully completed a BSc/BCom IT degree at the
university, and currently work as software designers
and/or developers.
Copyright © 2019, Infonomics Society
She therefore interviewed recent graduates that
graduated within the last 5 years with a BSc/BCom
IT degree from the university, and are currently
employed to design and develop software for (inhouse) end-users.
The software development team in the company
where the case study was conducted consisted of a
total of nine software designers and developers; six
of them completed the undergraduate (3 year) degree
(and thus graduated with a basic BSc/BCom IT
degree), and also completed/were in the process of
completing the optional 4th (Honours) year level.
These six were chosen as participants and they were
invited to be interviewed. They were chosen because
they have completed all the modules that are
regarded as core modules to qualify as software
developers in industry—the structure of the degree
and curriculum is discussed in Section 4.2—and they
were actively working as software designers and
developers.
Roles were not well defined in the company, and
the employees were expected to be able to fulfil any
role, as required, in a software development project.
This was a frustration for the participants, but
provided an additional benefit to this study, since all
the participants were approximately equally exposed
to the entire spectrum of software design and/or
development during their employment, and therefore
were all relatively equally knowledgeable about the
processes and procedures of the company. The
company followed an agile development approach to
develop software.
The participants were interviewed as a group; the
group interview had the added advantage of allowing
the researcher to observe how they interact with each
other. So it thus also gave an indication of their
perceived interpersonal skills in a group context (as
an example of a required professional skills that is
relevant to all types of work that involves some sort
of team work, as would also be the case when
working as part of a software development team); so,
the aim was to identify whether any particular
participant could potentially be perceived as ‘socially
awkward’, i.e. lacking basic interpersonal skills.
Fortunately, none appeared to be ‘socially awkward’;
all contributed equally and shared views openly yet
politely. The researcher also had an opportunity to
follow up with individual participants after the group
interview to clarify statements if/where required.
Critical systems thinking (CST) was applied as
the theoretical lens (F) to explore the viewpoints of
the participants, and critical social heuristics (CSH),
as a framework positioned in the CST paradigm, was
used to structure the interview questions; it was also
used as a framework to reflect on the participants’
responses. CSH provided a structure whereby the
stated problem could be explored from the following
views: who/what makes software and/or software
development purposeful and measurable for end-
1543
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
users; who is, vs. who ought to, control resources;
who/what is, vs. who/what ought to be, considered
relevant experts/ expertise to guarantee successful
application and continued use of new software; and
who/what should identify/ensure emancipation of
stakeholders that may be affected, yet are uninvolved
[17]. Participants were guided during the interview
to reflect on their software development work from
these viewpoints. The outcome of the interviews are
discussed in Section 5.
3.3. Action taking
Next steps (actions) that were taken in this study,
as per the outcomes of the interview, are discussed in
Section 6. The researcher implemented ideas
formulated, as per the information gathered from the
participants. She then reflected on the outcome of the
implemented actions; it is discussed in Section 7.
4. Key concepts of the study
The key concepts of the study are discussed next;
the aim of these sections are to create a shared
understanding of the following: professional skills
required by software developers, as per the literature;
a brief overview of the BSc/BCom IT degree taught
at the university where the study was conducted; and
a short overview of CSH to position in this study.
4.1. Professional skills for developers
This study is grounded in the conviction that
software development is by nature a collaborative
process - it acknowledges that specific “soft skills
enhances the likelihood of an individual’s success
and contributes positively towards the common goal
of the project”; yet, it seems that, in general, IT
professionals “tend to be poor at verbalizing how the
task affects the people involved… the greatest
different between software engineers and the general
population is the percentage who take action based
on what they think rather than what they feel, a fact
that does not help in bringing software engineers
closer to their customers” [1]. The literature often
refer to these non-technical skills as “soft skills”;
however, the researcher argues that the term “soft
skills” may be limiting and therefore, in this study,
she rather refers to “professional skills” to
encompass relevant non-technical skills required by
an individual, which complements his/her technical
abilities and aids achievement of given (technical)
tasks.
Limited research has been done in terms of
particular professional skills required by software
developers [1], but authors agree that the degree to
which software development teams comprehend and
aptly interpret specific needs and requirements of
end-users drives software development success (or
Copyright © 2019, Infonomics Society
failure); e.g., they must accurately understand and
interpret end-users’ business requirements, so as to
design and develop successful software; they must
also be able to work effectively in teams to achieve
this [1; 10; 13]. The most prominent skills that
overlap for all individuals involved in software
development projects are: communication (and
listening) skills; analytical and problem solving
skills; interpersonal skills; and the ability to be a
team player [1; 13].
Essential professional skills required by software
developers do not refer, in the context of this study,
to personality traits of people that are software
developers; these are also important and should not
be ignored when allocating team members to projects
[1]—refer also to the rationale for having a group
interview so as to determine whether the participants
appeared to have sufficient interpersonal skills to
work in a group context—however, personality traits
of individuals are not the focus of this study.
4.2. The IT degree
The degree offered at the university entails a 3
year (undergraduate) programme, with an optional
4th (Honours level) year that allows students to
specialise. The university’s degrees are governed by
the South African governing body for academic
institutions (SAQA) [15].
The curriculum includes a number of core
modules, i.e. introduction to programming (Python);
basic programming (Java/C#); advanced programming (Java/C#); data analytics; security; data
structures; business/systems analysis; basic statistics;
basic mathematics; communication skills; business
management; accounting and databases (MySQL).
The fourth (optional) year of the curriculum also
includes the following elective modules (that have all
been completed by the participants), i.e. advanced
databases (Oracle); data warehousing (the Kimball
lifecycle approach; SQL); and information systems
engineering (with project management and software
development approaches).
4.2. Critical social heuristics
Critical social heuristics (CSH) operationalises
the premises of the critical systems thinking (CST)
paradigm [17]. CST aims to aid social improvement
through awareness, complementarism and liberation
from oppressive structures [8]. CSH is a critical
systems methodology that enables critical reflection;
it facilitates identification of underpinning boundary
judgements and associated normative implications of
a problem, and guides rational application of
improvement actions [18]. CSH enables a problem
solver to determine what is/has been done, and what
ought to be done to improve a problem context [7].
Reflection from a CSH perspective aims to be
1544
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
holistic and systematic, and is, as such, to be done
from the perspectives of four categories, i.e. the basis
of motivation; the basis of power/control; the basis
of expertise; and the basis of legitimacy on behalf of
uninvolved, yet affected stakeholders [17]. Problems
can be analysed effectively from the perspectives of
these four categories, according to involved and
affected (yet not involved) stakeholders to ensure
legitimate design and implementation of systems.
For this study the researcher therefore applied
CSH as the theoretical lens to systematically explore
the viewpoints of the participants in terms of their
actual experience, vs. what they felt should have
been in place that could have improved their
circumstances upon starting work as software
developers. So, the participants were asked to
comment on the following aspects of their work:
who/what makes software and software development
purposeful and measurable for them and/or for endusers; who is, vs. who ought to, control software
development resources (e.g. processes, funds, tools);
who/what is, vs. who/what ought to be, considered
relevant experts/expertise to guarantee successful
application and continued use of new software; and
who are affected, yet uninvolved, and who/what
should identify/ensure liberation of them.
5. Interview outcomes
The outcome is also structured according to the
viewpoints of the participants as per CSH categories
that also guided the discussions with the participants.
It is discussed next.
[the clients/end-users] want” from the final product
that are asked to develop. A few of the participants
felt that they were able to succesfully derive business
requirements from end-users; however, most of them
acknowledged that they felt incapable to properly
“…structure those questions…”, especially where
the software will serve cross-functional departments/
teams/diverse end-users, e.g. financial, auditing;
project management, and processing/manufacturing
department; and/or operational and tactical/strategic
management.
The participants agreed that “…if you ask the
correct questions you can move towards the right
code”, and therefore feel that this should be
incorporated (integrated) into the curriculum. One
participant indicated that, upon entering the work
place and immediately after graduation “we did not
have the skills to ask the correct questions…”
therefore their clients often want to continuously
“…keep changing, keep changing, keep changing…”
so projects’ scopes were difficult to fix—it results in
scope changes when end-users see prototypes of the
product, and then continue to add requirements to the
scope of the project, without increasing the amount
of time allowed to finish the final product.
Continuous re-work and then, ultimately, limited
time to finish final software projects, results in failed
software in the sense that the end-users claim that it
does not meet their requirements (which, must be
noted, were unclear from the onset of the project).
So, they wanted to learn how to properly incorporate
changes through change management.
5.2. Proper controlling of resources
5.1. Purposeful and measureable software
The participants acknowledged that, when starting
with a new software development project, they find it
difficult to identify the exact purpose of the new
piece of software, and how it will ultimately be
measured by end-users, at the onset of the project.
Software are often used across departments, and
representatives of those departments have different
views about the relevant purpose(s).
They also say that there were often perceived
incongruities between what they, as designers and
developers, initially thought it was that the end-users
wanted, and what the end-users would be willing to
accept as usable and/or worthy software in the end.
These disparities had very little to do with technical
issues, but rather with functional issues and what the
developers regard as “nice-to-haves”; these would,
for example, be confusions regarding page lay-outs
or buttons, color schemes, reporting formats etc.
The participants said that they derive from this
that they were not taught suitable communication
and active listening skills; they did not learn how to
be “asking the correct questions”, therefore they
often feel that they do not really “know what they
Copyright © 2019, Infonomics Society
Change management, as a systematic approach to
dealing with transitions within an organisation, or on
a project where approved changes go through a
structured justification and approval process, is not
part of any of the subjects included in the degree
offered by the university. The students are given
fixed scope projects as practical assignments; the
scopes of these projects do not vary during the time
that they have to complete them, and they do not
have to deal with managers/end-users that move goal
posts; so they did not learn to cope with project
scope changes and/or people that initiate these scope
changes.
Ultimately, the participants did not feel that they
were in control of their own software development
projects. Scope changes that resulted in schedule
delays and budget overruns were blamed on them;
but they felt that end-users also had to take
responsibility for some of these. So, they also wanted
to learn to be assertive, yet still professional, when
communicating with end-users (that are often their
seniors), for example, to explain the impact (in terms
of time, resources and effort) of every requested
scope change timeously. They also wanted to be able
1545
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
to implement proper change management processes
for their projects.
5.3. Relevant experts/expertise
The participants acknowledged “…that you get
these excellent technical students entering the
workplace, but then how to communicate, how to sit
in a meeting and voice your concerns or your
opinions. How do you do it from day one? It’s a skill
that you need to acquire. If you can’t get it on
university level, it’s very difficult out in the
workplace. It’s a dominant world.” They want to
learn how to be seen as team players, and not just
technical IT people that are “…solitary in the sense
that we don’t like to interact with people…”, i.e. they
want to be “debunking the notion of us as IT…
people who don’t really care about the client so to
say… if we can start by getting rid of that idea from
us as IT people, then I think we can grow and
actually get communication skills…”
The participants agreed that they want to learn
communication (interviewing and listening) skills as
part of the practical software development modules,
and where they develop actual software artefacts.
They want it integrated into existing modules, and
not necessarily added as an additional module to the
curriculum. This way they can learn to specifically
communicate (listen) as is required in their area of
expertise, rather than only in general.
Requirements analysis/gathering, documentation
of business requirements, and interviewing of endusers, are a definite part of a few of the software
development modules (e.g. business/systems analysis
and data warehousing); however, these were,
according to the participants “rushed through” in
order to allow students to spend more time on the
technical aspects of system/software analysis, design
and development.
The participants realised now, in retrospect, that it
would have been beneficial to have more practical
project work that integrated individual modules and
ran “across” individual yet interlinking modules, to
integrate concepts business analysis; requirements
gathering for software design and development;
interviewing of end-users (what to ask in addition to
how to ask the right questions); and design and
development actual databases for “real” clients/endusers, rather than “dummy” case studies/ scenarios;
they feel that this will definitely help in
“[i]ntegrating the technical side and the soft side.”.
5.4. Liberation of the affected
The affected, in the context of this study, is the IT
students that do not learn the relevant non-technical,
professional skills that they also need to acquire to be
successful software developers upon graduation. The
oppressing structure to be liberated from is the lack
Copyright © 2019, Infonomics Society
of professional skills teachings in the IT curriculum.
However, the current technical skills that they learn,
must remain part of the curriculum, as these are also
crucial for software developers. So, a balance must
be found between teaching of the technical skills
(currently included) and required professional skills
(to be included), without overburdening the students.
The credit-load of the IT degree, as governed by
SAQA [15], should not be exceeded.
6. Actions taken (next steps)
Two natural next steps followed upon the
outcome of the initial in-depth case study: Firstly, a
second (last) semester 3rd year module where the IT
students must work in teams to develop a (predefined) software artefact was identified. The project
usually entails a software application to be designed
and developed, based on specifications provided by
the lecturer. The aim is to integrate all technical
students acquired, and allow students to apply a
range of skills taught to them over a period of 2½
years.
However, for this study, the university worked in
collaboration with members of the community and a
real-life project, that would also improve the
community, was identified. A random sample of ten
students were selected, and they were given this
community (real-life) software development project,
instead of the usual “dummy” project. Three staff
members and one community member were also
involved in this project - the community member
played the role of project sponsor; the three staff
member were in the roles of project manager,
project/module coordinator and project technical lead
respectively. The project was overseen by the school
director. The team followed an agile development
approach with regular sprint and progress meetings.
The team had tight deadlines to work towards.
They had to follow all the steps of a software
development project, i.e. starting at analysis of the
business requirements (which were not yet clearly
defined as the community project entailed the
development of a mobile application, but the exact
details and scope had to be defined still, as is often
the case in real software development projects). So,
the team had to investigate technological platforms
and tools, document their work, and give regular
feedback to the project sponsor. The project sponsor
(with minimal background and knowledge regarding
IT and software development) was interviewed to
determine business requirements (that continuously
changed throughout the project, much to the
frustration of the project team as well as the project
sponsor, again, as is the case with actual software
development projects - refer to previous discussions
in this regard). As a result, functional and technical
specifications continuously changed.
1546
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
At the end of the semester, the students were
interviewed to determine what they have learned
from this project - it is discussed in Section 7.
7. Reflection and specification of learning
At the end of the semester, the mobile application
was, to the disappointment of both the students and
the project sponsor, as well as the involved lecturers,
not finished. What started off as a seemingly very
simple mobile application to be developed, evolved
into a frenzy of scope changes, documentation, rework and schedule delays that frustrated the students
and staff, as the project sponsor changed business
requirements as well as the technological platform
half-way through the project.
The students agreed that they did not learn a lot of
technical skills by means of this project (but it must
be noted that this was luckily not the aim of the
project). They did, however, agree that they learnt
valuable lessons in terms of business analysis (asking
the right questions in the beginning of the project,
rather than to assume that they know what the client
wanted and expected from them); to communicate
more effectively within the team and with the client;
how to listen more effectively; and how to properly
plan from the onset of the project. These correlate
well with the professional skills that the interviewed
graduates (refer to Section 5) felt they were lacking.
When interviewing the remainder of the students
that did not participate in the community project, but
continued with the module and completed a dummy
project, as per previous years, these students also felt
that they did not learn any new technical skills (as
expected), but merely applied the skills that they
learnt in other modules to complete their projects (as
is the aim of this module). However, they did not
have the added advantage of learning any of the
professional skills that came with working with an
actual, real client.
So, it can be concluded that incorporating a
project that simulated a real-world scenario, such as
the community project, yielded success and taught
the students mandatory professional skills required
by software development professionals. This project
will be developed further in consecutive years to
ensure that it be completed successfully. Similar
projects will also be identified so that the whole class
can benefit from these.
An additional (and unexpected) outcome of this
study was that the lecturers involved in this study
said that they also gained valuable practical “realworld” experience, which they feel can be ploughed
back to improve their future classes and teachings.
develop successful software. These should ideally be
learned as part of academic tuition, since lack of
these non-technical skills hinder software developers
and software development success. Students learn
technical capabilities to develop technically good,
robust software. Yet, the technical skills are not wellbalanced with required non-technical professional
skills. The outcome is then frustration and failed
software projects.
This study reveals shortcomings that recent IT
graduates felt that would have, if incorporated as part
of the IT degree, helped them to be more successful.
They want to learn to communicate more effectively
(assertively) in team meetings and with clients/endusers; they want to be able to aptly guide interviews
so as to gain a proper understanding of business
requirements upfront (to minimise scope changes
and develop better software in limited allowed time
frames). They also want to learn to manage changes
that result from scope changes.
Participants indicated that it would have helped
them to have more exposure to projects that mimic
real-life scenarios, integrate teachings of different
modules, and hence acquire a balance of technical
and professional skills. An identified community
project, where a real-life project was given to a
number of students for a 3rd project module, yielded
positive results. The students (and staff) learnt
valuable lessons and acquired professional skills.
9. References
[1] Ahmed, F., Capretz, L.F., Bouktif, S., and
Campbell, P., 2015. Soft skills and software
development: A reflection from the software
industry. arXiv preprint arXiv:1507.06873.
[2] Avison, D. and Fitzgerald, G., 2006. Information
systems development: methodologies, techniques &
tools. McGraw-Hill, London.
[3] Baskerville, R.L., 1999. Investigating
information systems with action research.
Communications of the Association for Information
Systems 2, 19, 1-32.
[4] Checkland, P. and Holwell, S., 1998.
Information, systems, and information systems:
making sense of the field. Wiley, Chichester.
[5] Clegg, B. and Shaw, D., 2008. Using processoriented holonic (PrOH) modelling to increase
understanding of information systems. Information
Systems Journal 18, 5, 447-477. DOI=
http://dx.doi.org/10.1111/j.1365-2575.2008.00308.x.
8. Summary and conclusion
This study reflected on professional skills that
software developers should acquire to effectively
Copyright © 2019, Infonomics Society
[6] Colomo‐Palacios, R., Casado‐Lumbreras, C.,
Misra, S., and Soto‐Acosta, P., 2014. Career
Abandonment Intentions among Software Workers.
1547
International Journal of Digital Society (IJDS), Volume 10, Issue 4, December 2019
Human Factors & Ergonomics in Manufacturing &
Service Industries 24, 6, 641-655. DOI=
http://dx.doi.org/10.1002/hfm.20509.
[7] Flood, R.L. and Jackson, M.C., 1991. Creative
Problem Solving: Total Systems Intervention. Wiley,
Chichester.
[8] Flood, R.L. and Jackson, M.C., 1991. Total
systems intervention: A practical face to critical
systems thinking. Systems Practice 4, 3, 197-213.
DOI= http://dx.doi.org/10.1007/BF01059565.
[9] Hwang, M.I. and Hongjiang, X., 2007. The Effect
of Implementation Factors on Data Warehousing
Success: An Exploratory Study. Journal of
Information,
Information
Technology
&
Organizations 2, 1-14.
[18] Ulrich, W., 2003. Beyond methodology choice:
Critical systems thinking as critically systemic
discourse. Journal of the Operational Research
Society
54,
4,
325-342.
DOI=
http://dx.doi.org/10.1057/palgrave.jors.2601518.
[19] Wixom, B., Ariyachandra, T., Douglas, D.,
Goul, M., and Gupta, B., 2014. The Current State of
Business Intelligence in Academia: The Arrival of
Big Data. Communications of the Association for
Information Systems 34, 1-13.
[20] Wixom, B., Ariyachandra, T., Douglas, D.E.,
Goul, M., Gupta, B., Iyer, L.S., Kulkarni, U.R.,
Mooney, J.G., Phillips-Wren, G.E., and Turetken, O.,
2014. The current state of business intelligence in
academia: The arrival of big data. CAIS 34, 1.
[10] Jalil, R., Khalid, J., Maryam, M., Khalid, M.,
Cheema, S.N., and Iqbal, I., 2019. Requirement
Elicitation for Bespoke Software Development: A
Review Paper. In Intelligent Technologies and
Applications, I.S. BAJWA, F. KAMAREDDINE and
A. COSTA Eds. Springer Singapore, Singapore, 805821.
[11] Mahalepa, T., 2016. Developing guidelines for
business intelligence modules in information
technology programmes at universities using critical
systems heuristics North-West University.
[12] Miller, K., Sonnert, G., and Sadler, P., 2018.
The Influence of Students' Participation in STEM
Competitions on Their Interest in STEM Careers.
International Journal of Science Education, Part B:
Communication and Public Engagement 8, 2, 95114.
[13] Mtsweni, E.S., Hörne, T., and Van Der Poll,
J.A., 2016. Soft Skills for Software Project Team
Members. International Journal of Computer Theory
and Engineering 8, 2, 150.
[14] Oates, B.J., 2006. Researching Information
Systems and Computing. SAGE.
[15] Saqa, 2012. The South African Qualifications
Authority: Level Descriptors for the South African
National Qualifications Framework.
[16] Shehzad, B., Awan, K.M., Lali, M.I.U., and
Aslam, W., 2017. Identification of Patterns in Failure
of Software Projects. J. Inf. Sci. Eng. 33, 6, 14651479.
[17] Ulrich, W., 1983. Critical Heuristics of Social
Planning. Haupt, Bern.
Copyright © 2019, Infonomics Society
1548