The psychologist as business analyst
The Performance Technologies Group
Category: requirements | Author: Craig Errey | Date: 26/09/2006
Requirements are a critical determinant of IT success
At a recent seminar by our partner Object Consulting on requirements, one of the speakers, Chris Sirosky, made the comment that he wants BAs who really understand how businesses function and how people work, rather than those with a strong technical focus.
The whole point of his comment is related to the critical role requirements has in the success of technology projects. We all know the adage 'if you fail to plan, you plan to fail'. According to an SEI research report (2004), poor requirements is a primary reason for cancelled or over-budget projects and around 50% of all defects originate during requirements.
We all intuitively know this to be the case, but things don't seem to be getting a lot better in terms of overall IT project success rate. So it begs the question, even when there are BAs on the job, why are projects still unsuccessful in terms of cost and time overruns and defect rates?
This got me thinking about why we have employed so many psychologists at PTG Global for user interface requirements and design: what about the psychologist as a business analyst (and the play on 'analyst' was not lost on me!!). This paper discusses the BA role and how a psychologist should be an essential member of the requirements process. The criticality of requirements and that there are hundreds of 4-year graduates to 6 year qualified psychologists out there suggests that the BA role could be a new career path and a solution to the skills shortage.
What is a BA?
BAs that I know come from all sorts of backgrounds including liberal arts, computer science or even no formal training. Wikipedia on 'Business Analyst' provides a good overview of the role. Most telling in that overview is the comment 'there is no one defined way to become a Business Analyst'. What are the implications of this? It means that there is no standardised skill set of the BAs you're probably using right now and they are not necessarily following the same process, in the same way.
When you get an accountant or financial planner, the first thing you do is make sure they're qualified. This gives you confidence that they're all following the same rules and approaches so what they do should work. If the BA takes on the most critical role in an IT project, getting the requirements right, yet there is no standard qualification process, can you be really sure they're doing it right?
UML and use cases in requirements
But wait, you say, don't BAs use UML and use cases as a standard? UML has a strict purpose and it is to specify the model of a system in a relatively abstract way and it was designed to produce the artefacts necessary for object oriented development. Within UML, the use case is used to document the functional requirements of the system. In our experience, we find that the BAs documenting use cases start with documenting what people will do with the system, but quickly end up specifying the deep system messages between applications (e.g. between middleware and underlying legacy systems) and using state diagrams.
Unfortunately, the use case and UML becomes more about the system then it does about how people go about their work because that's often the easiest thing to specify. The interrelationships between people, work and performance are complex and require specialists to understand and model the dynamics. BAs don't necessarily have a strong understanding of organisational dynamics and can embed what the organisation does now into the application, rather than what it should be doing to improve performance.
The UML notation for use cases is something that the executive and end users cannot easily understand and sign off. If it’s difficult to read a complex representation of what should have been the person's job, when there is no way they can review it for accuracy or relevance.
We also find that people do use cases and UML is slightly different ways, meaning there can be issues with consistency from one BA to the next.
Are we rejecting use cases? Certainly not. The issue we have is that the use cases are so granular and end up specifying the minutiae of the system that it is impossible for lay people to understand them and for developers build a simple, easy to use interface from them.
About psychology and the psychologist
I mentioned earlier that there is no 'BA school' that teaches budding BAs a standard set of skills, knowledge and methods to capture requirements and convey them in a manner that everyone involved with the application and its development can understand.
I also mentioned that we preferentially hire psychologists. We make a big deal about this to our customers, but I don't think we've ever taken the time to explain to them exactly what a psychologist does and why it is relevant to IT and, more specifically, to business requirements.
I think that most people only have a vague idea of what a psychologist's skills and knowledge really is, and that it is probably inaccurate. Most of the misconceptions are fuelled by the endless rows of questionable self-help books in most bookstores.
Here's the quick guide to psychology and the psychologist.
There are two main branches of practising psychologists: the clinical psychologist and the organisational psychologist. There are specialists within each, including forensic, educational, sports, neuro- and counselling psychologists. We'll focus on the organisational psychologists here, but you can go to the APS website for more information on the different types of psychologists.
You become a registered psychologist (in the same way medical practitioners and lawyers must register to practice) by completing a four year Bachelors degree in psychology and undergoing 2 years of supervised practice with a registered psychologist. Alternatively, you can complete post graduate courses, including a Masters degree (coursework and research thesis) in psychology that includes the supervised practice, a PhD, or a combined Masters / PhD. Some universities also offer a Doctor of Psychology as an alternative to a PhD.
What an organisational psychologist learns
The psychology degree, specialising in organisational psychology, covers a range of subjects. We've covered some of them here and included a brief explanation of what we learn about.
| Subject | Explanation |
| Research methods | Experimental design and statistical methods to support scientific enquiry |
| Social psychology | How people relate to each other, social dynamics, verbal and non-verbal behaviour |
| Personality and individual differences | The structure and the processes involved in the organised functioning of individuals, their traits, cognitions and motives, and how people differ from each other |
| Psychological assessment | The development and usage of psychological tests to measure, for example, intelligence, personality, motivation, satisfaction and specific skills |
| Cognitive Development | The process of intellectual and social development over time, how people learn |
| Perception | How people perceive through the five main senses, perceptual reasoning, visual object recognition |
| Cognition and skill | How people process and use information, the acquisition of knowledge and skills, problem solving, reasoning, logic and decision making |
| Organisational behaviour | How an organisation functions including job analysis and design, selection, of work, organisational culture, training design and evaluation, consumer behaviour, organisational change and development, organisational learning, culture analysis and change, performance management, leadership, communication and ergonomics |
| Neuropsychology | The structure and function of the brain and their relationship to cognitive and emotional functions |
| Counselling | Development of counselling skills to work with individuals to address issues like stress, personality and social disorders |
| Ethics | The ethics of psychological practice, including research, working with people, confidentiality |
You can read more about these subjects at the UNSW psychology course guide.
The role of the psychologist in business analysis and requirements
If you agree that purpose of software applications is to help businesses and people work better, then the capture and documentation of those requirements is something that the psychologist is clearly qualified to do. Specifically, the psychologist can do the following for your next IT project:
- Evaluate people's performance and identify how to improve it
- Analyse the performance of an organisation and determine the causes
- Design and drive organisational change and development
- Analyse and redesign jobs to improve performance
- Evaluate and document workflow and team interactions
- Create a training program to teach new skills and knowledge
- Evaluate and improve occupational health and safety
- Establish performance management and reward systems to sustain improvement
- Evaluate and improve the ergonomics of technology and workplaces
- Understand the consumer psychology to determine behavioural drivers
I would argue that these skills are more important than knowing UML and use cases. After all, an organisation is not a collection of use cases — they are about people, working together, to deliver services and products to other people (i.e. your customers).
The documentation used by psychologists to describe the organisation includes the humble job description and flow diagrams — notations that everyone can understand. It describes people's activities, the processes they go through, the information used and the decisions being made. The psychologist can work with you to improve the way people work before you embed the old ways into the technology. Starting with people is the right place to start — but working with and understanding people requires specialist skills.
Conclusion: The psychologist as a critical business partner
Next time you're looking at your requirements documentation, consider whether a workflow and job description is easier to understand than the hundreds of pages of use cases. Sure, a BA can create a workflow for you, but will it contain the richness of human behaviour and organisational dynamics? Will it reflect the best processes for people?
Psychologists know about people, but can draw on the skills of the BA for the technical representation of the requirements. The psychologist can also learn these techniques and provide a stronger bridge between business and technology.
So if you think business requirements should be more about the business and people than the technology, then consider putting a psychologist on the team. Most organisations need some help to improve and the psychologist as business 'analyst' makes perfect sense.
Get a psychologist to evaluate and improve your organisation first, then look to the use cases to create a bridge between the business and people requirements and the technology requirements. Organisational performance is about people first, technology second. The technology must work for people, not for its own sake.
