No abstract

Software development project managers may need to focus on particular issues during the development process for a variety of reasons, including limited resources. This study utilized a survey to ask software practitioners, who are at the core of development, to provide insight into some of the important early non-technical issues of software development, including those related to sponsor/senior management, customer/users and requirements management. Proposed relationships among these early items, and their relationship to software practitioners' perception of project success, were quantitatively represented through a proposed Bayesian Belief Network. The concept of 'success' was derived from a pilot study of practitioners and was 'defined' as (a) there is a project plan, (b) the project is well planned, (c) practitioners have a sense of achievement while working on a project, (d) practitioners have a sense of doing a good job (i.e. delivered quality) while working on a project, and (e) requirements are accepted by the development team as realistic/achievable. The proposed causal model provided quantitative evidence that reaching agreement with customers/users on requirements, a high level of customer/ user participation, and users who make adequate time for requirements gathering have the largest direct impacts on project success among the investigated items. The proposed model identified the following as the critical chain of events for success: (1) Having a sponsor throughout the project, (2) users who make adequate time for requirements gathering, (3) a high level of customer/user participation in the development process, and (4) agreement on requirements between customer/users and the development team. /jit 2.05 What was your responsibility(s) on this project? (Check all that apply) 2.06 What was the primary nature of this project? (choose only one) J Development (of a new system) J Maintenance (of an existing system) J Enhancement (adding functionality to existing system) J Don't know 2.07 For who was this project intended? (choose only one) J In-house customer J Customer(s) outside of your organization J Both in-house and outside customer J Don't know 2.08 This project was: (choose only one) J Completed J Completed with reduced functional scope J Cancelled/abandoned J Don't know J Other (please explain): 2.09 How long (calendar time) did this project take to completion (or abandonment)? 2.10 For which type of organization was this project developed, maintained or enhanced? (choose only one) J Business (for-profit) J Non-profit organization J Military J Government agency J Consumers/mass market J Don't know J Other (please specify): Section 3: Sponsor/Management Support and Participation and Your Project 3.01 The project had an upper-level (management) sponsor/champion: J At the beginning of the project J During 1st quarter of the project J During 2nd quarter of the project J During 3rd quarter of the project J During 4th quarter of the projectPredicting software development success JD Procaccino et al 199 ...

No abstract

When Internet technology is used within the bounds of an organization, the network is referred to as an intranet. Using intranets to connect heterogeneous systems enables information sharing between existing information systems without major changes to existing applications. This study examined organizational, contextual, and technical variables that are associated with intranet infusion in organizations. A survey was mailed to 1,000 senior-level computer executives in the United States. Six independent variables were examined using an ordered probit analysis to explain the likelihood of occurrence for different levels of intranet infusion. Results indicate that top management support, IT infrastructure, and competition positively influence high levels of intranet infusion. Organizational size is negatively associated with high levels of intranet infusion. Implications and areas for further research are discussed.

olving the wrong problem is a common occurrence in business practice. This paper presents a straight forward procedure that can be used by a decision‐making unit to ensure a more complete diagnosis during problem formulation, and suggests a solution investigation scheme. The basic idea is to avoid wasting precious time treating symptoms instead of problems, and also to gain time during the diagnostic process by starting with a conceptual framework about the nature of problems.