DSDM Atern Approach And Agile Development Information Technology Essay
Developing general practice information systems to support ‘good’ consultations using the DSDM Atern framework: A best practice approach using collaborative working, demonstrable prototypes and regular evaluations
Abstract: UK general practice is universally computerised with computers being used in the room the consultation takes place. Practices use a range of computer systems, which have developed with the purpose to meet the needs of general practitioners and health service managers. A good consultation is considered as one that meets the ideas, concerns and expectations of the patient. Doctors’ computer use and the information system features have an impact on the consultation process. Regardless of the availability of tools to measure the impact of computer system features on the consultation, there is no clear understanding on how to integrate them into the information system development process. The Dynamic System Development Method (DSDM) – Atern is an agile framework for management and delivery of IT- and non-IT-related projects. The Agile framework has been chosen as a solution to this problem due to the fact that is effectively combines processes, people, practices and products – key factors that satisfy the real business needs of the clinic system.
1. Introduction
Over the years there have been an increasing number of project failures mainly due to improper communication. Many systems are delivered too late, with higher costs than initially agreed, and usually don’t satisfy user requirements. The aim of this report is to document the need of a productive information system in the clinical approach. In many organisations, there is a gap between the final users and the technology people. In order to identify the real business and social objectives of the clinical system and also adapt the process, as to align people and technology, there is a need for migration from the traditional top-down management approach [2]. The most suitable alternative in this case is the DSDM Atern framework.
2. Overview of DSDM Atern approach
DSDM Atern is an Agile project management framework that has been developed as a response to the necessity of codifying ways in which most project failures can be avoided [5]. The initiative of the UK information systems’ professionals to set up the Agile foundation was launched in 1994 [5]. The DSDM Consortium was formed in the early 1990s and now consists of various organizations with DSDM being widely applied in the UK to more than 90,000 projects and proving to be a reliable solution in a rapidly changing business environment [3]. Using DSDM Atern as a project delivery method, and PRINCE 2 as a project management method, we can guarantee a mixture of the traditional style of thinking with the new Agile mindset [3]. The reason I mentioned this possible integration is to put emphasis on the great adaptability of the DSDM framework.
The framework is based on a solid philosophy, aligning to the business strategy and delivering real business benefits that is never compromised. This philosophy is sustained by a set of principles, a project lifecycle with clearly delimited stages (process), defined roles and responsibilities (people) and a set of best practice techniques. DSDM Atern principles also ensure the delivery of good quality products within the time initially agreed.
There are a set of eight principles, representing the way DSDM works, in order for the project to be delivered effectively:
Focus on business need
Deliver on time
Collaborate
Never compromise quality
Build incrementally from firm foundations
Develop iteratively
Communicate continuously and clearly
Demonstrate Control
The strong fundament of the DSDM approach is good communication. Informal discussions between team members are encouraged, and interactive face to face meeting are always welcomed [3].
This “rich culture” of supporting just enough requirements elicitation must be back-up by a “no blame culture in case a mistake is made” [3, pg. 20]. The whole team is responsible for the project and a firm control over it is assured by enforcing the use of the following the techniques described below.
Moscow prioritisation: In order to deliver the right product at the right time, the requirements must be prioritised. Moscow prioritisation guarantees that the vital tasks are done first (Figure 1).
Must Haves: The “minimum usable subset” [1] that is agreed upon and guaranteed.
Should Haves: They are not the most important assets to the project, but it would be good to include them.
Could Haves: Desirable for the project, but usually de-scaled in favour of the ‘must-haves’ or ‘should-haves’.
Figure 1: MoSCoW prioritisation [1]:
Moscow.JPG
An important aspect of this principle is the fact that ‘must haves’ and ‘should have’ usually deliver 80% of the business’ requirements (Figure 1). The priorities set before the workshop commences are under continual review [1].
2.2 Timeboxes: This is a key technique of DSDM Atern. The overall project is divided in different timeboxes, each of them delivering a low-level product in an iterative way. The timeboxes usually don’t include activities. Their main purpose is to deliver a feature, but the action plan will be decided by the actual team involved [4]. Usually a timebox is between two and six weeks long.
2. 3 Facilitates workshops: This is a team based approach to communication using interactive development, effective group dynamics having as goal the production of the main idea. A facilitator is also needed to ensure that stakeholders involved don’t become stuck on a particular issue or derail from the objective [3]. The major benefit of this practice is the fact that all the stakeholders exchange opinions, increasing the efficiency of the final product [3].
2.4 Modelling: Using diagrams (UML modelling), post-its or prototypes a collaborative work will be facilitated. Modelling is used throughout the lifecycle of the project as it helps interpreting the real business needs of the customer.
2.5 Iteration and incremental delivery: Traditionally the focus of developers was to try to deliver all the user’s requirements; the feedback was received at the end of the project. DSDM changed that view by promoting the incremental delivery, with users getting involved in teams in order to provide instant feedback on the technical work. This procedure ensures errors are trapped before they become too costly to repair [5]. The prototypes delivered can be built by following two formats. The first method is to build horizontally, the system being firstly schemed at a high level and details being added later. The second approach assembles vertically, with functionality being built incrementally from firm foundations. Usually a combination between these two delivers the best results.
A DSDM team defines a philosophy of business, management and technical perspectives merged in order to deliver a high- quality final result. The framework proposes a ‘no-blame’ culture and a collaborative work that brings together business analysts, project managers and technical coordinators [5]. The project roles adopted by DSDM (detailed in Appendix A) create a more open working environment, overcoming the traditional barriers that still exist in some organizations [5].
Figure 2: DSDM Atern Team Structure [1]:
The lifecycle diagram is usually referred to as the ‘cheese and pizzas’ diagram [3, pg 33]. This is because in the first stages, Feasibility and Foundation, the bases of the project are established, similar to the cheese on a pizza. The actual pizza’s ingredients are added, the same way the project has partial deliverables following the exploration and engineering phases. The development phase can be associated with the pizza delivery box, when the final product is tested and ready to be delivered to the customer.
Figure 3: DSDM Atern lifecycle [3, pg 34]:
Having mentioned and explained some of DSDM’s principles and good practices, my conclusions are that DSDM offers a reliable and simple solution for project delivery. This can be characterized by the following actions [5, pg xx].
Development is a team effort
Development is incremental
Never compromise quality, time and cost (Figure 4)
High quality demands fitness for purpose as well as for technical robustness
Figure 4: Traditional vs. Atern approach regarding quality, cost, time and features [3]:
3. Use of DSDM to develop clinical systems – the best practice proposal
3.1 Defining system features:
The involvement of computers in general practice techniques has had a significant impact on the efficiency of consultations. However, these techniques have to be well documented and investigated. Computer systems offer a reliable solution for clinical data recording [15]. With the use of computers, the maintenance of disease records, blood tests and appointments is much easier [15].
Patient care is a team activity [22] involving physicians, nurses, admin staff for whom the share of information and activity co-ordinating is an important factor in making vital clinical decisions. The UK GP computer systems have appeared as a necessity to facilitate the work of repeated prescribing [15].
Hospitals are seen as a network, involving people and technical equipment. The social aspects of the doctor-patient interaction have a major impact on the advantages introduced by the clinical computer systems. Building such a system is a demanding job as it has to respond to real time queries, be easy to understand and use by a non- technical person and also work in a high speed pace [15].
Routinely collected data from different Electronic Patient Records (EPR) usually serves as subject for further research or as a standard to improve quality. This information is generally stored in distributed databases. There are some problems associated with retrieving data from the heterogeneous distributed databases, such as the different architectures used, the possibility of misinterpreting the semantic information or different layers of access to the information [20]. This approach is taken because the patient’s information is a mixture of data, facts, opinion from a range of professionals. Nevertheless, this information has to be accessed by doctors with expertise in different fields [20]. Staff members should be able to enter all the details of a consultation into the system from the point they are generated (e.g. laboratory, pharmacy, nursing house). These may be then stored into a central server, from where the database can be queried to retrieve the details of a particular patient. Using software prediction algorithms the system may be able to organize the patient’s information in a specific format that can be interpreted by the healthcare provider [20]. In order to evaluate the impact of a clinical computer system on the consultation, UML diagrams can also be used [14].
3.2 Requirements and user interaction:
Many of the EPR have developed according to the preferences of an individual doctor who initiated the system [13]. Therefore the functional components, their features and usefulness are usually performed in a different way. The personal touch of a doctor and the way he interacts with the patient has a major impact on the final deliverable [13]. The main functionality of such a system is to cure the patient by initiating investigations and by monitoring his progress. Therefore it is safe to assume that the health care and process expertise is required in order to improve efficiency and effectiveness across the health system. Nevertheless patient safety is also an important factor [13].
The combination of opinions of various practitioners must be stored in a relevant way in a patient’s records. This requires good communication between the GP and the technical staff. From the technical perspective the problem is regarded with a degree of complexity as it doesn’t look like any other application they have encountered. The health systems aimed at offering patients a better job has special requirements and differs greatly from the usual software application done. There are different clinical systems available or under development at the present time [7]. However, a lot of complaints have been registered in the clinical community regarding the quality of deliverables, time and money spent on it and the final result. There have been two traditional responses to this problem. The first one does not believe in this complexity and predicts that everything will fall under the wide principle of ‘enterprise interoperability’ [7]. The second approach totally denies the complexity, which gets pushed to the requirement side, specification and design of the ‘solution’. Finally the whole piece crashes under its own weight [7].
The health system was intended to be reconstructed by approaching a waterfall (top-down approach) addressing untested requirement, too thick documentation, too much work done up front [7].
Based on the results of my research, I have identified four major unresolved issues regarding clinical systems:
Requirements: The team developing the solution is not fully aware of them, whether they are realistic and flexible enough [7]. Too much work done up front.
Specification: How do we frame the practical development, procurement and standardization of health record system?
Problems are compounded by different departments and individuals, driven by conflicting priorities and interests.
Implementation: How do we approach implementation and user capacity building so that health records are practical and can contribute effectively in both health and social care? [7].
3.3 Proposal of DSDM Atern:
From the reasons mentioned above it can be noted that a DSDM Atern framework implementation would be appropriate. Atern promotes user involvement and, moreover, working relationships are important aspects that can balance the technology input [19]. There should be a degree of involvement of the caregiver in the project, whereas his requirements should be parallel with the system’s requirements [10].
DSDM encourages effective team work and a structure where each stakeholder can express his opinion. This framework really aligns to the clinical system’s strategy by delivering factual business needs. During facilitated workshops and daily stand up meetings, stakeholder’s input is needed and is continually reviewed in order to produce quality content.
Using this framework there will be just enough work done up front. Most of the time is difficult to elicit the requirements from the very beginning. DSDM establishes the requirements at any stage by adopting an iterative approach. The requirements expressed by the health system would be given prioritises during the iterative lifecycle.
The pre-project, feasibility and foundations phases enable the business problem to be expressed and ensure that the project is worth doing. Furthermore the clinical requirements are aligned to the business strategy. In the Exploration and Engineering phases products are delivered iteratively, while the requirements are reviewed and feedback is given. The features delivered at the end of each timebox are built form firm foundations [1]. The DSDM’s lifecycle is developed in iterations, enabling the system to perform a “sufficient number of essential patient management tasks”, fulfilling in this way the initial objective [23, pg 1].
The project’s responsibilities must be shared by caregivers and technology specialists [10]. DSDM ‘s focus on people would allow the caregiver managers to work together with the IT managers, the Chief clinicians that represents the physician community, the technical leaders etc [10]. Caregivers would also be interviewed by business analysts to identify “issues regarding workflow and data needs”, whereas others may act as business ambassadors, being proactively involved in the delivery of the product [10].
Making medical records available, providing accurate patient status, performing insurance verification and providing immediate notification are some of the tasks required from the clinical system. Each of them will be developed in a DSDM iteration, composed of one or more timeboxes [23].
In order to prioritise the system’s requirements a DSDM technique is mandatory (e.g. MoSCoW prioritisation). Must haves together with should haves will most probably cover 80% of the project’s needs. Once these decisions have been made, scalable prototypes are modelled to make communication easier and more intuitive between stakeholders. Another significant advantage is to see actual features delivered at an early stage.
Due to the clinical system’s specifications, I consider that a vertical approach would be the best. By using this method every item is understood and acknowledged before the implementation of the next one starts.
The eight principles of DSDM Atern are sustaining the techniques mentioned above. They make sure that the customer receives a product with the exact specifications required.
There is also a need for testing and evaluating the application. After the deployment phase finishes, the system design features, such as navigation methods, layout, coloristic, display of alerts and prompts, will be appraised [12]. One appropriate tool used to perform this job is ALFA (Activities Log Files Aggregation) Toolkit. It offers a more precise observation of the clinical consultation [12]. This task is performed by comparing elements of EPR systems such as computer use, verbal interactions, and non-verbal into a single output [12].
4. Discussion
Computers are used in clinical consultations in a variety of ways [15]. There is sufficient evidence as to develop methods for testing and comparing the benefits offered by technical software, compared to the traditional paper systems. This ‘going digital’ [18] approach has benefits for all the users involved. The patients get a more efficient and secure system while staff are able to access the records much faster [18].
Computer-based patient records systems will have the ability to allow higher care delivered at a lower price. In order to take factual advantage of the benefits and, moreover to maximize them, high attention should be given to the requirements’ elicitation [11]. There has still not been developed a system that meets all the user requirements. Therefore the health care organizations are still reluctant to fully adopt such a system. Even if the implementation of this system will be at the expense of a higher cost, this expenditure can be justified by its many benefits. Some studies have identified that the cost of retrieving a paper record and taking it to a physician at the required time of the treatment ranges from 2 GBP to 14 GBP [11]. The paper work from hospitals can be discarded by applying the DSDM principles and techniques.
Health care organizations turn to clinical support systems to help caregivers with patient specific assessments and recommendations. It has been proven that clinical systems improve practices such as prescribing medicines, reducing human medical error and improving adherences to recommended standards [21]. More than 95% of the general practices are now computerized [9], but there are no standards enforced for such a development.
One of the reasons seems to be the preference for the development methodology chosen. As mentioned previously, software developers did not know at the start how to handle such a project because it was very different than the previous ones (e.g. banking, on-line shopping), in terms of complexity, user involvement and processes.
A move from this traditional, technology centred, top-down approach to a more agile development is necessary to support systems that revolve around the work of highly skilled professionals. The traditional approaches focusing on building the requirements around the centred software, whereas DSDM Atern looks at how technology will be incorporated into the daily activities [6].
Atern gathers enough requirements at the start of the project as to be able to deliver a first functionality, as required by the user, in due time and within budget. Creative feedback and responses will be drawn from the issues that may appear in the development cycle, to further assist in the creation of the system.
A comparative analysis conducted between the use of computer and clinician – patient interactions should determine theoretical models to the “computer mediated consultation” [12]. The ALFA toolkit could be used as an indicator of clinical performance and also to assess the reaction of the patient [12].
More research is needed to further study the benefits of standardising DSDM Atern as the appropriate framework for clinical systems [12]. The people leading the ‘Connecting for Health programmes’ are frequently questioned whether they will succeed to deliver a concept good enough to cure 75% of the ill people [12] by simply relying on an IT solution. A possible alternative would be to focus on simpler tasks, and execute them. In time, this will build a proficient system, and the DSDM Atern is the perfect framework to start with.
Thorough analysis of the information needs and work flow requirements will ultimately help the system developers to design an information system that will increase the efficiency and effectiveness of clinical practice throughout the continuum.
5. Conclusion
The development of information systems is complex and costly but critical to the success of the organization [24]. Other factors that measure effectively the quality of such a system are patient’s care and satisfaction [24]. The increase in the demand of computerised clinical systems is based on the growing concern regarding the “context and value of clinical therapies “[11] and a recent focus on health services research [11]. Increasingly computers are winning rapid ground in being accepted as a tool for enhancing efficiency in all facets of everyday life [11].
In the light of the nowadays IT need, backed up with a growing demand for reforming the health system [11], in my opinion DSDM Atern is a feasible framework to adopt for further development and integration.
Appendix A:
Table 1: Roles and responsibilities in DSDM Atern framework:
Project level:
Role:
Responsibility:
Business Sponsor
Owns business case and certifies ongoing viability of project in line with the business case.
Ensures funds and resources are made available and makes decisions on escalated project issues
Business Visionary
Maintains organizational perspective on changes and defines business vision for the project.
Communicates the business vision to all parties and ensures the project is in line with the vision
Makes decisions and approves changes to high level requirements and design
Collaborates between stakeholders and ensures resources are available
Project Manager
Communicates with senior management and project governance authorities.
High level project planning and scheduling
Monitoring progress against project plan
Technical Co-ordinator
Agreeing and controlling technical architecture and environment
Co-ordinating team technical activities
Identifying technical risks
Ensuring non-functional requirements are met
Solution Development level:
Role:
Responsibility:
Team leader
Encourages full participation of team members and focuses the team to ensure on-time delivery of agreed products
Ensuring that iterative development is focused and controlled and all testing and review is properly carried out
Managing risks and issues and reporting progress
Running daily team meetings
Business Ambassador(s)
Contributes to requirements, design and reviews
Provides business perspective and detail for decisions and to help define and test the solution
Ensures the solution is evolving as required
Develops business user documentation and ensures end user training
Business Analyst(s)
Ensuring communication between business and technical participants
Managing development, distribution and baseline approval of all documentation and products
Ensuring business implications of day-to-day decisions are thought trough
Solution Developer(s)
Working with Business and Solution testers to develop a deployable solution
Design and apply models required for controlled development
Models and documentation required for supporting the solution in live use
Recording any changes in detailed requirements, re-work and information that may influence the solution
Adhering to technical constraints, standards, and best practice
Participating in quality assurance work
Testing outputs prior to independent testing
Solution Tester(s)
Designing test scenarios and test cases
Assisting the Business Ambassador and Advisor to plan tests to ensure important areas are covered
Carrying out all technical testing on the solution
Reporting the results of testing activities
Other:
Role: