Material Concerning the Theme Management

1 Management

In this sub-section material concerning the theme management will be presented.

Project objective

In total five questions were asked concerning the category management. In all cases uncertainty was encountered by all respondents concerning the term project objective. When this was exchanged for project goal the respondents were able to answer. When respondent 1 (R1) was asked what significance he attached to the projects goal with regard to a successful software project an acknowledgement for its relevance was acquired. This is apparent from the following excerpt: The goal of the project naturally has relevance. The project usually has a relatively clear goal. (R1)

Respondent 2 (R2) commented that delimitations were important and that such delimitations were usually defined.

Respondent 3 (R3) laid a particular emphasis on this aspect, stressing its importance for the project: Its importance is decisive. Without a clear goal which is possible to verify then you have no way of knowing if you have completed the project or not. In other words, you have no way of knowing if you have a project or not. (R3) R3 continues, emphasising further the importance of the project goal: Unclear goals have a tendency to collapse projects. (R3)

Respondent 4 (R4) emphasised the importance of roles when considering the objective of the project. According to R4 your position in the project influences a particular persons requirements/needs from the project objective: It is heavily role accentuated […] I believe that the goal should be adapted to fit both the person and the task that person is undertaking. (R4)

Respondent 5 (R5) explained that a well defined goal was essential for a project. A clear goal according to R5 was necessary in order to know exactly what to create: It is extremely important that one has a clear goal to steer towards. A clear goal is extremely important in order to know exactly what to create. (R5)

Analysis

The respondents were not familiar with the term objective. When this was exchanged for the term goal all respondents were able to answer. All respondents acknowledged that the goal of the project was a very relevant and important factor. Some respondents were more specific than others. For example, R3 maintained that the objective was decisive for the project. According to R3, if the project does not have a verifiable goal then one has no way of knowing if the project has been completed or not. R5, in line with R3, placed considerable emphasis on the importance of the project goal in the sense that without a clear goal one cannot create the requested product.

R4 offered an interesting perspective on the goal of the project by implying that the goal should be adapted to fit the individual and the task that individual is undertaking. A particularly strong sentiment is captured by R3 who maintains that unclear goals had a tendency to collapse projects.

Sponsor/champion

When asked for their opinions regarding a project sponsor three respondents shared a similar interpretation of this term whereas the fourth had a slightly different interpretation.

R1 used the term internal customer. R1 emphasised the sponsor's role as bridging the gap between developer and customer. Yes, definitely. A project should include such a person, someone who we call an internal customer. As we usually have difficulties communicating with the customer we create a fictitious customer […] a person who both the development team and customer can liaise with. R1 explains the consequences of a project lacking a sponsor:

[…] it becomes very difficult if you don't have such a person. The risk is great that the project will become very expensive. (R1)

R2 acknowledged the term sponsor and that it had, for several years, been present in a project management model used at R2s company. R2 considered a sponsor to be a valid inclusion in this model.

R3 emphasised the economic role of the sponsor, laying emphasis on the fact that the sponsor provided the necessary funds needed to finance the project.

R4 considered the relevance of the sponsor in relation to the size of the project. In either case R4 considered the sponsor to be a valuable asset: I believe it depends on the size of the project. In any case a sponsor is a very valuable person, someone who better sees continuity in the project. (R4)

R5 was of the opinion that sponsors contributed with important elements to the project: We have a steering group of which the sponsor is a member. The steering group is assigned the role of supporting the project manager in certain issues, for example resource issues.

Analysis

When asked for opinions regarding the relevance of a sponsor/champion in software

projects 3 out of 5 respondents recognised this term in the context that has been identified in the literature analysis:

“(The Standish Group, in Procaccino et al, 2002) maintain that a project needs a committed sponsor or champion throughout. This sponsor should participate in the decision making process and encourage the same commitment from other stakeholders.” (p. 48)

The fourth respondent recognised the term sponsor in the economical sense, i.e. a financial provider. All five respondents, irrespective of interpretation, valued the presence of a sponsor.

The concept of the sponsor adopting a superior role is addressed by R1, R4 and R5. R1 explained that the sponsor assisted the project team with customer contact. R1 implied that the project team may experience difficulty with this aspect of project work and therefore the sponsor fulfilled a very necessary function. R5 explained that the term sponsor was used for a member of a steer group whose chief function was to support the project manager in certain issues. Whereas R1 and R5 addressed specifics in the sponsor's role; R4 encapsulates the issue of superiority by considering the holisticity of the project. R4 maintains that the sponsor better sees continuity in the project which would imply that the sponsor adopts a position from which he/she can overlook the project.

Lessons learned from the past mistakes (Post-mortem analysis of a project)

When asked for their opinions concerning lessons learned from past mistakes all respondents were of the opinion that this was an important aspect sometimes overlooked in projects.

R1 explains that too little time is dedicated to this aspect of the project. The fact that resources may not be available and the fact that this phase may not have been planned are given by R1 as plausible reasons for this deficiency: I believe that too little time is dedicated too this […] all the money is gone, no resources are left, one hasn't planned for analysis and feedback. R1 points out however that this aspect is partially incorporated into the development process in use at R1s company: [..] this is partially built into the process we use. After each iterative stage we have an evaluation where everyone has the opportunity to give their thoughts about good and bad aspects of that particular stage.

R2 was of a similar opinion, placing emphasis on the fact that people are very tired at the end of the project: It is a deficiency in our projects and that is a shame plus the fact that when everything is done no-one has the energy to go through all that.

The response obtained from R3 was slightly different. R3 emphasises the importance of keeping this phase at the right level. R3 acknowledges the relevance of this phase but at the same time maintains that it should not be too long as no one would read it. It's important to keep it at the right level. It's a difficult balance. A report must be written but at the most 10 pages A4. People will read it then.

R4 considers the fact that when the project actually has been completed everyone involved in the project has at that stage been reallocated to a new project. R4 highlights that if a technical development project stretches over a long period of times to complete then no-one will remember what happened in the early stages of the project: […] it would be wonderful if it could be realised but when one has come so far that the project actually is complete and an evaluation is possible, everyone at that stage is gone and the project doesn't exist. […] besides, if it is a technical development project which stretches over a long period of time then no-one is going to remember what happened 2 years ago, 2 months ago or even 2 weeks ago as so much happens all the time.

R5 advises that if projects were not evaluated upon completion then mistakes and successes could not be capitalised upon in future projects: If we didn't do this then we wouldn't learn from mistakes or successes. By studying how the project has been run many things can be learnt. (R5)

Analysis

The concept of a post-mortem analysis was fervently acknowledged by all respondents. Both R1 and R2 maintained that this aspect was a regrettable deficiency in the projects these managers have led. R4 was of the opinion that such an analysis is usually hard to achieve. According to R4, when the project has reached that stage when it actually is complete project members have inevitably been reassigned.

Furthermore, R4 informs that if the project has spanned a long period of time it is unlikely that people will remember events that occurred early on in the project. R5 offers a concise motivation for the contributions of a post-mortem analysis by ascertaining that if such an analysis was not conducted then lessons would not be learnt.

Communication

R2 maintains that communication between the stakeholders is a very important aspect to be considered in software projects. According to R2 this is also difficult to get right:

Communication, we have noticed, is a very important to create a common vision of the goal (R2)

When asked how communications could be improved R2 answered that specifications were used during meetings and that the stakeholders spoke until a common vision was reached: Specifications. One has meetings where different groups within the project meet and go through these specifications. We speak until we are certain that we have a common vision. (R2)

R3 also values the presence of good communications. R3 observes that it is important that the customer is engaged from the beginning and is able to communicate his/her vision of the goal.

Communication is important. It is important that the customer is engaged from the beginning, is interested and communicates his/her vision of the goal. If the customer can successfully do that then we have both a correctly defined goal and a close communication. R3 continues explaining the problems which can arise if good communication is not established between stakeholders:

[…] there is a lesser risk that one falls into the-dare I ring and ask- trap. A dangerous trap to fall into because one chooses not to ring and ask about things they are unsure about. One makes a decision, the risk is great that the decision is wrong and the consequences are expensive.

R5 is of the opinion that good communication constitutes a key for project success: This is one of the keys to project success. Partly that good relation exists and that one has close contact and clear lines of communication.

Analysis

Three out of five respondents recognised the value of good communications. R5 even maintained that good communications constituted a key to project success. R2 advised that good communications are hard to achieve and that it was important to achieve a common vision for the project. By acknowledging the importance of a common vision R2 suggests a coupling back to the goal of the project or project objective. This affiliation would be endorsed by R3 who stresses the importance of an engaged customer and the ability of this customer to be able to effectively communicate his/her vision of the goal.

Software measurement

Software measurement is a term which encompasses aspects such as product size, lines of code, man hours etc. None of the respondents recognised this term in itself but recognised the individual components the term applied to. When asked how much time should be dedicated to these aspects R1 explained that, depending on the projects size, two people working full time for 2-3 days was to be expected. R1 stressed the importance of establishing a cross section of viewpoints regarding these aspects: Depending on the size of the project one should dedicate 2-3 days, and that's two people working full time. After that we may have a 5-10 man forum where we don't go so deep. It's extremely important that one obtains varied points of view

on this, extremely important.

When asked whether carelessness when estimating lines of code, man hours etc could affect the success of the project R1 maintained that it could. In R1's opinion this was because by carefully estimating such aspects and involving the people who ultimately will work on the project a common vision can be created. R1 maintains that much is earned by involving the team in these estimations. In addition to a common vision the team can establish which parts are difficult, which parts are easier, which parts should be completed first etc. the team also have a chance to discuss the product.

R2 explains that the products main functions are established first then an estimate is made for how many man hours would be required to create these functions. R2 emphasises how important it is when giving estimates of time:

extremely important. Often time is something which is underestimated. I have, on several occasions, witnessed that competence is required when estimating time.Especially when giving a price tag. (R2) R3 observes that these aspects are influenced by the competence of the team: it is important that these aspects are considered […] I am project manager for a number of people and we are going to develop a software product. If this is their first project then these aspects are really important. If this is their 150 th project then they are going to require completely different guidance. (R3) R4 recognised components such as lines of code, man hours etc. R4 informed that this information was used to estimate the project.

Analysis

The term software measurement was new to all respondents. The respondents did, however, recognise the individual components the term referred to: lines of code (LOC), man hours, scheduled time etc.Varied points of view were gathered when discussing software measurement. Three of the five respondents acknowledged the importance of the individual components (LOC, man hours and scheduled time). R1 stressed te importance of establishing varied points of view with regard to these components whereas R3 advised that although aspects such as (LOC) were important there was a direct affiliation to the competence of the team. R3 means that if the project team is inexperienced then aspects such as LOC are important. If the team is experienced then such aspects are not so important. R2 focused primarily on the time components of software measurement: man hours, scheduled time etc. R2 considered these aspects to be extremely important and often underestimated.

Quality control

Routines for quality control include features such as: design reviews, code inspections testing etc. When asked if the same degree of thoroughness was required with these features as was required with software measurement R1 replied that this should be but was not the present case. R1 informed that design reviews and code inspections were implemented automatically. R1 cautions for over ambition when working with features for quality control. “design reviews, code inspections and such are usually implemented automatically. One should not be over ambitious with these things. It's a fine balance but MOOSE (a development process) allows that quality checks can be omitted if the team is in agreement.” (R1) R2 explains that his company have ambitions to be thorough with quality procedures. R2 informs that lack of time or money causes such things to be overlooked:“we are aware of these things, testing and such. We have ambitions to be thorough with these things but when time, perhaps even money is lacking such things go by the wayside. I believe that everyone is in agreement that these things, testing and such, are good things.” (R3)

R3 informs that quality procedures belong to the process. R3 considers such aspects to be directly attributable to the complexity of the product and the competence of the team. “These things belong to the process. They have to be there. Once again the total competence of the team is valid here. That and the complexity of the product.”(R3)R4 relates the issue of quality control to the size of the project and the lifespan of the product:“they are important, especially if the project has been going on a while. If the project is short and the product has a short lifespan then quality checks are not as important as something which is expected to last a while and will probably be updated.” (R4) R5 advises that routines for quality control have to exist before the product can be delivered. We must have routines before we deliver. We have routines both before and after delivery. (R5)

Analysis

When asked for their opinions on quality control and components such as: design reviews, code inspections etc, all respondents recognised the relevance of such features. There were, however, varying degrees of enthusiasm from the respondents when considering quality control. Both R1 and R3 advised that quality checks belonged to the process and therefore were implemented automatically. R3 was particularly enthusiastic about this part of the process maintaining that quality checks had to be there. R1, although acknowledging the importance of such checks, cautioned for over ambition maintaining that quality checks can be omitted if the team is in agreement. In these comments R1 would appear to suggest that one can be over thorough with quality control. This sentiment would be challenged by R5 who suggests that quality checks may be demanded by the customer. R4 established a correlation between quality control and the lifespan of the product by informing that quality checks were vital for a product which is expected to last a while and may be updated. If the product was only expected to last a while then these checks were not as important.

2 The software development process

Information related to the theme the development process will now be presented.Use of a methodology All respondents recognised, to varying degrees, the value of a methodology when developing software. R1 considered a methodology to be affiliated to professionalism and necessary to guarantee aspects vital to the customer. R1 points out interestingly enough that the method does not guarantee the result: when you take on work you need to have a certain professionalism. You need, for example, to be able to promise that this and this will be delivered in 6 months and will cost X. You need to be able to guarantee certain things. Of course the methodology does not guarantee a result. (R1) 62 R2 as methods were relatively “heavy” to follow judgement should be used when considering their use. R2 thought that, in principle, methods should be used. in principle I believe so, of course one needs to use judgement as methods are quite heavy. A lot of time goes to following them exactly. One should use judgement depending on the size of the project. (R2) R3s response was simple and to the point:

They are very important. We rely on the method. (R3) R4 explains that a method is useful if the same thing is to be repeated. When building a smaller product R4 feels that a method may not necessarily be required. If something is going to be reproduced then it is good to have a method. When developing a smaller product one can just get on with it. Make sure you write everything down because in a couple of months you won't know what you have.(R4) R4 maintains however that methods have their place in larger projects: “[…]One can accomplish good things without a method, but when you come up to volume then you need a method otherwise you'll have chaos” (R4) R5 is of the opinion that use of a methodology implies a common working practice.R5 informs that use of a methodology better enables the transfer of systems developers between projects. I believe that it is good to use a methodology because you create a common working practice […] it should be easier to move system developers between projects if one follows a methodology. (R5)

Analysis

All respondents were of the opinion that use of a methodology had its place in software development. Three of the five respondents were particularly enthusiastic about this aspect. R1 affiliated use of a methodology to professionalism and suggested that use of a methodology may guarantee aspects vital to the customer's peace of mind. R3 offered a particularly concise response by ascertaining that the everything rested on the method.R5, in addition to R1 and R3, heavily endorsed the use of a methodology maintaining that a methodology enabled a common working practice. R2 informed that in principle a methodology could be used in software development but cautions that methodologies are time consuming if they are to be adhered to. R2 advises therefore that judgement should be used when considering the use of a methodology. R4 affiliated use of a methodology to project size informing that when one comes up to volume then a method will be required to avoid chaos

CASE tools

The respondents were not thoroughly familiar with the term CASE-tools. This term had to be explained. However, once this had been done the respondents were able to answer. When asked if these tools were necessary for the success of the project R1 maintained that the advantage with using the same tool was homogeneity: 63 the problem is, if you take them away then everyone is going to use their own way. The advantage with everyone using the same notation is that it looks the same and it is quick. There are a lot of strengths in having the same tool. (R1) R2 explained that his company have developed a development environment where automatic code is generated for certain functions. When asked if this tool was necessary to the success of software projects R2 felt that quality would suffer and cost would rise if this tool was not available. it would be more expensive and the quality would suffer. Standard functions, for example a table which utilises a user dialogue, can automatically be generated with code we can guarantee with the help of these tools. (R2)

Analysis

Two respondents gave favourable opinions regarding the use of CASE-tools. R2 emphasised aspects such as cost and quality, maintaining that such aspects would suffer if CASE-tools were not used. R1 explained that use of such tools implied certain strengths, i.e. speed in the process due to the fact that everyone was using a standard tool.

3 Estimation and scheduling

A presentation of the information concerning scheduling in software projects will now be given. Milestones and regular reports R1 considers realistic deadlines were important even if they were not always achieved. R1 informs that deadlines imply that resources can be gathered for the purpose of achieving a common goal: They are important irrespective of weather you meet them or not they have filled the function of gathering resources for the common goal. (R1) R2 informs that in the beginning one may have a tendency to rush into things. Milestones, according to R2, provide stability in the sense that one can go back and see what needs to be completed before the next phase is commenced: At the start of the project one rushes in. It may be necessary to halt the process and go back to see what we said in the beginning. Then we see what needs to be completed before we go further. (R2) R2 advised that it was important to get the team members to respect deadlines. R2  informs that it is important therefore that deadlines are realistic. R2  informs that the project can succeed if some deadlines are missed along the way but this is harder: Important! One must try to get the team members to respect the deadlines, which means that they must be realistic. The project can succeed if some deadlines are missed along the way but this will be harder. (R2) R3 maintained that milestones or checkpoints were essential in order to confirm the status of the project with the customer. R3 advises that these checkpoints are relevant when progressing to the next stage of the project It's these checkpoints where we agree that we can go further. We confirm the projects status with the sponsor and the customer. (R3) 64 R4 informs that milestones are important but that adhering to them may not always be realistic:[…] these milestones are defined in the beginning and then they should be adhered to no matter what happens in the project. This is not always realistic. User requirements, or other prerequisites, may change. (R4) R5 informs that milestones constitute the only way to clarify how something can be achieved and followed up within a specific timeframe. They are important. It's the only way to clarify what needs to be accomplished and followed up within a specific timeframe. (R5)

Analysis

When asked for opinions regarding the relevance of milestones in software projects all five respondents fervently acknowledged the relevance of milestoning and realistic deadlines. R1 implies that deadlines fill the purpose of gathering resources for the purpose of achieving a common goal. R1 does not focus on meeting the deadline but instead emphasises the concentration of effort anchored to a specific timeframe. R5 encapsulated the essence of milestoning by ascertaining that this was the only way by which to clarify what needs to be done within a certain timeframe R3 enforced the importance of monitoring the project. Milestones or checkpoints according to R3 constitute those points in time when the project progresses from one stage to the next. The status is confirmed with the customer and progression to the next stage is authorised. Confirming the status with the customer would imply that the process must have been monitored in order to ensure that all phases encompassed by the milestone have been achieved. R2 offers further support to the relevance of milestones and the monitoring of progress. R2 explains that at the start of the project the tendency may be to rush in. There may come a point where the process has to be stopped so an evaluation can take place to see what needs to be completed before the next phase commences. R2 advises that missing deadlines may, but not necessarily, compromise the success of the project. R2 further identifies the importance of realistic deadlines by ascertaining that it is essential for team members to respect the deadlines that have been established. According to R2 this can only be established if the deadlines are realistic. R4 explains that deadlines are established at project start and should consequently be adhered to. According to R4 this is unrealistic as user requirements or other prerequisites may change. Predicting the occurrence of such events is not easy but by allowing for them then perhaps more realistic deadlines could be generated. A further reference to scheduled time can be found in the responses obtained when the respondents were asked for their personal opinions on those factors that constituted software project success. Three respondents maintained that delivery within  estimated time constituted a success factor. No specific questions were asked related to software project estimation. However, when asked for personal opinions as to what constituted software project success three out of five respondents ascertained that delivery within budget was a factor for success. This can only be interpreted as implying that realistic estimation is extremely important 65

4 Development personnel

Information related to the development process will now be presented Individual competence of the team members When asked for opinions concerning the importance of team members R1 gave a decisive answer: I believe it is very important but I believe that the work climate and job satisfaction are more important.(R1) R2 was keen to point out that this was very much dependant on the type of competence in question. […] it depends what competence we mean here. In some technological areas there are many people to choose between. In other, smaller, areas everything hangs on 2-3 people. Naturally it's important to get those people into the project. (R2) R3 incorporates a similar line of reasoning to R2s. R3 adds that it is important with a breadth of competences in the team. R3 highlights that a passion for the task may even be more valuable. It's really important to have a breadth of competence in the development team. It's no use having 10 people who are great at assembler programming. On the other hand I might be interested in one. Often it's more important with an interest for the task than the necessary knowledge. To have passion for what we are going to build.(R3) R4 informs that technical competence is insufficient: If we set up a team for a 2 week job someone might say: this person can develop software, he/she can write code. It's not enough. If we are to do something in such a short space of time then it needs to be exactly the right person […] it has to do with how one is as a person so there are several types of competence. (R4) R5 considers competence to be a prerequisite for working in project form. R5 advises that when a project team is put together the intention is to acquire the people who have the best skills for the task in hand:

One of the reasons we work in project form is that when we receive a job we try and put together a team from different departments and units. Naturally we try and acquire those with the best skills for that type of project, under the assumption that they are available. (R5)

Analysis

When considering the competence of individual team member's three respondents claimed that identifying individuals with specific skills was important for the project. R2 explains that in some technological areas a multitude of people can be chosen between. In other areas everything hangs on 2-3 people. R3 means that it is important to involve such people. R5 would definitely agree by firmly establishing that one obviously tries to acquire the people with the best skills for the task at hand. R3 informs that building a team where 10 people are competent in, for example, a specific programming language is not desirable. R3 explains that one person with that particular competence is, on the other hand, very desirable. 66

R4 is keen to inform that technical competence is insufficient when working in projects which do not last long. R4 maintains that when a project is put  together for a two week job then one needs exactly the right person. R4 would imply that the personal qualities of a team member may be more important in this context than his/her ability to perform a specific task. Build the right team from the beginning R1 was uncertain as to whether it was necessary to build the right development team from the beginning. When asked, however, if the development team could be built successively throughout the course of the project R1 felt that to a degree this was possible. I think this is possible to a degree. For example you might want to add a verifications specialist or a protocol specialist at later stages in the project. (R1)

R1 indicates, however that moving people from projects may be inadvisable: I believe that people should not be moved in projects if the move cannot be motivated. You should not move people for economical reasons. (R1) R2 felt that it was certainly an advantage to have the correct development team   from the beginning of the project Of course it is better when everyone has the history from the beginning. Its easier that way. (R2) R2 continues, warning that when new members are added information inevitably gets lost when bringing that person up to speed: When a new member arrives one obviously shares all the available information but something always gets lost in this transfer. (R2) R3 is of a similar opinion to R2: If you are successful building the right team from the beginning then that is an advantage. (R3) The social aspects of team building are addressed by R3 who observes that this can inevitably affect the output of the team if this process needs to be repeated for new members: In the beginning everyone gets to know each other, everything is positive and it feels good […] in the situation of a new person coming in the induction phase starts over[…] if you keep adding people you become fully occupied with the social aspects and you end up with no output. (R3) According to R4 in an ideal situation the right team can be built in the beginning but this is not often the case. R4 advises that team members must inevitably apply team members successively throughout the course of the project You are forced to add members successively. That's the way it is. The dream is that you can get the people with the right competence from the start and that everyone gets on and no one leaves. It doesn't happen. (R4) R5 informs that building the right team from the beginning may be difficult as the ultimate goal and scope of the project may well not be fully defined. R5 suggests that events occur during the project which results in personnel being added to the team. 67  At the start of the project the scope and the goal may not be well defined. Things happen during a project which results in people being added. (R5)

Analysis

Two of the respondents considered the building of the right software team at the start of the project as being advantageous. R3 explains that at the start of the project a certain social decorum takes place where everyone gets to know one another. If project members keep being added then this decorum needs to be repeated and as a consequence output is minimised. In contrast, two of the five respondents maintained that building the right team could only be accomplished by successively adding team members throughout the course of the project. R5 motivates this by explaining that at the start of the project the project goal may not be well defined. As the goal becomes better defined the addition of more people may be required.

Attrition

People leaving the project does not necessarily imply negativity. R1 explained that this seemingly unattractive event could have advantages: It can be healthy for a project to adopt new people. Situations can arise where something may not be as good as it could be. One can then choose to exchange one of the people and try to make something good out of it. (R1) R2 is of the opinion that people leaving the project is undesirable but acknowledges that positive aspects can be drawn from this situation . It's a disadvantage to lose an asset. I've experienced it and it was annoying. […] it can also have benefits to get someone new, someone who might question what we take for granted. (R2)

Analysis

Attrition in itself is a negative feature. Indeed, as R2 explains, losing an asset is undesirable. However, both R1 and R2 advise that upon losing a person the project may acquire a new person. This new person may then be able to assess the problem situation from a different perspective and thus bring to light issues which may have, up till then, been invisible for the other team members. Allocation of roles When asked if the allocation of roles to team members could improve the motivation of the team R1 replied that it was important have an area of responsibility. Furthermore, R1 emphasises that this allocation of responsibility is important for the project to be able to progress beyond a certain stage: You should at least have an area of responsibility. […] is not always easy to come to a consensus in software development. There are many ways to solve a problem. You have to have a role which gives a person the right to say : this isn't the best solution but we'll take it because we have to go further. (R1) 68

R2 maintained that it was more important to establish what the individual should accomplish. However, R2 agreed that a clear description of roles was an important base: More importantly everyone should know what they should accomplish […] as a base it is important to have clear role allocation. (R2) R3 makes a correlation between role allocations and goals. When it's clear what you have to do you do it. We're back to goals but goals on a lower level, that my task is to complete this within this time. That's my responsibility. (R3) R4 suggests that role allocation is important to establish certainty about what needs to be accomplished: […] if people don't know what their role or task is then they don't know what they should be doing and everything is uncertain. (R4) R4 advises that the nature of project work often implies that people need to change roles. According to R4 this can only be effectively accomplished if people know exactly what they should be doing: […] in a rapidly changing project roles can change. You need to be very thorough in making sure that people know what they should do. (R4) R5 informs that some form of role allocation is important but this shouldn't be exaggerated as project members are often required to take on different roles: On the one hand I believe that some form of role allocation is important but on the other hand I feel that perhaps it's a little exaggerated because in a project environment a team member is required to take on different roles. (R5)

Analysis

The concept of role allocation was acknowledged by four out of five respondents. However, varying degrees of importance were attached to this concept. Both R4 and R5 advised that roles can change in a project and that one needs to be aware of this. R4 and R5 accept, however, that roles do have their place. R1 explains that an area of responsibility should, at the very least, be allocated. The establishment of areas of responsibility would be endorsed by R2 who advises that it is important for the team member to know what to accomplish

Ownership

Giving the team members influence over that they are working with is considered by R1 to be very important: That is very important. When the project starts it may be that not everyone agrees with the project plan […] we discuss it and arrive at a decision where everyone has had input. (R1) R2 advises that freedom can be allocated but a boundary needs to be established for the actual design so that team members do not stray outside the limits for that boundary: It is important to establish a boundary and then allocate freedom within that boundary. (R2) 69 R4 maintains that the concept of ownership is different from individual to individual. Some team members want to have influence, others are not so interested. For some people it is very necessary, that they have influence. Others don't care less. This is something that needs to be considered from project team to project team. (R4) R5 endorsed ownership: I believe it is important that they feel free, that they are allowed to be creative and make suggestions. I think that's important. (R5)

Analysis

Four respondents considered the concept of ownership to be important in software projects. R1 and R5 were particularly enthusiastic about this concept. R1 advised that it was important that the team member feels he/she has input. R5 would agree, ascertaining that the freedom to be creative and contribute with suggestions was an important aspect of project work. R2 and R4 were restrictive in their comments concerning ownership. R2, in line with R1 and R5, did acknowledge the relevance of ownership but maintained that it was important to establish a boundary within which creative freedom could be granted. R4 explained that ownership needed to be considered from project to project. According to R4 some people want to influence the design, others do not

5 The project manager

A presentation of the information concerning the project manager in software projects will now be given Qualities of the project manager When asked what qualities were essential for a project manager R1 laid particular emphasis on the project manager's personal qualities: He should be communicative, seen and heard and relatively technical. Most important is that he is available and listens. (R1) R1 was not of the opinion that experience was not necessarily a prerequisite for managing projects. R1 advised that experience could even be a disadvantage. […] experience can be a disadvantage, one makes the same mistakes etc. I believe that experience is good but not completely necessary. (R1) R1 highlights that the project manger must be prepared to take responsibility, even when the project does not go as planned. The project manager should also encourage a positive working environment: It is very important to take responsibility […] when the project doesn't go as planned the project manger has to explain for the executives why this is the case. The project manager drives the project. he should ensure a positive working environment. (R1) R2 advised that a project manager should be able to manage multiple tasks and display good judgement: I believe that it's good to be able to manage multiple tasks, be concise with what is expected and identify discrepancies. (R2) 70 When asked if a project manager should be experienced R2 maintained that this may be necessary if the project was large. R3 regarded the project manger as the driving force for the project: The ability to create a positive atmosphere so that everyone is passionate for the task in hand. (R3) R3 considers experience to be an important quality when managing software projects: […] It's very important […] software projects are typical examples of problematic situations, there are many pitfalls […] you need that experience. To manage software projects you must have worked with software. (R3) In R3s opinion the ability to make a decision was one of the project manager's most important tasks: Decision making is one of the project managers most important tasks […] he has to make a decision, he can't hide behind anyone. (R3) In R4s opinion a project manager must be prepared to take the blame for anything that may go wrong in the project. R4 highlights that it is always the project manager's fault:

The project manager must be prepared to bear responsibility for everything. It is always the project manager's fault, never the individual. (R4) R4, in line with R2, maintained that experience was more relevant when managing large projects. R4 considered personal qualities to be more important. R4 was of the opinion that decision making was a very important quality for a project manager. Additionally, R4 maintained that the project manger should have the ability to make the decision in that moment where the decision is required: Very important. You can't stand there and ponder over something or say that you'll get back to someone. It doesn't work. (R4) R5 observes that a project manager needs to have leadership qualities. He needs to be able to handle both the user and his development team. R5 informs that experience is a good quality but there will always be a first project. R5 maintains that the  capacity to make decisions is a very desirable quality even if a bad decision is made. Even if one makes the wrong decision, a decision needs to be made. (R5)

Analysis

When asked for their opinions on what constituted a good project manager qualities such as communicative, inspirative and prepared to take responsibility were forthcoming. The inspirative qualities of PMs were specifically addressed by two respondents, R1 and R3, who maintained that a PM should ensure a positive working environment. Three respondents recognised experience as a valid quality for project managers although only R3 maintained that experience was an essential quality for a project manager All respondents were convinced that the ability to make decisions was an essential quality for a project manager. This quality is captured effectively by R3 who states that the project manger has to make a decision; he can not hide behind anyone. 71 The project manager is authorised to run his/her project R1 considers that the project manager should have authority to manage the project within his/her area of responsibility. R2 was convinced that the project manager should be granted authority to manage his/her project R4 maintains that the project manager should have authority to manage his/her project and make any type of decision. If this is not possible then effective channels of communication should exist between the project manager and that person who does have that authority: Yes, or effective channels exist between the project manager and those that have that authority. It is more important that the project manager is authorised as running a project implies that many decisions need to be made. (R4)

R5 informs that because so many projects run at the same time giving project  managers full authority to run their projects is not desirable. R5 maintains that some kind of central coordination unit is required: On many occasions several projects run at the same time. Each project manager cannot be given full authority to run his project. There must be some kind of central coordination. (R5)

Analysis

Three respondents were of the staunch opinion that the project manager should be granted authority to manage his/her own project. R5 felt, however, that this was not possible due to the fact that many projects ran at the same time. R5 maintained that some kind of central control was necessary in order to supervise all these projects that run at the same time

6 Customers and users

The information related to the theme customers and users will now be presented. User involvement in the whole development process All respondents acknowledged the importance of user involvement in the development process. There were, however, varying opinions with regard to the extent of this involvement. All respondents considered customer and user to be one and the same. When R1 was asked weather the user should be involved in the whole development process a correlation was made to specific type of project: “ I think that is good when a human computer interaction (HCI) project is being run. If we are building something the customer will never see then I don't see any value in that.” (R1) R2 had a different opinion on the extent and validity of user involvement in the development process: “ I am convinced. Especially in the beginning so we can agree on what should be built. After that we can check periodically with the customer.” (R2) 72 when asked if the user can be omitted from certain phases of the process R3 pointed out that this often was the case. According to R3 there are phases in the project where user involvement actually becomes less attractive. “the customer can be omitted from certain phases[…] somewhere there is a boundary where it no longer is desirable to involve the customer because this will just cause problems. For the most part this is due to the fact that the customer lacks the necessary technical knowledge.” (R3) R3 does, however, acknowledge user involvement as being relevant: “the customer is definitely important. Take the process for example: how do you work? Do you really follow this process? The customer needs to be there and check this.” (R3)

R4 would agree with R3s first comments that the user can be omitted from certain phases. R4 acknowledges, however, that continuous not constant user involvement throughout the development process is necessary. […] there is a situation in the beginning when it is important to involve the user. After that we enter a phase where we try to “develop something” and may just require the user's involvement now and then. It is not profitable to involve the user constantly during the process. On the other hand the user should be involved continuously. (R4) R5 is of the opinion that the user should be involved from beginning to end but not necessarily in every phase: Not the whole process because we engage ourselves in things the user won't understand; technical stuff and so forth. The user should naturally be involved from beginning to end but perhaps not in all phases. (R5)

Analysis

All respondents maintained that the user should be involved in the development process. The chief tone of all responses was that the user need not explicitly be involved in every phase as this may cause complications due to the user's lack of technical knowledge. The user is knowledgeable and is authorised to make decisions R2 informs that someone on the customer side has to be authorised to make decisions. However, R2 is of the opinion that if the supplier is familiar with the environment where the system is to be implemented then this may not be such a major problem: Someone on the customer side, preferably a knowledgeable user, must be authorised to make a decision. Once again, if the supplier is familiar with the user's workplace then this may not be a problem. (R2) R3 was of the opinion that such a user was an essential requirement for a project. R3 uses the term active customer: Another important point is that the project has an active customer. An active customer campaigns for a successful project. (R3) When asked whether an active customer/user should have certain competences R3 felt that the only competence required was the ability to explain advantages and disadvantages with different solutions: 73 […] it is a competence to be able to explain and point out advantages and disadvantages with different solutions. (R3)

R4 informs that if the user does not have this authority then effective channels of communication should be established between the user and that person who has this authority: If the user doesn't have this authority then effective channels are required between the user and that person who has this authority in order to avoid unnecessary waiting time. (R4) R4 explains the consequences for the project if this aspect is neglected: […] the project plan and project goal can suffer severely. (R4) R5 claims that a user who is authorised to make decisions is an important asset for a project. According to R5 the project loses time if the user is not authorised to make decisions: It is extremely important to have users tied to the project who are authorised to make decisions […] you lose time if you have users that are not empowered to make decisions. (R5)

Analysis

Four of the respondents maintained vigorously that a user who was authorised to make decisions was a very valuable asset to a project. The consequences for a project that lacks a user authorised to make decisions are neatly encapsulated by R4 who advises that the project plan and project goal can suffer severely if such a user is not involved in the development process.

7 Requirements

A presentation of the material concerning requirements in software projects will now  be given. Involvement of the user in the requirements elicitation (RE) process R1 offers a concise motivation for the involvement of users in the RE process: I believe that the user should be present when establishing requirements. It is these requirements which are interesting. (R1) R2 informs that the level of interest, engagement and the ability to provide opinions varies from user to user. R2 emphasises that one should always try and find an interested used that is willing to help. […] it depends on the user: their level of interest, engagement and points of view. you should always try to find an interested user who can help and provide opinions. (R2) R3s response was in line with R1s: It is the user who provides the real requirements. (R3) R4 acknowledges that user involvement is very positive but due to the fact that the user may not be able to express the requirements this involvement is not decisive for project success: 74 In most cases the user has a feeling for what he/she wants […] the presumptions for success are greater if the user is involved but not decisive. (R4) R5 considers user involvement in the RE process to be somewhat of a key to the whole process. R5 informs that if the user is not involved in this phase then much will be missed: We may miss a lot. We have to get the user to talk about what he wants and how it is supposed to look. It's one of the keys to the whole process. (R5)

Analysis

All respondents were enthusiastic about involving the user in the requirements process. R2 does, however, touch upon the issue that the user has to be motivated for this task. Changes in requirements R1 explained that by using use-cases (a specific notation associated with the Unified Modelling Language- UML) increases traceability when managing changes to requirements: We try to explain requirements with use-cases […] you have already done an analysis of which components are affected by that use case. You can trace back and see what needs to be changed. (R1) R2 maintained that changes were managed by saving old requirements documents. One could then see how these documents change over time: […] save old versions to see how they have changed over time. (R2) R3 explains that requirements should be firmly anchored. If changes are to be made the person that makes that decision should have a holistic impression of that he/she is going to change:

Ensure that the requirements are anchored […] this is important. It may occur to someone that this requirement cannot be realised, we'll do this instead. The person who makes that decision may not have the complete picture in front of him/her. (R3) R3 warns of the consequences for the project if changes to requirements are not managed effectively: You verify the requirements with the customer. If you change something you get another product. When you verify later with the customer and discover that changes have been made it can be very expensive compared to what it would have been if you had managed the changes correctly. (R3) R4 enforces the necessity for a process when changes to requirements are made. Changes cannot be conferred verbally or changed continuously: You should have some kind of process for managing changes to requirements. You can't have a situation where someone says change that 4 for a 2. You can neither have a situation where requirements are changed continuously. We must have a process which dictates that we have a review and then we can change the requirements. (R4) R4 explains the outcome if requirements are not managed effectively: 75 It's not certain that you achieve what you intended. It may well be that you all of a sudden don't know which requirements are valid. (R4)

Analysis

Four out of five respondents were of the opinion that a process or procedure was necessary for managing changes in requirements. The explanations concerning this were varied and aspects such as verification and traceability were touched upon. The aspect of verification is clearly addressed by R3 who maintains that if changes are not managed effectively then the consequences can be expensive Establish complete or basic requirements from the beginning When asked if one should establish complete, detailed requirements or simply basic requirements from the beginning R1 advised that it was a real advantage to work with requirements on a higher level. You should work on a higher level. You shouldn't look at the small details […] we want to have requirements structured on a high level, preferably as use cases. I believe it's a real advantage if we can receive requirements structured on a higher level. (R1) R2 maintained that it was important to identify all the main functions in the beginning. According to R2 the level of detail can be evaluated in accordance with its associated function: I believe that all main functions should be established at the start […] one needs to evaluate exactly what we need in order to build a function. Those things we can wait with we don't ask about. (R2) R3 explains that the level of detail concerning requirements is dependent on the task in hand:

If it's a big project its dependant upon where you are in the project. the level of detail concerning requirements is much higher when we come down to those requirements the constructor needs. (R3) According to R4 there is no one way which is better, or more desirable than the other: You could say that one leads to the other. If you receive detailed requirements then you can always work backwards and establish the fundamental requirements or vice versa. (R4) R5 acknowledges that it is necessary to identify the fundamental functions in order to establish the scope of the project. R5 informs that details need to delved into almost at once in order not to miss anything. One needs to get the fundamental requirements in order to understand the scope […] pretty much straight away you need to delve into details. You need to do that in order not to miss anything. (R5)

Analysis

When questioned on their opinions concerning the level of detail of requirements three respondents acknowledged that it was important to establish a higher level of requirements in the beginning. R1was of the opinion that establishing deeper levels of detail was unnecessary when working with software. R2 and R5 would seem to agree 76 stating that it is important to identify the main functions at the start of the project. R2 effectively justifies why details can be avoided by explaining that if you do not need it do not ask about it. Whereas R2 and R1 tended to dismiss the necessity of deeper levels of detail in requirements R5 advised that once the fundamental requirements had been established it was necessary to delve into details. According to R5 this was necessary in order not to miss anything.

User resistance

R2 maintains that each user is different. Some users know what they want early in the project whereas others do not realise this until after they have used the system. R2 informs that with users who know what they want the chance of building the wrong functions are minimal. R2 is of the opinion that it is harder to achieve a successful project without a committed user: Users are different: some know what they want early on in the project, others come to life after they have used the system a while. With the first sort the risk of building the wrong functions is minimised […] usually it's harder to achieve a successful project without a committed user. (R2) R2 observes, however, that a committed, unknowledgeable user can be troublesome. R2 advises that if the system's supplier is familiar with the environment where the system is to be implemented then it may be cheaper and more effective not to anchor everything with the user. R4 maintains that if the user does not collaborate then the project has to draw its own conclusions. R4 informs that this may not necessarily be negative as the user may not have a clear vision of what they want. If the user doesn't collaborate and share his/her opinions then the project is forces to draw its own conclusions, what needs to done, what the requirements are. This isn't always negative, especially if the customer doesn't know what he/she wants. R4 suggests a solution for lack of user collaboration. R4 advises that the project can itself establish the requirements.

These can then be confirmed with the customer for review and approval. […] one way to solve this is for the project to establish the requirements etc. these can then be confirmed with the customer for review and approval. (R4) R5 was of the opinion that if the user is unable to dedicate sufficient time to the project then the success of the project will be threatened: If the user cannot dedicate that time which is necessary then the success of the project is definitely affected. (R5).

Analysis

The concept of user resistance was recognised by two of the respondents as being potentially detrimental to project success. R2 informs quite   categorically that it usually is harder to achieve a successful project without a committed user: R5 was of the opinion that if the user did not dedicate enough time to the project then the success of the project will be threatened. R4 explained that if the user was not committed then the project would be forced to make its own conclusions. According 77 to R4 this was not necessarily disadvantageous as the user may not know what he/she wants.

8 Respondents opinions on what characterises a successful software project

A presentation of the material relating to the respondents own opinions regarding software project success will now be given. When asked for opinions regarding software project success R1 maintained that time and cost were the most important variables to consider: I am orientated towards the result. I think that if you have delivered within the allocated time and within budget then it's a success. It's that simple. (R1) R2 would agree, also considering time and cost to be the decisive variables pertaining to project success. Deliver in time and within the estimated price. (R2) R3 did not consider time and cost to be the most important aspects to consider. According to R3 customer satisfaction was the most important aspect to consider: […] a project can double its costs and go behind schedule but if the customer is satisfied then you've got a successful project. ( R3)

R4 informs that if the product is at all is used is an indicator for success. Furthermore, the product should be used for that for which it was intended and gives the customer the requested functionality. The product should be: used, used for that which it was intended and gives the customer the requested functionality. (R4) From the perspective of the project R4 ascertains that project success can be derived if it is possible to follow up if the goal has been reached, how the project's economy has stood and if experiences have been recorded before the next project begins. R5 informs that delivering what the customer has requested constitutes success. Additionally, and in accordance with R1 and R2, R5 considers time and budget to be relevant variables when considering project success: To be able to deliver what the customer has requested within the timeframe and within the budget. (R5)

Analysis

Three out of five respondents staunchly maintained that delivery within time and budget constituted factors for software project success. Customer satisfaction was a concept addressed by three of the respondents. R5 claims that delivering what the customer requested constitutes a success factor. R4 would agree, adding that the product should provide the customer with the requested functionality. R3 would appear to regard customer satisfaction as ultimately decisive for software project success.

9 Summary

A presentation has now been given for all material gathered throughout the course of this report. The first stages of the analytical process have also been presented together with the raw interview data. The author of this report feels that this approach lends 78 itself towards better continuity in the report and allows chapter 7 to better focus on a more specific analysis that covers the whole report.

Cite this page