Agile Project Management for End User Information Systems Development Angela Marie Leilani Chock December 18, 2007
University of Maryland, University College
What is End User Information Systems Development?
There are many ways to define end user information systems development. Originally, end user applications were created to optimize workplace performance for individual, groups, and departments. The development process for end user applications included implementing, managing, and supporting computing in the workplace by the end user rather than technical professionals in the information systems (IS) department (Regan & O’Connor, 2004).The Organizational Systems Research Association (OSRA) defined end user information systems (EUIS) as the application of information technologies to support business processes and individual performance with the objective of improving overall organizational effectiveness in direct support of business goals and strategies(Regan & O’Connor, 2004). Other definitions of end user computing included “the use of computers by knowledge workers without the direct intervention of professional systems analysts and programmers” (Regan & O’Connor, 2004). In this report, end user information systems and end user applications are defined as information technology solutions applied to solve organizational and business problems or improve workplace productivity. When end users create or modify software artifacts to perform their specific business functions and tasks, they tend to use available software applications tailored to their needs (Costabile, et. al, 2004). These “tailoring” activities and decisions include: 1.) Customization – The users set parameters and choose among alternative behaviors (presentation or interaction mechanisms) to customize or personalize their applications (Costabile, et. al, 2004). 2.) End User Programming – The users create or modify a software artifact using a programming paradigm (Costabile, et. al, 2004). Visual programming and macro creation are an example of this type of activity (Costabile, et. al, 2004). 3.) Simplified Software Development Lifecycle – End user developers tend to favor a more simplified software development lifecycle and make trade-off decisions between ease of use and expressiveness over complexity (Costabile, et. al, 2004). 4.) “Less is More” Planning – Users tend to keep the system easy to learn and easy to work with only a limited number of features. Only those features that are absolutely essential are available at certain intervals in the development lifecycle for users to evaluate (Costabile, et. al, 2004). The system evolves over time and new functionalities are included on an as needed basis (Costabile, et. al, 2004).
End User Information Systems (EUIS): A Field Of Study
End user development is a very important topic in today’s work environment. As a field of study, EUIS is relatively new. It is distinguished from other forms of computing because of the emphasis placed on the application of information technology to the needs of individuals, groups, and departments. EUIS is an interdisciplinary field that combines organizational development theory with information technology. It encompasses the following broad areas (Regan & O’Connor, 2004): • • • • • • • • • • Productivity tools for knowledge workers Work group computing End user development End user training End user support – a help desk, information center Knowledge management/performance support Human factors and ergonomics Business process and job re-design Change management Project Management
EUIS is highly interactive and evolves from loosely structured text, data analysis, and communication requirements (Regan & O’Connor, 2004). It requires flexibility for handling exceptions and changes which makes it appropriate for individual and departmental processing. It meets users need for a quick response and offers costeffective solutions for applications that do not have volumes high enough to warrant the expense (Regan & O’Connor, 2004).
The Scope of the Report
This report will focus primarily on the nature of EUIS development and the most appropriate method to manage a EUIS project. The remainder of the report is organized with a discussion on the growth and maturity stages of EUIS development, decisions regarding expansion or control of EUIS projects, and the application of agile methods for managing EUIS projects.
The Maturity Stages of EUIS Development
It is natural for EUIS development efforts to encounter periods of growth and maturity. At the organizational level, the activities for EUIS development are distributed across a maturity spectrum (Huff, et. al, 1988). As time passes, users and their applications have a tendency to become more sophisticated (Huff, et. al, 1988). In order to gain a better understanding of EUIS development, a maturity model was developed to evaluate the stages of advancement for these projects (Huff, et. al, 1988). Operationally, application maturity is measured in terms of the interconnectedness of the application with other components in its surrounding user computing environment (Huff, et. al, 1988). Researchers initially developed this model to describe the maturity process of EUIS development. Application maturity for an entire organization was achieved when the greatest proportion of EUIS development resources were expended (Huff, et. al, 1988). There are five phases in the maturity model and they include: Isolation (Stage 1) - In this stage, most end user applications are simple and do not involve an exchange of data with other systems (Huff, et. al, 1988). Applications serve more to promote understanding than to perform substantial work-related tasks (Huff, et. al, 1988). This stage is characterized as laissez-faire, in the sense that management has not decided on how to support end user computing activities (Huff, et. al, 1988). The number of users is small, and they have to rely on personnel in the IS department for informal support (Huff, et. al, 1988). Thus, organization-wide EUIS planning and control, formal technical support, and end user training are largely unavailable (Huff, et. al, 1988). Users develop applications with the tools they are familiar with, as opposed to the best tools for the job; largely due to a lack of awareness of what is available (Huff, et. al, 1988). Stand-alone (Stage 2) - In this stage, end user applications become integrated with the users job activities and there is observable dependence upon the application (Huff, et. al, 1988). However, the applications are still restricted in scope and are only used by the individual or the individual’s immediate work group (Huff, et. al, 1988). Formalized procedures for evaluation and acquisition of new end user hardware and software begin to take shape (Huff, et. al, 1988). In some organizations, a decision is made to standardize the products it will support and improve the opportunities for later integration of the application with other systems (Huff, et. al, 1988).
Initial operating policies and practices are also introduced to end users, notably procedures for backup and recovery (Huff, et. al, 1988). Increases in demand for enduser applications are more apparent in Stage 2 (Huff, et. al, 1988). Planning activities are initiated to cope with the increase in demand for end user development (Huff, et. al, 1988). For example, the IS manager may request all departments to submit hardware and software requirements for end user computing for the subsequent year or budget cycle (Huff, et. al, 1988). This plan provides a road map for management to understand the direction end user computing is moving in the organization (Huff, et. al, 1988). During this stage, IS professionals introduce users to basic security issues and documentation requirements (Huff, et. al, 1988). Also, users begin to develop business cases and cost/benefit analyses for new EUIS projects (Huff, et. al, 1988). The IS team may provide instruction and assistance in the preparation of these business cases (Huff, et. al, 1988). Manual Integration (Stage 3) – In stage 3, application maturity develops into an exchange in vast amounts of data and programs between end users (Huff, et. al, 1988). However, this data transfer is not integrated within the EUIS application design and requires manual intervention (Huff, et. al, 1988). At this point in its evolution, IS management turns its attention toward the impact a EUIS application will have on the corporate environment (Huff, et. al, 1988). This new focus often takes the form of a corporate end user plan, in which the IS assembles a comprehensive picture with regard to the microcomputers, terminals, software, and applications being developed or used in the organization (Huff, et. al, 1988). Eventually, cost-benefit analyses are developed to justify new EUIS acquisitions and there are post-implementation audits to determine effectiveness of the technology (Huff, et. al, 1988). Automated Integration (Stage 4) – This stage is where the work commences on the developing automated data transfer systems (Huff, et. al, 1988). It is the beginning of the integration for EUIS throughout the organization. Applications at this stage do not require data transfer through exchange of diskettes nor re-keying of data from one system into another (Huff, et. al, 1988). End user applications are now developed by users that employ effective automated connections among other organizational systems and databases of all types including corporate, user, user-developed, mainframe, or microcomputer based (Huff, et. al, 1988). Distributed Integration (Stage 5) – In this final stage of maturity, end users operate in a shared environment where databases exist at desktop, departmental, and corporate levels (Huff, et. al, 1988). Stage 5 applications are written to access procedures or data without concern for their physical location by simply describing relationships between data and transactions (Huff, et. al, 1988). In the distributed environment, the users' application (e.g., operating systems, communication systems, database management systems) fade into the background and is a normal part of the computing landscape (Huff, et. al, 1988). Its facilities are always available, easy to use, and
thoroughly woven into all of the organization's key application packages and data bases (Huff, et. al, 1988). Principal among these facilities is the distributed database (Huff, et. al, 1988). There is a serious examination of the corporate-wide use of newly integrated computer products (Huff, et. al, 1988). This strategic planning activity assesses the “fitness” of new application tools for the organization and presents conversion problems for the end users (Huff, et. al, 1988). The maturity schema detailed above presents a dilemma regarding end user application development. Project managers and end users must ascertain (a) the stage of maturity for the end user application and (b) the value of resources required for further development of the application in order to control and manage the project. In considering the growth stages of EUIS, is there anything an organization can do to manage through the stages? Two important dimensions for EUIS development as a part of an organization’s strategy would include considering the pace of the EUIS development, and its direction (Huff, et. al, 1988).
Expansion or Control: Which Is More Important?
Project managers must decide on the pace and direction for EUIS development in the organization by making a choice between expansion and control. Expansion of EUIS development can be affected by manipulating the flow of information to the user community, costs borne by the users, the ease of acquisition of new technology, and the support and assistance available to learn about end user computing (Huff, et. al, 1988). In order to control end user application development, project managers must consider restricting the selection and acquisition of hardware and software, decide on mainframe versus micro usage policies, authorize the IS department to oversee the acquisition of new technology, and determine the conditions under which end user applications can access corporate data (Huff, et. al, 1988). Expansion and control are largely independent of each other, that is, one can be changed without affecting the other (Huff, et. al, 1988). By considering low and high levels of each, four distinct EUIS development strategies are evident: 1. Laissez-faire, in which the organization has little or no interest in expanding end user computing and has no significant controls in place (Huff, et. al, 1988); 2. Acceleration, wherein the organization encourages or allows end user computing to develop rapidly and has few controls in place (Huff, et. al, 1988); 3. Containment, in which end user computing is developed slowly and carefully in a highly controlled environment (Huff, et. al, 1988); and 4. Controlled growth, wherein EUIS is developed rapidly but in a carefully controlled environment (Huff, et. al, 1988).
Eventually, issues of complexity will arise throughout the end user development lifecycle. In later stages of application maturity, the size and complexity of a typical user developed application will increase with a proportional increase in the power of development tools allowing end users to create more sophisticated applications (Huff, et. al, 1988). However, there is a point in the EUIS development lifecycle where users cannot develop and maintain a highly complex system without further support from the organization. In previous experimental studies, researchers determined that the success of a desired end user application was inversely correlated with the complexity of that application (Huff, et. al, 1988). In cases where the end user application involved low levels of complexity, i.e., relatively simple processing rules, transparent data structures, and low data volumes, the application development was successful (Huff, et. al, 1988). In cases of high levels of complexity, the end users were generally overtaxed during the specification, data design, and application development (Huff, et. al, 1988). The cause for a lack of success among more complex designs included system restrictions such as missing development tools or debugging and testing aids, and/or unavailable data structures (Huff, et. al, 1988).
The EUIS Project: A Design or Production Problem
An agile approach is a very useful method for addressing EUIS development projects. The agile approach used in EUIS development projects allows the developer to adjust the time, cost, quality and scope of the project to balance the activities such as coding, testing, listening, and designing (Keller & Keller, 2006). However, the success of an agile method for managing end user development projects depends upon whether a project manager or end-user developer perceives the problem as a design or production issue (McBride, et. al., 2007). If the software development project is considered a production problem to be solved, then the emphasis will be on producing the required documents, code, tests, and software artifacts in a predictable and controlled manner (McBride, et. al., 2007). If the software development project is considered a design problem, then emphasis will be placed upon understanding and solving the problem and less emphasis on steady progress towards project completion and deliverables (McBride, et. al., 2007). Software development projects are not alike and are not as simple as they may appear. When project stakeholders and team members view EUIS development as a production issue, they will insist that the problem is well-defined with a standardized solution. All that is required from the project is to produce a software artifact mechanistically (McBride, et. al., 2007). In this situation, the traditional plan-based project approach is most likely to be adopted (McBride, et. al., 2007).
However, a view that software development is a design process with an undefined problem domain and a solution as yet to be established, a phased or agile approach is more fitting. This approach will continue to use the traditional project management and monitoring techniques but allow the problem and solution to emerge over time in a cyclic manner (McBride, et. al., 2007). The major reason for adoption of an agile approach to manage a EUIS project is due to the “evolving” nature of the systems and the volatile nature of the users’ requirements (McBride, et. al., 2007).
Adopting the Agile Method for EUIS Development
Agile methods have been used effectively by developers to manage end user development projects. When EUIS developers maintain the right to adjust time, costs, quality, and scope for the project, they can complete the most important features for the application allowing for earlier feedback loops and keeping the project’s deadline from affecting their scope (Kalstrom, 2005). Only less important features might be scaled back or dropped (Kalstrom, 2005). Agile project methods also eliminate requirements cramming where a project manager tries to squeeze in extra features into the system on an unpredictable schedule (Kalstrom, 2005). When uncertainty about a project’s progress and how much work is planned for each phase makes it easier to add on more features and increase workloads, a developer can present the requirements “cramming” request as a trade off question – “Sure, I can do that but which feature will be eliminated given the costs and time constraints” (Kalstrom, 2005). Agile teams deliver actual functionality in running software rather than documentation and partially developed functionality (Kalstrom, 2005). In this manner, they are able to demonstrate project status to customers (Kalstrom, 2005). This helps with the communication process (Kalstrom, 2005). Controlling EUIS projects using the agile method is now based upon a short, feedback cycle which includes (1) Interactive monitoring to ensure that the planned activities are re-aligned with the task-oriented corrective actions for a particular increment or release and (2) Structural monitoring in which a review at each increment (whether the beginning or the end) gives the state of the requirements and lessons learnt from the recently completed work (McBride, et. al., 2007). This will result in broader corrective actions to the already developed product or the intended product development (McBride, et. al., 2007). The team remains focused on the development project because the tasks are split into easily managed releases (Kalstrom, 2005). This also eliminated problems associated with frequent changes to requirements where the traditional methods required going all the way back to the beginning and starting over again (Kalstrom, 2005). Engineers can concentrate on past and current releases whereas managers could think about current and future releases (Kalstrom, 2005).
After analyzing the agile method to manage a EUIS project, I have concluded that the selection of an agile approach for developing and managing a EUIS project is dependent upon its purpose and goals. The agile method is more compatible to the volatile nature associated with EUIS development. It breaks up tasks into smaller batches, provides focus to control the team’s work structure, and is a better way to communicate project status to customers and other stakeholders. The major benefit in using an agile method for a EUIS project is the ability to iteratively collect customer requirements. Agile methods accommodate change in its approach to requirements elicitation. When analysts are still in the process of discovering fuzzy requirements, a working prototype is a good way to gather feedback and make necessary changes early on in the project. Another benefit of using the agile method is in delivering work in batches for stakeholders to evaluate a project’s feasibility. The very nature of using an agile method means that a project can be assessed for its technical or operational feasibility earlier and cancelled if necessary. This prevents organizations from wasting an enormous amount of time, money, and energy working on a project that has the potential for failure. In this sense, agile methods replicate the lean process methodologies used in manufacturing and supply chain management that serve to reduce costs and waste in the value chain. Although agile methods provide a more efficient use of resources, leaders should be aware of the need to determine the pace and direction of EUIS development in their organizations. It is very important for stakeholders to understand that not every business process requires a technological solution. When end users are allowed to tailor a business process, the organization should clearly outline which processes are mission critical and develop a risk assessment for each of those processes. This process risk map will allow an organization to communicate to its employees where it is safe to practice EUIS development and when it is off-limits. Again, the agile method has merit but whether project managers choose to adopt this technique to manage projects will largely depend upon their perception of the project’s complexity as well as the initial reasons for implementing EUIS development in the workplace.
Mellor, S. J. (2005, May - June). Adapting agile approaches to your project needs. IEEE Software, pp. 17-20. McBride, T., Henderson-Seller, B., & Zowghi, D., (2007). Software development as a design or production project. Journal of Enterprise Information Management, 20 (1), 7082. Karlstrom, D., & Rumeson, P. (2005, May – June). Combining agile methods with stagegate project management. IEEE Software, pp.43-49 Costabile, M.F., Fogli, D., Fresta, G., Mussio, P., & Piccinno, A. (2004). Software environments for end-user development and tailoring. Psychnology Journal, 2(1), 99-122 Huff, S.L., Munro, M.C., & Martin, B.H. (1988, May). Growth stages of end-user computing. Communications of ACM, pp. 542 Kendall, K., & Kendall, J. (2008). System Analysis and Design, 7th ed., Upper Saddle River: Pearson-Prentice Hall. Regan, E.A., & O’Connor, B.N. (2004). End-User Information Systems: Implementing Individual and Work Group Technologies, 2nd ed., Upper Saddle River: Pearson-Prentice Hall.