# Project Management Information Systems (PMISs):
## 3 Methodological Approach
### Survey Design and Analysis of Data
#### 3.2.2 Second Survey: Design and Analysis of Data  
In the second survey, the Design of Experiment (DoE) was used to develop some full functionalities packages--called prototypes--to be submitted to respondents. In particular, only features were involved in the design of prototypes, whereas sub-features were disregarded because of their high number. In order to allow respondents to evaluate prototypes, a conjoint analysis [31; 32; 33] was performed. The conjoint analysis allows the determination of whether the presence of a functionality significantly influences the appreciation level of PMIS software or not, also taking into account the interactions that could arise from the simultaneous presence of several functionalities [34]. With regard to DoE, a fractional factorial design of experiments was developed. It provided \(2^{(k+p)}\) runs (i.e., prototypes), two being the number of levels (i.e., presence or absence of a feature, identified by \(+1\) and \(-1\) respectively), \(k\) the number of factors (i.e., the eight features) and \(p\) the rate of reduction. A well-known design with eight factors foresees 16 runs, so that the resulting reduction rate \(p\) is equal to four. It means that the fractional design only comprised \(2^{4}=16\) runs rather than \(2^{8}=256\) of the full design. The chosen fraction design can be selected in many ways, \(2^{4}\) ways in this particular case. In this paper, the chosen fractional design was obtained by the Minitab(r) package (Table 1). It was characterized by the presence of four factors (i.e., level \(+1\)) and the absence of the other four (i.e., level \(-1\)) for 14 prototypes (from 2 to 15), while the first and the last prototypes (i.e., all features are absent or present) represent the zero and the full scale, respectively.  
\begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline \begin{tabular}{c} **Prototype**Feature** \\ **Feature** \\ \end{tabular} & \begin{tabular}{c} **Activity** \\ **Planning** \\ \end{tabular} & \begin{tabular}{c} **Resource** \\ **Planning** \\ \end{tabular} & \begin{tabular}{c} **Control** \\ **Control** \\ \end{tabular} & \begin{tabular}{c} **Risk** \\ **Analysis** \\ \end{tabular} & \begin{tabular}{c} **Reporting** \\ **Analysis** \\ \end{tabular} & \
\begin{tabular}{c} **Comm.** \\ **Manag.** \\ \end{tabular} &
\begin{tabular}{c} **Utility** \\ **Permits** \\ \end{tabular} \\ \hline
1 & \(-1\) & \(-1\) & \(-1\) & \(-1\) & \(-1\) & \(-1\) & \(-1\) & \(-1\) \\ \hline
2 & \(+1\) & \(-1\) & \(-1\) & \(-1\) & \(-1\) & \(+1\) & \(+1\)  
The 16 runs of Table 1 were the software prototypes considered to evaluate features. In every prototype, the included features were highlighted in yellow whereas the absent ones were in white. An example of a prototype is reported in Figure 2.  
Every respondent was asked to rate every prototype on a seven-point scale, also allowing decimal scores. Scores equal to one and seven were given to the first and last prototypes, respectively.  
Aiming to single out the features' weights on the basis of the prototypes' ratings, a regression model was performed [35; 36; 37; 38; 39]. Input data of this model were the dichotomous variables representing the presence (i.e., level +1) or the absence (i.e., level \(-1\)) of a functionality within every prototype. On the other hand, the response variable of the model was the rating of every prototype given by every respondent. The regression coefficients of the estimated model represented the features' weights. The only significant terms were considered after using a stepwise regression, which was able to select the significant factors (i.e., features) with respect to their contribution to the total variability of responses. Finally, on the basis of the methodology proposed by [PERSON] et al. [37; 40], the normalized weights of features were calculated from the estimated regression model coefficients.