Software Project Management: The Manager\u27s View

As businesses become more dependent on information technology for their operations, IS managers are under increasing pressure to deliver quality applications software on time and within budget. Thus, in addition to their technical skills, they must master the necessary management skills to lead and control software development projects. The purpose of this tutorial is to present the fundamental concepts of modern project management and show how these concepts can be applied to software development projects. The tutorial presents a broad overview of current software project management practices that evolved over the years from a variety of complex projects. The subject is presented from the manager\u27s rather than from the developer\u27s perspective. The focus is on large and complex projects because these projects are the most challenging and in need of an effective project management discipline

Ansaitun arvon projektinhallintamenetelmä sähköjärjestelmäprojekteissa: Tapaustutkimus

Competition in business is harsh. The companies are continuously seeking ways to improve the efficiency and customer experience in their business operations. Project business is one very usual way of delivering complex tailor-made systems for B2B customers. Aspects of cost and schedule performance as well as customer satisfaction are important elements in a successfully completed project. This master’s thesis is a case study. The purpose of this thesis is to review earned value management method, find out how it could be implemented in case company’s projects and analyse what difficulties and benefits the method would have compared to current way of managing projects. Furthermore, a brief look to topics of projects and project management are discussed. The implementation is started by identifying a typical project in the case company in terms of planning, scheduling, budgeting and monitoring practices. The key elements of the project are discussed and finally implementation of EVM is focused on one of them due to time limits in this thesis. A concept of EVM was introduced in the engineering process and its advantages and disadvantages are addressed. The results are validated using data from a real ongoing project in the case company. Possible future actions are provided based on the development of identified shortcomings in the EVM concept.Kilpailu liiketoiminnassa on ankaraa. Yhtiöt etsivät jatkuvasti tapoja parantaa tehokkuutta ja asiakaskokemusta liiketoiminnassaan. Projektiliiketoiminta on yksi erittäin tavallinen tapa tarjota monimutkaisia "avaimet käteen" -järjestelmiä B2B-asiakkaille. Kustannusten ja aikataulutavoitteiden sekä asiakastyytyväisyyden näkökulmat ovat tärkeä osa onnistuneesti toteutettua projektia. Tämä diplomityö on tapaustutkimus. Työn tarkoituksena on tarkastella "ansaittu arvo" -menetelmää ja selvittää, miten se voitaisiin toteuttaa yrityksen projekteissa, sekä analysoida mitä vaikeuksia ja hyötyjä menetelmällä olisi verrattuna nykyiseen projektin hallintaan. Lisäksi keskustellaan lyhyesti projekteista ja projektinhallinnasta yleisellä tasolla. Työ aloitetaan tunnistamalla, miten tyypillisessä tapausyrityksen projektissa käytännössä toteutetaan sen suunnittelu, aikataulutus, budjetointi ja seuranta. Projektin keskeisiä osia käsitellään ja lopulta aikarajoitteiden vuoksi EVM:n toteutus keskittyy yhteen niistä. EVM konsepti otettiin käyttöön projektin suunnitteluprosessissa ja sen edut ja haitat käsiteltiin. Tulokset vahvistetaan käyttäen tietoja todellisesta tapausyrityksen käynnissä olevasta projektista. Mahdollisia kehitysideoida tulevaisuuteen annetaan EVM-konseptista tunnistettujen puutteiden perusteella

The role of knowledge artefact and agency in IS project escalation

This research contributes to current academic thinking by highlighting new perspective to studying the IS Project Escalation phenomenon through the application of Agency Theory. This theory views the customer as the (principal) who needs an IS product, and the IS developer as the (agent) who creates this IS product. According to this viewpoint, examining current IS project escalation literature suggests the majority of previous studies implicitly adopted the assumption that the customer (principal) is entirely capable of identifying the requirements of the proposed IS product, and a project is prone to escalate because of the attitude of the IS developer (agent). This presents a gap in the literature in that the impact of the customer (principal) not been explicitly explored. As such, one critical aim of this research is to investigate IS project escalation by employing an extension of Agency Theory. This extended theory assumes that the customer (principal) suffers challenges of incompetence when it comes to the transfer of knowledge (i.e. requirements) to the IS developer (agent). This leads to a situation of information asymmetry on the principal’s side because of incomplete knowledge transfer. In turn, this situation develops and leads to IS project escalation. Another aim of this research is to investigate the process of requirement elicitation (RE) in IS development practice. This is to identify the role of the incorporated knowledge artefacts within this activity, in terms of how the project manager and developers effectively create and utilise these objects. Thus, this is in order to provide a possible solution with respect to the challenge of incomplete knowledge transfer. To achieve that, this research employed a qualitative methodology and collected data in two stages in Saudi Arabia by using semi-structured interviews. In this respect, in the first stage, a number interviews with 30 IS project manager form five different IS development organisations is conducted. In the second stage, a number of interviews with 10 customers form different organisations is conducted. The findings in general acknowledged and complemented a number of previous studies’ results through the employed perspective of the extended Agency Theory in this research. Considering the identified gap, the empirical evidence supported the assumption of this research, and provided a new explanation for IS project escalation which highlighted the role of the customer (principal) this time. In addition, an influence diagram (i.e. Project Escalation Framework), which clarifies the relationship between the reasons behind incomplete knowledge transfer and IS project escalation, is developed. Also, the empirical evidence identifies a number of incorporated and relevant knowledge artefacts throughout the process of requirement elicitation (RE), namely Initial Request, Features, Process Diagrams, Prototypes, and Requirements. In this respect, the discussion categorised the different roles these artefacts can act out, in terms of being boundary object, epistemic objects, and activity objects. Additionally, a process diagram (i.e. Knowledge Transfer Framework), which clarifies the knowledge process in five main steps during RE phase, is developed. Analysing a number of IS development cases in a various contexts demonstrated multiple practical applications of the Project Escalation Framework with respect to managing issues building up to and leading to several project outcomes (i.e. success, failure, and escalation). Additionally, this analysis presented the artefacts in the Knowledge Transfer Framework as critical linchpins of an otherwise fragmented process when it comes to eliciting customer requirements. These artefacts have much broader implications that go beyond acting as just a procedure to elicit customer requirements. The ‘inclusion’ or ‘omission’ of these artefacts contributes to project success or failure respectively. Consequently, this understanding will result in improvement of IS development investigations, rather than exclusively enhance RE processes between principals and agents. Furthermore, the findings provided a number of highlighted things to be aware of and useful hints which reflect professional experience from real life applications. Thus, considering learning from such rich experience in terms of employing the advantages and avoiding the drawbacks would positively reflect on IS development practice. This includes managing and dealing with challenges of IS development projects, particularly project escalation, in addition to improving RE process and enhancing the process of receiving customer requirements and ideas

The role of knowledge artefact and agency in IS project escalation

This research contributes to current academic thinking by highlighting new perspective to studying the IS Project Escalation phenomenon through the application of Agency Theory. This theory views the customer as the (principal) who needs an IS product, and the IS developer as the (agent) who creates this IS product. According to this viewpoint, examining current IS project escalation literature suggests the majority of previous studies implicitly adopted the assumption that the customer (principal) is entirely capable of identifying the requirements of the proposed IS product, and a project is prone to escalate because of the attitude of the IS developer (agent). This presents a gap in the literature in that the impact of the customer (principal) not been explicitly explored. As such, one critical aim of this research is to investigate IS project escalation by employing an extension of Agency Theory. This extended theory assumes that the customer (principal) suffers challenges of incompetence when it comes to the transfer of knowledge (i.e. requirements) to the IS developer (agent). This leads to a situation of information asymmetry on the principal’s side because of incomplete knowledge transfer. In turn, this situation develops and leads to IS project escalation. Another aim of this research is to investigate the process of requirement elicitation (RE) in IS development practice. This is to identify the role of the incorporated knowledge artefacts within this activity, in terms of how the project manager and developers effectively create and utilise these objects. Thus, this is in order to provide a possible solution with respect to the challenge of incomplete knowledge transfer. To achieve that, this research employed a qualitative methodology and collected data in two stages in Saudi Arabia by using semi-structured interviews. In this respect, in the first stage, a number interviews with 30 IS project manager form five different IS development organisations is conducted. In the second stage, a number of interviews with 10 customers form different organisations is conducted. The findings in general acknowledged and complemented a number of previous studies’ results through the employed perspective of the extended Agency Theory in this research. Considering the identified gap, the empirical evidence supported the assumption of this research, and provided a new explanation for IS project escalation which highlighted the role of the customer (principal) this time. In addition, an influence diagram (i.e. Project Escalation Framework), which clarifies the relationship between the reasons behind incomplete knowledge transfer and IS project escalation, is developed. Also, the empirical evidence identifies a number of incorporated and relevant knowledge artefacts throughout the process of requirement elicitation (RE), namely Initial Request, Features, Process Diagrams, Prototypes, and Requirements. In this respect, the discussion categorised the different roles these artefacts can act out, in terms of being boundary object, epistemic objects, and activity objects. Additionally, a process diagram (i.e. Knowledge Transfer Framework), which clarifies the knowledge process in five main steps during RE phase, is developed. Analysing a number of IS development cases in a various contexts demonstrated multiple practical applications of the Project Escalation Framework with respect to managing issues building up to and leading to several project outcomes (i.e. success, failure, and escalation). Additionally, this analysis presented the artefacts in the Knowledge Transfer Framework as critical linchpins of an otherwise fragmented process when it comes to eliciting customer requirements. These artefacts have much broader implications that go beyond acting as just a procedure to elicit customer requirements. The ‘inclusion’ or ‘omission’ of these artefacts contributes to project success or failure respectively. Consequently, this understanding will result in improvement of IS development investigations, rather than exclusively enhance RE processes between principals and agents. Furthermore, the findings provided a number of highlighted things to be aware of and useful hints which reflect professional experience from real life applications. Thus, considering learning from such rich experience in terms of employing the advantages and avoiding the drawbacks would positively reflect on IS development practice. This includes managing and dealing with challenges of IS development projects, particularly project escalation, in addition to improving RE process and enhancing the process of receiving customer requirements and ideas

Prerequisites for and impediments to success in logistics reengineering projects

The purpose of this research was to determine the most important prerequisites for success and the most important impediments to success in logistics reengineering projects. The research design was based on a hypothesized relationships between the independent variables (the prerequisites for success and the impediments to success) and the dependent variable, the outcome (success or failure) of reengineering projects, it was further hypothesized that some of the independent variables help the outcome of reengineering projects, while others have little or no impact. In order to fulfill this objective, a three-part research questionnaire was developed to measure logistics practitioner\u27s reengineering project experiences. This instrument was designed to capture measurements of success in reengineering projects and the determinants of success, prerequisites and impediments, in these projects. This instrument was also designed to collect data regarding the firms. The firms selected for this survey were firms where logistics would play a major role in the firm, such as manufacturers, transportation providers, warehousing, and distribution companies. The information regarding the firms was used to classify the firms to determine if there were any differences in the success or failure of reengineering projects within any given classification of firms. The practitioners to be surveyed were selected from three sources. The first two sources of survey practitioners were the membership roles of the American Production and Inventory Control Society (APICS) and the Council of Logistics Management (CLM). The third source of survey practitioners was the Standards and Poor\u27s database. This research found that there was a relationship between project success in reengineering projects and prerequisites for success and impediments to success. This research further found that there was also a relationship between project schedule performance and project budget performance in reengineering projects and prerequisites for success and impediments for success. Further analysis of these relationships resulted in the development of a short list of the most important prerequisites and impediments. Managers now have an opportunity to field test and verify the findings of this research. The list of 34 prerequisites to success and impediments to success developed mainly from the work of consultants has now been shortened to a manageable list. The scope of this research was the determination of the most important prerequisites for success and impediments to success in reengineering projects at firms classically categorized as logistics firms. Beyond this limited scope of reengineering projects initiated at logistically sensitive firms, an examination of other types of projects and other type of firms would be warranted

Software development project success: perspectives of project managers and developers in a South African bank.

Masters Degree. University of KwaZulu-Natal, Durban.Many researchers have attempted to define software development project success. While common factors have been found, the success of software projects in all industries cannot be judged by the same factors. Success is complex and means different things to different people. This study investigated what factors project managers and software developers, in a South African Bank, believed contributed to software development project success. The reasons why software developers and project managers were investigated were because software developers have a technical background whilst project managers have a business background. There were 41 respondents consisting of six project managers and 35 software developers that answered the questionnaire. Six participants were interviewed: four developers and two project managers. A case study research was adopted for this study. The results showed that there are many significant factors that contribute to success and failure. The study was divided into four categories to investigate the different success factors. These categories were individual, team, organisational and project. The most critical success factor from this study was the projects being strictly according to the on brief. This showed the software being built must fulfil the requirements that were defined in the project brief. The least important success factor was employees having more than ten years of experience. This showed that this group of respondents do not believe that such a high level of experience is directly related to project success. Respondents were also asked what they thought would lead to software project failure. The factor that was considered most significant was not understanding requirements. An individual factor that stood out was the level of skill of the staff. Both groups of employees believe that having the appropriate skills to do one’s job, contributes significantly to the success of a project. The only factors where project managers and developers responded significantly differently were when they were asked about work life balance and job satisfaction. Developers seemed to consider these factors more important than project managers. Project managers and software developers considered the scope and size of a project critical to project success as it ranked as the second most critical factor. Other critical success factors that appeared in the top five were the level of skill of staff, clearly defined business objectives and understanding requirements. This study contributes to existing literature as it shows that success factors that other researchers found cannot be generalized to all individuals, teams, organisations and projects. This study investigated what factors, project managers and software developers in this digital banking business unit considered to contribute to the success of a project. It concluded that there are many factors that contribute to success however, projects being on brief was the most important factor. Even though this study only investigated the views of project managers and software developers, there are other IT professionals that could offer different insights as to what success means to them. This study could therefore be expanded to include business analysts, system analysts and testers