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 cost-
effective 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 end-
user 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).
Conclusion
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.
References
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), 70-
82.

Karlstrom, D., & Rumeson, P. (2005, May – June). Combining agile methods with stage-
gate 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.