It's the expectations, stupid
Despite years of research and development into techniques and tools for modelling the requirements of business clients, it is still too common to hear the plaintive cry from frustrated IT professionals -
"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.
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 , 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.
"You ##@@@** users, if only you could have told us what you really wanted !!!"
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.
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.
Culture is everything
We recently were working in two very different organisations. One was a very successful merchant bank and the other was a police organisation. The predominant organisational culture of the merchant bank was entrepreneurial, highly-empowered and driven by competing with other merchant banks. The police organisation had a "paramilitary" and very hierarchical culture where following the due process and rigorously documenting all activities was the norm. Any attempt to get the merchant bankers to take time to fully document their requirements was doomed to failure where as rigorous and full systems analysis techniques were totally accepted in the police organisation.
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.
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 :
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.
Functional requirements are what the client wants.
Quality requirements are often confused with functional requirements but cannot be modelled using standard systems modelling techniques. As discussed by Thomsett , 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.
Quality requirements describe how well the functional requirements must be developed.
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.
Constraints define when and how the product must be developed.
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.
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 :
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:
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:
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