international journal of software engineering and its applications vol. 4, no. 3, july 20 10...

International Journal of Software Engineering and Its Applications Vol. 4, No. 3, July 20 10

Aligning 'he software project selection process with the business strategy; a pilot study

Joseph Kibombo Balikuddembe Department of Computer Science

University of Cape Town South Africa

ibalikudOcs.uct.ac.za

Antoine Bagula Department of Computer Science

University of Cape Town South Africa

[email protected]

Abstract

This report aims to present the significance of requirements engineering approaches in guiding the project selection process with an overall objective of ensuring that selected projects align fully with an established business strategy. We analyze software practitioners' views on managing the software project selection process in Cape 71-:wn, South Africa. We designed this empirical study following on from our previous' literature survey. Using data categorization techniques, our findings suggest that software vendors ought ro ensure that organizational business strategy is well explained to all stakeholders. including the technical personnel who produce the software. Similarly, the engineering approaches directed towards mirig6uing selection of risky bminess must be utilized and integrated into the development process. Failure to take these factors into perspective renders the organizational competitive strategy ineffective. Detailed research methods used in the study are given as well as approaches undertaken for data collection and analysis..

Keywords: Software Process Improvement, Effective Business Strategy Formation, Value-based Software Engineering.

1. Rationale

New market entrants competing for a significant market share, are often challenged by husiness opportunity management and exploitation. In the agile software market. certain business decisions have to be taken without much delay in consultation; otherwise, a business opportunity is lost Singh [21 observes that too often companies enter markets where they do not have sufficient capabilities to compete effectively. Invariably. making a foot print in the market requires that one adopts market penetrating strategies such as price-cuts so as to ow-compete their competitors [IL Such strategies often lead to selecting unviable projects that are ill-aligned with the perceived business strategy. This complexity is further plummeted by the lack of available tools that guide this selection process against the business strategy. This symptom is prevalent in small firms. These blind decisions are often taken at project inception where the project face-value depicts significant profits. However, once a clear understanding of the requirements sets in. project disaster symptoms start to emerge. At times it is often too late to walk away from such

91

http://www.mercubuana.ac.id

International Journal of Software Engineering and Its Applications Vol. 4, No. 3, July2010

92



Fig. 1. Technical inputs to the be •,iiess strategy

The project management theory provides that the project selection process is fundamentally driven by four principles. including: focusing on broad organizational needs. categorizing software projects according to organizational needs. performing net present value or other financial analyses on these projects and using a weighted scoring model to obtain a clear project value in terms of expected return on investment [9]. We infer that the engineering approaches utilized in understanding project needs and requirements must support these principles as bialirectional business functions impinging on the business strategy. This process can either be 'fornial-merhocr driven or carried out by use of modeling approaches such as the Universal Modelling Language (nit), thereby supporting the planning and control process on projects as well as identifying risk factors on the project. If well adapted as project risk precaution drivers). support for identification of any risky business early on in the process. and even before resources are committed on such projects is ensured. As observed by Gregor et al., 110], if neglected or in the absence of such business strategy- supporting mechanisms. profit-driven software businesses are likely to be edged out of the market easily.. Building on tins view. we recently conducted an empirical study, over a four months period, with 70 software companies in Cape Town. South Africa. Our main objective was to examine whether project selection and requirements engineering processes (as technical inputs to the project selection process) employed in industry today align appropriately with organizational business strategies in general. Secondly, we wanted to examine how projects are selected in industry with or without the use of analytical tools, and if any requirement engineering techniques are used to assess risk on software projects, Understanding the phenomena of prevailing project selection processes in industry and their alignment with the business strategy. would give us some insight in what is going on in business strategy formation and alignment and why it is indeed happening.

3. Methodology

Project Managers. Systems and Business Analysts in particular were targeted due to their strategic role in guiding management on project scoping and viability implications. especially during the software development life-cycle. While building on previous literature surveys. we applied she descriptive and analytical approach so as to identify presence of relationships among key factors found during the interview analysis. A systematic process for survey development, as suggested by Sanchez et al. [11]. which is grounded in consideration of the basic: purposes for which the test scores would be used, was employed to develop the survey instrument. This 18 item instrument was divided into subscales of selected-responses centered on economic aspects of software development. It was designed to gather ordinal data on requirements engineering and project selection. The requirements engineering subsection was aimed at understanding current software development processes used today, by specifically analyzing the depth and breadth of requirements engineering techniques used in industry, The project selection subsection aimed at understanding how projects are selected in the various participating developing houses. The selection criteria used were instrumental in refining the study assertions and guiding conclusions to the research objective. A 5 point Likert-type scale (Le.. 1 = Strongly Disagree. 2 = Disagree. 3 = Not sure. 4 = Agree. 5 Strongly Agree) previously used by Gunn et al. [12] in a study of the relationship

93


94

International Journal of Software Engineering and Its Applications

Vol. 4, No. 3, July 20 10

f7;gX

Ni 3 At] AU ICA ■E5 61151 NEU FE5A AE6 Acbi

Irwrami

SB1.1•10.1.11.10064, • Lh 61,1••• • It al Sum •441i• • ill! 411.1

ng. 2: Rio, tieweriou 3n nxiturstocius algiskeenng

The graph 411 IN) ye illustrates that in response to RE.1 ("We usually fest understood 4lient iequirements before project implementation"), 44% and 34% of the respondents "A.grecsi" and "Stningly Agreed" respectively with this assertion. 10% were "Not sure". while S% and 4% "1)isagreed" and -Strongly Disagreed" respectively. This implies that, although 22% of the rcspondcrits disagree-d with the statement.: majority of 78% of the respondents consider it an imp onant step in systems development to understand the client's requirements. For these companies the Analysis phase is reasgaiahly critical if projects are to he completed successfully. and if consensus has to he achieved on desired functionality - thus increasing client conminmeni on the project. In response to RE 2 1 -We implement the requirements in parallel with requirement elicitation and validation"), 6% "Strongly Agreed" with the statement, while 30% "Agreed". 8% were "Not Sure", 40' -Disagreed" and 8% "Strongly Disagreed" respectively. This result shows ltiat the agile pr-actin e of rapid promyping where miuirernenti ate implemented in parallel with elicitation ad validation is not widely used, thus constituting a 48% response rate, Only 36% of the respondents practiced this approach, The 8% who sin-ingly disagreed in this regard most likely do not use either of the practices. Alternatively. perhaps the software development process utilised in these firms is nut well defined. In respect of RE.3 t"We undertake systems rnotlellin.g using UOSA using 1114L") 40% "Agreed- and 18% "Strongly Agreed" with this Assertion. thus constituting an uggregaw percentage of 589,.. of the local respondents. 84 were "Not Sure". 6% 1)isagreed" and 28%. "Strongly Agreed". This implies that UM'. is being widely used in this area. although there are some companies that do not consider it as lest option for systeinr other possibk reason would be the possibility of a lack of expertise in this area of modelling - thus losing out on the benefit or functional decomposition, system transparency modelling and consequently adequate project estimating using this approach. With regard to RE.4 t"We use a standardised process in collecting., docunierning and Validating WY requirements"), 50% "Agreed" and 20% -

Strongly Agreed" with the sturerneoi. 1(i%. were "Not Sure". and 14% "Disagree-tr. It seems., then. that 70% of the respondents do have some sort of standardised process in requirement collection. documentation and 95



validation. However. a few of the companies do not This poses a big risk to successful project conipletion. and traceability complexities and challenges are bound to occur for them. In response to RE.5 ("We usually develop a traceability matrix for project requirements"). 69 "Strongly Agreed" and 42% "Agreed" respectively. 6% were "Not Sure". 40% "Disagreed" and 6% "Disagreed". This implies that only 48% of the respondents considered traceability matrix generation as an important step in assessing the risks of requirements. The other 46%, however, seemed to put Mlle emphasis on generating traceability matrices. These companies would most likely have difficulties measuring and tracking tasks on their projects quantitatively. Specifically, it will be difficult for them to track what happened where. who did it. how it was done. what remains to be done, and how ii fits into the overall project picture. As far as RE 5.1 ("The traceability matrix is generated using a matrix generation tool") was concerned, only 20%. agreed with this assertion. 6% were "Not Sure". 60% "Disagreed" and 14% "Strongly Disagreed". This implies that. although certain firms do generate traceability matrices for project requirements. few or no tools are utilised. thus creating a need to leverage available tool options to enhance the software development process. At the same time. the lack of using tools in generating matrices means that they will he niore prone to mistakes, which can result in errors in judgment with regard to project choice and overall nanag e meal. In respect of RE 5.2 ("The traceability matrix is generated manually") as a control statement. 14% "Strongly Agreed". 34% "Agreed" while 185. were "Not Sure" about this statement. 34% "Disagreed" and 6% "Strongly Disagreed". Thus, most of the companies that generate requirements matrices for project requirements do so manually. This approach is error prone, however, and can be time consuming. which ultimately affects implementation time. With regard to RE 53 ("We don't consider the traceability formulation important because of lack of time"). 50% "Agreed" with the statement, 26%, were not sure. 18% "Disagreed" and 6% "Strongly Agreed" respectively. This implies that, due to time constraints, which are common in software projects. half of the respondents leave out the traceability generation process. They do so because they regard it as a waste of time, which is likely if it has to be done manually, given that there may be no readily available tools. In response to RE 6 ("It is part of our development procedure to undertake a requirement dependency assessment for risk assessment"). 12% "Strongly Agreed" and 46%: "Agreed" with the statement. 30% were "Not Sure", and 12% "Disagreed" with the statement. Thus. .58% of the respondents acknowledged the fact that a requirement dependency assessment was important for identifying project risks earlier on in the development process. given that they do so in their own development process. In respect of 6,1 ("There is generally less or no requirement dependency assessment undertaken") as a control statement. ltl% "Agreed" with the statement. 8% were "Not Sure", 54% "Disagreed" and 20% "Strongly Disagreed" with the statement. This result implies that. while some firms do undertake dependency analysis on the requirements, others do not. This raises concerns on how risk detection is executed and managed on projects taken on by the latter companies.

4.2. Project selection process

In the area of project selection, the following assertions were presented to the respondents are given in Table 2 below.

96


Table 2: As.sertious in project selection

fpm jeer selection PS I Our projims AFC selected based on atrategic business objectives PS 2.: Wc choose liar projccR hail rtn profitability level mak:Taut] PS 3. Our rrroteds are in-Iiiiii se and Inv orlartisation is The direct mammal PS 4: We dvedd on foisibility asscssgricni reports to determine projek.1 trnplenvniation PS '. We Ise analytical toois thin gII1de t13 in poliect selection PS fp Oar project seleatoc is parch beunstie

7.We just mice on any project we get hold of 1.Oar projects are for research and development

lip- ..1 below illustrates die malts ebtairketi in titi$ i n YeSligawn,

t

tt

I

1 00 MR i CIO

WI% MI CO%

LU

ILI OEM. G

II 00%

P32 r.53 1.55 PS P51 1.531

ilralihrOtrmf MAsairwe • lia•SLIrt &dire' • IliWighp Awry

3: Project selectman Innis

The graph above illustrates drat. with regard to PS 1 c-Our projects are selected based Lm :strategic busines.s objectives"). fa "Disagreed!' with this Matti:tient .while R.% were "NOt Sure", However. 64% "Agreed'" with the statement and 118% "Strongly Agreed". This pattern shows that a majority of firms do base their project selection processes on strategic business objectives However, a small percentage does not, or paliaps their business objectives are [14)L ciesitiy defined and therefore there is HO grAtcgic realignm-at of the process with I-rosiness.

in respect of PS 2 rihre choose our projocts based on profitainkty level anticipated.). NM of tic respondents "Disagreed' with this assation while 14%. were not sure, However, 34% "Agreed- and 24% "Strongly Agrei.xi" respectively. Ther.efore, :profitability seems to he die biggest dnving factor in choosing projects kr the majority of firms interviewed. None-helms. A few do not nemssarily rely on profitability per se. but perhaps base their decision on whether and how a given projoot is strategically aligned with the business .ohjecti yes, or perhaps their projects are for research and development. In response to PS 3 ("Our projects are in-house and my organisation IS

the direct fthrnele). 20% -Strongly Disagreed!". 38% "Disagnted" and 14% were "NO sure-.. However, 14% -Agreed- and "Strongly Agreed" respectively. This suggests that the majority of the respondents work on external projetis• for clients while a negligible number work on in-house projects. This suggests that there is a need for cif:wive risk assessment approaches directed towards understanding project mitsirements and ensuring that a misinterpretation or Inxisttndostanding a these regturernents does not reflect negatively on the rviects. 97


For PS 4 ("We depend on feasibility assessment reports to determine projects implementation"), 44% "Disagreed" with the assertion. while 12% were "Not sure". 24% "Agreed" and 20% "Strongly Agreed" with the assertion. 44% of the firms do not depend on feasibility assessments to decide on project implementation but on other factors. However, a few of them do.

With regard to PS 5 ("We use analytical tools that guide us in project selection"). 8% "Strongly Disagreed" with the assertion while 32% "Disagreed" and 40% were "Not sure". However, 14% and (t "Agreed" and "Strongly Agreed" respectively. This shows that most firms do not use any analytical tools to guide them through the project selection process. However. a few of them dot moreover. a large percentage are unsure of whether any tools are utilised in the selection process. This implies dust

although 1110SE of the respondents may have an idea of the selection process. there is uncertainty of whether any tools are used. In response to PS 6 ("Our project selection is purely heuristic"). 12% "Strongly Disagreed". 26% "Disagreed" and 42% were "Not sure" about the assertion. However, 14%. "Agreed" and 6% "Strongly Agreed" respectively. This implies that ihe biggest percentage of respondents do not necessarily rely on heuristic methods of project selection but do follow some form of metrics to determine project viability: this applies to PS 7 assertions as well. With regard to PS 7 ("We just take on any project we get hold or), 30% "Strongly Disagreed", 52% Disagreed and 12% were "Not sure". However, only 6% "Strongly. Agreed" with the assertion. In respect of PS 8 ("Our projects we for research and development"). 28%• "Strongly Disagreed". 42% "Disagreed" and 12% were "Not sure" about the assertion. However. 6%. and 12% "Agreed" and "Strongly Agreed" with the assertion. This shows that the majority of the companies interviewed focused on commercial software development rather than on research and development projects. which may not have a strategic business direction in the short term.

4...A. Interpretation summary

The above findings are summarized as follows, Specific trends of interest were ranked according to a scale designed for overall results interpretation. Tins is illtisu-wed in Table 3.

Table 3: Key for trends' scale

. Prevailing trend Scale

.

Not practiced at all

I

Require serious improvement

I

Occurs rarely

3

Satisfactory

4

Well practiced

5

It is upon this scale that conclusions were drawn specifically looking at overall performance of a parameter of interest across the sample, majority responses to a parameter in comparison to the overall sample and a few or minority responses to a given parameter across the sample. The key parameters of interest are given in Table 4.

98

International Journal of Software Engineering and Its Applications Vol. 4, No. 3, July20 10

99


4.3.2. Requirement., engineering proces_s

1 4

-

U

UM.111FMMIn1 kNOt macre.1 Wog .31.10 .,),Irsurercs oepeneleedy pnlfnl mid"' I/M..8414 .drlmIlfarld Is‘taial fArrGlitig$

Finking Forantamv

am IN Liminilv

Fig. 6: Strategic requirement engineering

As illustrated in the figure above, Ina modelling is well practised in only a few of the participating companies. In some companies however, it is used rarely, thus suggesting overall improvement itr this aro. On the other hand,. tool usage in project selection and requirements matrix generation is not used at all. More still. requirements traceability as well as dependency analysis on software itroject requirements still scored poorly within this snunple

4.3.3. Project selection

2 u t

A 2 li 1 li fp V i

t 2 ,1

I icunsix .InShobil tkiwil Emed an psortss ntalitiNilly4 telekricias lewd rave'.

l (Wm', • Mapiro ■A liew

Fig. 7: Project selection parameters

These results showed that, across this sample. projects are selected hosed on feasibility remits as well as on anticipated profitability and established business goals_ However, risk analysis on these projects is only undertaken by a few of the respondents within this sample: majority o the reSpoudentS do not rkeces undertake this analysis.

100


4.4. Discussion

These results show that the need to realign engineering and project selection processes with business objectives is still evident. in instances where business objectives are not well integrated into the processes that produce the software. certain business elements may be sacrificed, such as productivity measurement, quality and risk detection in business selection and overall management. Although a given percentage of the participating companies undertake risk analysis, the extent to which it is done cannot be quantified. Tooling is not widely used in project selection, which implies that heuristic project selection approaches always suffice-. although some companies often depend on feasibility assessment reports to del-mune viability of projects. Requirement traceability is sacrificed due to time constraints, yet if well integrated it can aid decision-maLng to a reasonable extent, especially when enforcing reconcilable acceptance criteria establishment on projects. Lack of utilization of such techniques makes it difficult to track and interpret complexities embedded within project requirements. On the other hand UML as a modeling technique has not been adequately embraced, overall, less or no requirement dependency assessment is undertaken. More still, although projects are selected based on business objectives and anticipated profitability, these business objectives are not well explained to all stakeholders. including the technical personnel who execute the tasks on these projects. Interestingly. the anticipated profitability on projects is not often mapped to the processes which in turn impact its overall management during the project lifetime; thereby affecting sustainable business continuity and economic value realization at project completion.

4.5 Stud). Implications

These results therefore suggest that the need for tools that increase visibility into assessment and identification of risky business is evident. This would in turn ensure that the possibility of repeated undertaking of non profitable projects is averted. Al the sante time company bottom-lines would be set at a project level before commitment is made on these projects. Essentially. this would support tactical decision inaking to ensure that past mistakes do not reoccur. This would demonstrate that profitability as well as viability bottom-line establishment can be achieved with adaptive tools that keep track of what is happening in the process at every level within the development lifecycle. Consequently. this visibility will enhance business strategy mapping. direction and guidance in the long run. With such tools and also with the diffusion of the business strategy in the organizational stream, we hope that companies will be more focused and therefore produce software products valuably.

5. Conclusion and future direction

While these results cannot be generalized across the entire spectrum, they are indicative of what is happening in most of the software-producing companies, irrespective of size and business direction. They are key business issues that require redress. Therefore. they offer a two-fold benefit. Firstly, they are instrumental in establishing baseline data for future comparison and problem analysis, Secondly, they can be used for identifying trends, issues and concerns unique to software development process, management and challenges. Similarly, a significant portion of most value-based engineering strategies available can be tirade operational by investing, in and developing the process capabilities that can lead to

101



itWreased compelitivenem in the sofb.v are business. Th.- co:Ss of slrategii; protect selection 81341 Cligineering techniques usiliz.ed therefore requires reliable data in order to tdign improvements with strategy. and to understand precisely the processes with which the business needs to develop_ In future. it will he interesting to re.plicare this study in another economy to assess the nature of results that cari he otgained as far as this paradigm is concern. This will provide a ground kir generalization of these resulLc acrom die spectrum or their CIMUCXillaii,2*1•11 with regard to South Africa and Cape Town in particular.

6. References I. 1. ['Fels. D, Heisler. 1. Regina, H. Schuetze. "A Cellular Automata Model of Compenium in Technology Markets with Network Extertia LNCS. Springer Berlin 1 Heidelberg. Netherlands, 2005, pp 378-3S5. 2. M. Singh. "U-SCRUM: an Agile Meihottology for Promoting Usability. In_ Proceedings of die Agile 2008"Jep. 555.560. [LEE Conwuter Society, USA (20118), I. S. loydeeji, O. Chakravarti. A. Rapnport. 'Price oriel Margin Negotiations in Marketing Channels: All Lxiierimental Study of Sequential Bargainitit, wider One-sided Unaertainry and Opportunity Cosi ot Delay", Marketing Science. Pi (2), RISE II2R, Amsterdam, 2{/1)[). pp.I61- I 84. 4.Y. IL Kivak, J. Stoillarei, "Projea Risk Management: Lt%Strus Le4nned Fiona SOftwunt Development Environment', Techuovation 244 H 1. ELSEVIER. Amsteidaro. 20(14. pp. 915-920 5.J.A. Parnell, S Carralter. K. Holt, "Participative Management's Influence no Effective Strategic D J. of Business Sarategies 1911 Einerakl Group Publishing Limiled. 2002. pp. 141-159. 6, A. J. G dilleirefiCtS le the perception of business & IT alignment", Communication of the DMA /121, in ivenity of Northern Press. 2[1(17. KJ.21-32, 7. A. Egyed, S. BIM M. Windt,. P.Urtinttaeher. "A Value-based .Approach for t[ntlerstanding Cost-benefit Trade-offs During Automated Soflware Traceability", In, the Y international workshop on 'Traceability in emerging forms of software engineering, pp 2--7. ACM. New Ytat (20051. X. Suborn. C.Y. Li, S.H. Chen. "An liteerated Multi-objective Decision-Making Process for Supplier Selection with Bundling Problem". rxixrL Sys. with App, Art liner. 1, Mai Pergartrao Press. New York, 2009, pp. '327--2337. 4. 11 mirk] K, Pyojeci Management, A Syxterns Approach to Pluming, Scheduling and Controlling.. John Wiley, New York . 1973. 10. S. Ov.gar, D. Han, N. N.Mariiii, "Eisierprise Architectures: Enablers al' Business Strategy mitt 1S/IT Alignment in Government", Information Technology and Peopk 20421, Emerald Group Publishing Limited, 2007, pp. 96-120, I. Sanchez. DM. liuxdiu. 'U.N. Bauer." Development and Examination of An Expectancy. based Measure of Test-Liking Motivation", Jounial of Applied Psychology. 81(51. American Psychological Association. USA. 2004), pp.739-50. 12. .1.C,Goan. R,C.M. Yarn. C.K. Mak, N. Ma. "A Study of the Relationship Between Competitiveness ouch Technological Innovation Capability Based on DEA Models", European I. Ores, Res. 171h31, ELSEVIER. Amsterdam . 2006. pp. 971-gfifi.

AuthurN

1)r. Joseph Kihrombis Bahkudtienthe t BUS Makerere. MPhi9.iT UCT, PhD I.1C1) is a Systetos Analyst at Santam Life Ensurauce, South AfriCa. He is a member of the Software Process and ItnprOvement Network, Cape '!'own chapter. His research interests are in Software Requirements Engineering, Project Management and Sizing and Estimation of Software projects.

1)r, Antoine Bogisla Wag Loin-0th, MSc Stellenbosch, PhD KTH) is a senior lecturer at the Departmenl of Computer Science. University of Cape Town. His research interests are in Traffic engineering. wireless networking. network security_

102


international journal of software engineering and its applications vol. 4, no. 3, july 20 10...

Documents