Introduction

IT projects tend to be executed in distinct phases. 1. determining the business needs, 2. setting system specifications for those needs, 3. programming and then 4. testing. The first two phases usually represent 50%[1] of a project’s cost. The traditional way of determining the business needs is to ask users or subject matter experts to express the needs verbally. Analysts then transcribe them and define the system requirements that will meet the needs. System requirement’s documents are finally reviewed and approved.

Traditional methodologies have pitfalls leading to delays, cost overruns, or change requests. One of the reasons is there is no guaranty users could express all their needs. There is nothing that guarantee that the analysts transcribe the business needs effectively and nothing that guarantees that users would understand the written document. Consequently, the process results in incomplete/incorrect business needs.

The known work-arounds for these challenges are limited, and include:

• Building in extra time into the budget to hedge risk of delay or over budget;
• Locking the project plan in fixed milestones. As the project progresses and clarification of uncertainties occurs, amendments to the project plan and/or scope are processed as change requests – which require a great deal of time and effort from senior leaders;
• Try other approaches such as agile development.
• Or eliminate the business requirements phase altogether by buying vendor’s solutions.

However, any work-around is only a band-aid solution to the problem. It address particular problems but leaves the root causes unaddressed. As a result, project costs often soar, and the quality of the project deliverables wind up falling standard.

Why are there uncertainties to begin with?

The root causes of business requirement uncertainties boil down to “human factors.” :

1. People have a hard time putting their visual-spatial operations into words. For example, five people explaining how they start a car will tell five different stories, even though their actions and processes would be almost identical;
2. It is hard (if not almost impossible) for people to recall detailed temporal or visual experiences out of context. For example, when describing how they start their cars people usually omit standard things they do, such as rapid visual inspections of mirrors and gages that they do automatically, without conscious thought
3. Points of view vary from one person to another. Each person has a different approach and puts their emphasis on different aspects of the process or task.

User research the “Cognitive Approach”

The Cognitive Approach has been developed over 20 years of practice with a rich body of scientific literature and industry practice.  It comprises a rigorous gathering and analysis of how people treat information. For example, to determine the business needs the Cognitive Approach gather information through observations using “think aloud” technique.  “Think aloud” technique, asks the person being observed to tell the observer exactly what he/she is doing and thinking while they are doing the task.  The observer will probe deeper into the thoughts and actions by having the participant further explain why they are doing what they are doing, and why they are thinking what they are thinking.  All of this is done “within context” – or as they are completing the task, not in a conference room away from the tools and situation that they are trying to describe. This process yields considerable subtle and non-verbal information, which other requirement collection processes leave out.

Specifying Needs by mapping User Research in User Interface

Information needs, how people process  information, is analyzed using Cognitive Task Analysis (CTA). Goals, sub-goals and methods are described hierarchically.  Methods are extracted with “how” questions, and goals are extracted with “why” questions. This provides a deeper understanding of what and how information is treated to accomplish certain tasks, which in turn facilitates the extraction of requirements.

The use of standard task elements facilitates the alignment of task and information representation with human factors and industry best practices. This facilitates the specification and optimization of the ideal information organization (Information Architecture)  and user interface to enable users to better accomplish their task. In short, better understanding on how people treat information allows better specification of information needs, which in turn results in better compilation of the user requirements.

Prevent change requests by testing prototype prior development

The first step in minimizing change requests consists (prior to any development) in simulating an optimized user interface in the field with users, using “think aloud” technique. Simulations take the form of interactive mockups, animated paper sketches, computer animation, role-play, wizard of oz, or whatever combinations of techniques providing an effective illusion of a functioning system. A series of iteration adjustments is executed until there are no more changes. Conducting an effective simulation of the user interface that matches information needs at the beginning of a project prevents the need for changes at later phases.

Results

Overall: 25% cost savings for IT projects and no change requests.

Using the Cognitive Approach in IT projects generally cuts the costs of conducting the business requirements and system specification phases in half. Since these two phases alone represent 50% of a typical IT project’s cost, the total overall cost savings on IT projects can run as high as 25% of total project cost. In addition, users get to stay in the field; they do not need to be removed from performing their daily assignments. This in turn forestalls endless meetings between users, stakeholders and analysts. Furthermore coding and testing phases are more effective, because more effective communications of user needs means that fewer changes are required as the project progress.

Summary

Tagged with: Methodology, User experience