It's the expectations, stupid

"But..our clients don't know what they want!!"

There are many reasons why it has been hard to analyse and model the requirements for information systems. The first is that many of the analysis techniques that are suitable for modelling information system behaviour are complex and confusing for business and other clients. Put simply, very few administrative people in a branch office of a bank think in terms of objects, types, normalised relationships and scripts. Second, many business people are too busy to spend the time required by systems analysts for detailed system specification. Third, many systems analysts are too solution-focussed and lack the appropriate interpersonal and communication skills required to build an open relationship with the key business people. Most importantly, as we will argue in this paper, we have been asking the WRONG question with the WRONG attitude.

OK, whose problem is it?

Probably the biggest challenge facing IT management, account managers, project managers and systems analysts is the change in the relationship between business experts [clients, users] and the IT experts. As discussed by Thomsett in Business and Information Technology Professionals : An Evolutionary Perspective [1991], over the past 5 or so years there has been a fundamental realignment of the relationships between IT and their business clients.

The traditional relationship was based on "expert power". In effect, computer people adopted the standard, hands-off, expert role used in the past by lawyers, doctors and engineers where we were the experts and all the "users" had to do was to tell us what they wanted, we decided what they really needed and then, in splendid isolation, we built it for them. Surprisingly, we often got it wrong and some of our users had the mistaken idea that they could get angry. The great thing about all of this was that, instead of us apologising, we could actually get more angry and blame our users.

Recently, there has been a radical shift in the power relationships and expert power has been replaced by "business power". The business experts frustrated by a perceived lack of service and responsiveness from their IT experts and confronted by an increasingly turbulent and competitive business and legislative environment have regained the upper hand. They are demanding professional and responsive service from their IT people while increasingly outsourcing IT to external consultancies who they perceive to be more responsive and professional than their internal IT people.

As a result, the issue of determining the business people's requirements has become central to the survival of internal and external IT groups. In essence, if the IT experts have clients who are struggling to articulate their requirements, it is now the IT group's problem not the client's.

Requirements ain't expectations

For many years, computing people have searched for techniques and tools to assist in the analysis and modelling of requirements. While techniques such as use-case, data-flow diagrams, data models and even, shock ! horror !, flow-charts are useful in determining the system functionality, data and events, they offer little assistance in modelling the "softer" requirements that are a key part of the business client's expectations.

Simply, the question "What are your requirements?" is the wrong question. The right question is "What is your world ?" Once we have begun to understand our client's organisational culture, their pressures, their concerns and their way of working, we can begin to get a clearer idea of them and then it becomes so much easier to understand their requirements.

To understand their systems, we need to understand their organisational culture, their dreams and their expectations.

So..what are expectations ?

The word "expectations" has probably been abused and misunderstood than any other word in the computing culture. To many project managers and systems analysts, expectations are simply those elements of the "requirements" that were not specified by the client. To others, expectations are the difference between what the client wants and what they really need. For the battle-hardened project manager, expectations are a wish list that begin a series of hard negotiations to reduce the expectations to minimum requirements. Finally, expectations are a hopelessly vague set of fuzzy requirements that defy documentation.

However, it is our experience that expectations are a related set of specific requirements that can be analysed and modelled. It's just that data flow and data model and other system-orientated techniques do not capture all the requirements for a business system.

When a business expert talks about their expectations, they are talking about four related sets of requirements :

functional requirements

These requirements are the set that deal with the business processes, data and documents that are the basis of the information system. Techniques such as use case, OOA and OOD diagrams, data flows and data models were designed for and, when used properly, are capable of documenting these. In addition, visual development environments such as Visual Basic, Powerbuilder, Delphi and so on can also be used to capture these requirements through the use of prototypes and early working versions.

quality requirements

Quality requirements are often confused with functional requirements but cannot be modelled using standard systems modelling techniques. As discussed by Thomsett [1989], quality requirements include attributes such as conformity [functionality], efficiency, reliability, maintainability, flexibility, portability, auditability, security, usability and reusability. By using techniques such as Software Quality Agreements [Thomsett, op cit], the team can model which quality attributes are required by the clients and the level to which related quality criteria [for example, conformity has the related criteria of completeness, correctness, traceability] must be delivered.

constraints

An additional set of requirements that are part of expectations are the constraints operating upon the project. Conformance to deadlines, costs, technology platform, staffing, organisational policy and legal impact are typical constraints that are requirements in projects. Constraints have a major impact on the capability for a project to deliver functional and quality requirements. Constraints are relatively easy to model and should be documented separately to functional and quality requirements.

added value requirements

This set of requirements are probably the most important component of expectations. Traditional approaches to project management and systems analysis used extremely crude models of cost-benefit analysis. The common use of intangible benefits such as improved customer satisfaction or management decision-making to justify projects and, the lack of formal approaches to benefits realisation has perpetuated loose and fuzzy concepts of added value. As described by Thomsett [op cit], techniques such as the added-value chain, the identification of primary and secondary benefits and stakeholder buy-in can effectively model the business client's expectations of financial benefits from the project. In addition, these techniques also clarify the real business objectives.

Added value is why the clients are really undertaking the project

Given our expanded concept of requirements as expectations, the following tips can help in ensuring expectations have been fully understood:

Become a culture vulture

You must get to understand the business culture of your clients. Spend time talking with various people from the client's business area and people from other business areas who work with the client's area. Check out on factors such as :

• what is their mission statement?
• how do they recruit new people?
• how do they train their people?
• how do they measure performance and what are their performance indicators?
• how do they celebrate success?
• how do they deal with mistakes?
• what formal organisation structures exist - hierarchical, team-based?

Check out the scenery

The physical working environment and cultural space in which the client's people work can often give you major clues as to their culture and attitudes. Look at things such as:

• can people personalise their work spaces ?
• what types of posters, cartoons, photos are there ?
• do they have a place where their people can gather for informal meetings?
• do they have a formal dress-code ?
• do they socialise together - how, when ?
• what are their common interests beside work - if any ?

Learn their language

Listen to how your business client speaks and the jargon used when talking about work and private issues. The key issue here is to always ensure that you understand what their terms and jargon mean. Get used to saying something like " I want to get a better understanding of what you just said, could you please go over it again for me?" Focus on:

• what are the key terms that are used regularly ?
• how much jargon is used ?
• how aggressive, hard or soft is their language ?
• is their language based on optimism, hope or on cynicism, pessimism and negative attitudes ?
• what metaphors and images are used commonly ?

Say it once hear it many times

Finally, never interview a client about their expectations by yourself. Most people get overloaded during these types of sessions and either mis-understand or simply don't hear certain parts of the interview. At a minimum, use two people to discuss requirements. One can ask the questions and focus on the interview process and the other team member can document the interview and follow up on certain issues. Always summarise your understanding of what was said in the interview and send it back to your client for confirmation. Use of tape-recorders and so on would depend upon the client's culture.

At best, use structured sessions such as RApid Planning sessions [Thomsett, op cit] which involve the client, other stakeholders and the project team determining the scope, objectives [functional requirements], quality requirements, constraints and added value through intensive team-based techniques.

You must meet your client's expectations rather than just their requirements. Doing this requires you to get to know your clients as people first and as clients second.

Understand your client and you'll understand their expectations