Let the End User Be Your Guide
Although my career has been primarily in OSes, transaction processing, data management/database and network implementation—along with consulting later on—I’ve also participated in application development projects. In my early years, I and an IBM consulting system engineer designed and developed a field developed program called Trend Analysis for CICS/VS, one of the first graphic analysis tools in the field. In addition, I and an IBM insurance industry specialist produced—in punched card format—a prototype, CICS-based online insurance claims processing application for a client.
My primary focus remained on IT systems and I became an IBM regional specialist in those disciplines. But I also participated in other projects:
- The first radio-based online CICS application for truck deliveries, dispatching, fuel efficiency and other metrics for a nationwide trucking company
- Converting a claims processing system from IMS DB/DC to CICS and Db2
- Implementing encryption and (Payment Card Industry (PCI) compliance in a mail-order system to protect credit card data
- Modifying an online Accounts Receivable system to process a state-based, three-payment credit system
- Implementing software to connect a marketing website to CICS TS
I likely ended up on so many application projects was because while in college, I’d developed and implemented a student records system for the MBA program I was in; that was rare in my type of job (technical marketing). In any case, it gave me a broader perspective that most of my fellows didn’t have, and that viewpoint increased my awareness of a fairly universal attitude among most application development units: While end users of a proposed application could be helpful in an application design phase, once the project had begun, the end user’s role was essentially complete until the application was rolled out. That’s a recipe for disaster.
I’ve observed more application rollouts than I’ve participated in, but in both cases, usability is an aspect that doesn’t get anywhere near the attention it should. Other considerations like meeting a published schedule, adhering to requirements, minimizing project cost, debugging and testing, responding to political demands, and performance/availability consume a large part of the development effort.
Once the design phase is complete, end users are often disconnected from the development effort until the project is nearly complete. That’s a big mistake. The primary objective should be to provide business units with the best tools possible, and that means end users need to guide IT every step of the way.
End Users and Developers Should Be a Team
A good application development project is the productive intersection of two distinctly divergent groups of people, with widely divergent job responsibilities, descriptions and aspirations. The end-user group tends to be people-oriented, while programmers are technology-oriented. End users are more business oriented, programmers more project-oriented. The ironic twist is that while this often tends to make both groups feel awkward with the other, it can be a huge asset, for the melding of their two talents represents a powerful resource that can produce robust applications far superior to what either entity could individually produce.
End users are usually involved in early design to help define specifications and requirements, but after that, aside from occasional phone calls or cubicle visits, programmers go one way and end users another, reuniting when the project is nearing completion. The Accounts Receivable project previously mentioned was like that, and despite warnings to management that we needed our users to validate our work, we were told deadlines were deadlines and our suggestion was denied because the delays associated with a comprehensive review were unacceptable. Besides, they’d signed off on the design weeks ago, and no changes or corrections had been submitted since then.
So the day came when the coding and programmer testing were almost complete, and end-user testing of the new app was scheduled in an online test system that had been populated with production database extracts. Some senior Accounts Receivable specialists gathered a number of test cases, some simple and basic, others with a high degree of complexity and some exceptions to normal processing. You can probably guess the outcome: The easy transactions mostly ran well but the Accounts Receivable staff didn’t like the screen design, cumbersomeness and transaction linkage. The rest was a disaster, because more transactions failed than completed normally. A long road lay ahead for us, and the deadlines were missed by months as significant effort and time were exerted to get things fixed.
It didn’t have to happen. It shouldn’t have happened. It was inexcusable it happened, but it was no surprise to us. I discovered this wasn’t unusual for my client and it isn’t for many other companies. If IT and Accounts Receivable hadn’t been so segregated from each other, many defects would have been detected and fixed during development. Since many errors were due to miscodings or logic mistakes that propagated between transactions, failures multiplied as code got copied from one program to another. It was a debacle that required a lot of work and time to resolve, and could’ve been avoided had programmers and end users worked as a team.
Practice Unity and Equality
This example demonstrates the consequences of shutting end users out of everyday work in development projects. It’s proof they should be equally empowered to direct and decide, even though the project manager usually comes from IT (where project management expertise normally resides). The project manager’s top priority must be to cultivate teamwork and unity that produces synergy between participants. The project kickoff meeting should include strong representation from both departments, common goals must be established and confirmed, and an initial project plan participants enthusiastically support must be created.
This message of unity and equality is a rallying cry a project manager shouldn’t just preach. He or she needs to sell it, practice it and champion it. It starts with the kickoff meeting and propagates itself throughout the project via weekly project tracking meetings and milestone events that involve more participants. These are good opportunities for users and programmers to interact, but this interaction should be extended to informal interactions on a regular basis—for example, a user has an idea they’d like to discuss, or a programmer wants to verify a function with a user. This is the kind of interaction regular people with a common goal take for granted.
Because users know business flow, functional granularity and unwritten rules or procedures far better than IT, their input is key to good screen design. Regarding processes, users know the flow of actions required to complete a business process or sub-process. These factors determine work segmentation, which determines module structure. End users know from experience how things are done, yet in many cases IT determines this via programming standards, performance metrics or other programming considerations, which can result in cumbersome transaction trails.
Conflicting Priorities
This is not to say there won’t be resistance from the end-user side of things as well. It’s the experienced and talented individuals that can contribute the most to the application design and construction, and end-user management may be reluctant to commit their best resources to anything that degrades optimum performance of their own unit. It’s important to convince this management that the short-term drop in resource will more than be paid for in producing a maximally useful system that will reduce and streamline resource requirements in the long term, and provide superlative usability.
Success Is an Exercise in Creating Win-Win Situations
The best project management infrastructure is one that not only includes, but involves each person affected by the project’s deliverable(s). Inclusion engenders a sense of ownership, ownership engenders commitment, which in turn engenders action. Effective project management and a thorough project plan are the genesis of a union of IT staff and one or more end-user departments. As disparate units morph into a team, productivity, quality and camaraderie skyrocket. The final product produced from an application development project should be a system that’s as much a byproduct of end-user effort and input as the effort invested by IT programming and quality assurance.