Government agency needing to replace an obsolete work management and business data system

Why this case study is presented

This is a case study of a very successful project to carry out process analysis and develop requirements for a small government agency to support the procurement of new specialty software under a request for the tender procurement process.

The case study reveals the importance of thorough business process review and change planning before eliciting software requirements. It is an example of Big Requirements Up-Front for an organisation with a stable business model, using a user story based approach to defining requirements with detailed descriptions of expected outcomes.

The case study also shows how a staged approach to the analytical and requirements development work can reduce risks for both parties.

The client

The client was a government agency with about 45 staff. It has two key business functions:

• To provide content production services to other arms of government; and
• To maintain permanent, up-to-date records of government content and publish that content on its website.

To produce content, the client has to collaborate with a range of other government agencies.

Due to the nature of its work, the client and its specific business is not identified in this case study. However, the client has reviewed and approved the content of this case study.

The problem presented by the client

The client used a collection of old and more modern software systems to manage its content production projects and also to manage and report its related data.

All its project documents were managed in an off-the-shelf records management system. However, all content production projects, data recording and reporting processes were managed across three custom systems that were around 20 years old. There was some integration between two of those systems and the records management system.

The client’s initial vision was focused on replacement of the main work management and data storage software which it assessed were no longer meeting its needs and were approaching technological obsolescence.

Initially, the client’s expectations were that a new system could be developed to replicate the functions of the existing system, but with a range of improvements.

The client wanted to develop requirements for a replacement system so it could procure a replacement system via a public tender process.

The client also needed to develop a business case to secure funding for the project.

Elkera’s staged development approach

After an initial meeting with the client, Elkera assessed that, to be effective, the project would involve a more extensive review of business processes than initially envisaged by the client. Elkera would need more information to accurately estimate the scope and level of effort required to undertake the work. Elkera proposed a three-stage development approach:

Stage 1: Conduct a short scoping analysis and then provide a solution proposal to complete process analysis and all work required for a business case in stage 2. The key objective of this stage was to identify all business functions that were likely to fall within the scope of the project and relevant stakeholders.

Stage 2: Carry out all analysis, develop a solution approach, and prepare a benefits assessment for inclusion in a business case. Provide a proposal to develop the requirements in stage 3.

Stage 3: Develop requirements and other documents required to support a request for tender.

That approach was accepted by the client.

Elkera completed stage 1 within 10 days, covering initial preparation, 2 days of intensive workshops on-site and development of a detailed proposal for stage 2.

Stage 2 was completed under budget and on time within approximately 4 months.

Stage 3 was completed on budget but took approximately one month longer than projected: 7 months, rather than 6.

The client’s commitment

The client gave the project its full commitment. The project team included very senior executives and SMEs for specific parts of the work. The client team had to continue with their normal work commitments throughout the project.

A core team of senior personnel participated in most workshops and review processes. SMEs from relevant work areas were included as they were needed.

Elkera’s agile way of working

Elkera proposed that in stages 2 and 3 it would produce deliverables in strict, fortnightly iterations or sprints, using a Scrum based approach. The goal was to spread the work out evenly for both Elkera and the client’s project team, and complete it in the shortest time.

To support this approach, Elkera developed a detailed backlog of tasks for each of stages 2 and 3 with assessments of the relative effort for each task using story points. From experience, Elkera made an assessment of the rate at which it could complete each story point. Based on those assessments, Elkera was able to provide fixed fee proposals with projected completion times.

During each stage, new tasks were identified that had to be added to the backlog, and some removed. In both stages 2 and 3, there was sufficient allowance within the original estimates to absorb the additions without affecting the overall project estimates.

Forward sprint planning was very important to give the project team sufficient notice of workshops. Well ahead of each sprint, Elkera allocated tasks from the main backlog to future sprint backlogs and scheduled workshops.

In week 1 of each sprint, Elkera held new task workshops with the project team and submitted draft deliverables that were to be completed in that sprint. In week 2, Elkera submitted revised deliverables from week 1, and held workshops for tasks that would be completed in the following sprint. In this way, there was a constant flow of work with regular workshops, drafts, reviews and final deliverables. Generally, no more than two drafts and reviews were required for completion of deliverables.

At the end of each two-week sprint, the client accepted completed deliverables.

The Scrum based approach, using a backlog of tasks, story point assessments, and a strong definition of “done”, enabled Elkera to provide the client with regular and accurate earned value assessments of the project performance for both cost and time.

All workshops and review processes in stages 2 and 3 of the project were held on-line. There were no meetings on-site after stage 1.

All work by Elkera was provided by Elkera’s principal consultant who was able to conduct workshops and deliver draft deliverables at a rate that fully utilised the capacity of the client project team to participate and respond. Additional personnel would not have speeded up the work.

Process analysis and review

In stage 2, Elkera developed for each business function or process that was assessed:

• business process diagrams for the ‘as is’ state of the processes;
• proposal for process change or improvement;
• business process diagrams for the proposed ‘to be’ state of the process; and
• a benefits assessment framework that the client could use to assess the reductions in staff effort or other benefits that should be derived from the process improvement.

Process change proposals in stage 2 were kept at a high-level, sufficient to assess the expected benefits. Much of the detail was left to stage 3.

Recommendations for change

The analysis revealed several key conclusions about the existing systems and business processes:

• All three existing software systems were not well designed to align with the client’s business needs. The project model employed by the main software application was not fit for purpose. A replacement system could not just replicate existing functionality or rely on retention of any one of the three systems. All would have to be replaced by a single system with enhanced functions.
• The existing data models for business data were not adequate to meet work management and publishing needs. Data models would have to be extensively revised, creating difficulties for data migration.
• There were major inefficiencies resulting from use of multiple databases with overlapping information that did not actually meet business needs. Some business data was stored in two database systems and in manually generated files. The primary source for some information was a website CMS. There was a large amount of data duplication with associated wasteful processes. Some important planning work relied on manually generated spreadsheets.

Elkera recommended very substantial changes to the client’s project and data models, particularly to improve access to information, eliminate duplication of data entry and storage, improve reporting capabilities, reduce manual processes, and automate the production of many reports.

Client acceptance of change

When the project began, most of the client’s project team expected that there would be relatively little change to their current business processes. There was a perception that, while the current systems did not work quite as they wished, the requirements process would essentially reproduce the old system in the new system. Those expectations mainly centred on the project and data models in use with the existing systems.

Those expectations were not realistic. As the analysis progressed, it became clear that it would be necessary to substantially re-design the client’s project model and also its business data management and reporting models.

Some team members could quickly envisage substantial improvements to their way of working while others took a little longer and only did so after being assured that they would not lose anything currently available.

Many team members also did not appreciate the extent of problems outside their direct work areas. The process enabled the whole project team to fully understand the complete business.

At all stages of the analysis, the client team was involved in the analysis. Proposed changes were developed collaboratively in workshops. Together, we were able to clearly assess problems and their causes, and then work through options for new approaches. That process paid off handsomely with the project team feeling that they owned the result.

Stage 2 results and business case

At the end of stage 2, Elkera delivered a report, supported by the process diagrams, change proposals, benefits assessments and a risk assessment that provided the project description and benefits assessment for a business case.

Elkera also delivered a proposal to undertake stage 3.

The assessed benefits were considered sufficient for the client to proceed to stage 3.

Requirements approach

The requirements were to support a formal request for the tender process under which the client expected fixed-price solution proposals.

The client expected that a solution could be a customised version of a product provided by one of several suppliers who worked with other similar organisations.

The requirements were not to assume the use of any particular product or technology. The overall approach taken was to define the expected outcomes, not how they were to be delivered. Thus, requirements specified workflows and models for project structures with very detailed information that users wanted in their work processes and business reports. Generally, only usability principles were defined for data entry components.

The requirements had to have sufficient detail so that a competent solution provider could plan to develop a solution under a fixed price contract and also that the client could test it.

The client’s business is highly stable. It was assessed as unlikely that business processes would change materially in the medium term. Consequently, it was realistic to define the requirements comprehensively, without the expectation of significant business change during solution development.

That allowed a “Big Requirements Up Front” (BRUF) approach, something that is rather rare in today’s fast-moving business environment.

The requirements were planned in three packages:

• Detailed business or functional requirements
• Non-functional requirements
• Data migration requirements.

Functional requirements were developed as epics in user story format and grouped by business function. Each functional group included context information with a scope statement, description of the existing process, problems, and a statement of client objectives for the new system.

The aim was to ensure that a developer fully understood what the client wanted to achieve, and why, so they could work out how to deliver a solution.

The business rules for generating many reports for the client’s business data were very complex. The user story format is flexible and allows inclusion of as much detail as required.

The result

The client was very satisfied with the result. Together, we solved the problems that the client presented at the start of the project. It was a pleasure to work with the client.

The client obtained a comprehensive and detailed set of requirements to support its procurement. Benefits provided by the requirements include:

• The client was well placed to procure an effective solution under a competitive procurement process.
• The software to be procured will be aligned to an optimised set of business processes so that the client derives maximum benefits from the software.
• The requirements will greatly minimise the risk of disagreement with a solution provider about what is to be delivered.
• There should be minimal change only during solution development, unless there are changes to the client’s underlying business operations.
• The requirements define the client’s business processes and expected outcomes in sufficient detail that the solution provider should not need to repeat that analysis during solution development.
• The detailed requirements will support effective testing of the delivered software by the client.
• The requirements provide a complete model of the business. A user could look up any major business process and understand how that part of the business will work with the new software. Several client team members commented on that benefit.

The client was successful in obtaining satisfactory funding for the project. It was also successful in securing a solution provider under its procurement process.

The development is proceeding over an expected two-year period.

Of course, the real test of the effectiveness of the requirements will be revealed during development and on product delivery.

Lessons learned

This project confirmed that software requirements are never just about requirements. They require a review of business processes so that the business can maximise the benefits of new software.

The staged approach employed by Elkera was effective. It enabled Elkera to provide reliable estimation and planning for the next step and minimised the risks to both parties.

Regular delivery of completed work under a Scrum based approach was important to building trust and maintaining project momentum. It also minimised the risk that at the end of the project there would be a large body of incomplete work and unresolved issues. Even so, there was a squeeze at the end of stage 3 to complete the integration of the requirements components and complete proofing. We would allow more time for final integration in future.

The user story approach to requirements with detailed descriptions of expected outcomes is very effective for this kind of project.

Elkera Pty Limited