The most expensive person in the whole company can be a business user with a bad attitude. It is increasingly the duty of business users to distil their business experience into user requirement specifications for e-commerce and other IT-enabled solutions.
The IT solution team that cannot or will not listen to the business will be a candidate for replacement by an outsourced solution.
Wayne Mallinson, editor, Test Focus
Granted, they may not know how to approach the writing of user requirement specifications, but a small amount of training, cooperation with the IT solution team and a positive attitude, will go a long way in this critical, direction-setting task.
IT plays a key role in business today and in the foreseeable future. The understanding of the market, proprietary processes, key data elements, competitive business methods and other critical factors known only to business users, is now being encapsulated in IT-enabled business processes. These new IT-driven knowledge repositories and engines can form significant business assets or liabilities, depending on the way in which they are specified, implemented and maintained.
IT-savvy business users are ones that understand the pivotal role of clearly specified user requirements at an early stage. This is the direction-setting stage of the whole (expensive) exercise. This definition of requirements requires significant early involvement with the IT business analysts of the IT solution team. For new and, as yet, untried products and interfaces, it will be necessary to be involved in product prototyping and usability tests. Any time skimped here will be required ten times of you and the team, to rework anything less than a fully committed approach.
Why is attitude so important? Developing IT solutions is a complex technical-cognitive mix. It is imperative that effective communication of high bandwidth is maintained. The technical fit and understanding between the user requirement specification and the system specification, and ultimately the system, is generally only as good as the relationship between the business and the IT solution team.
The business user who issues a "three-grunt" specification, is likely to get a "three-grunt" system, and market forces will begin to suggest that early retirement option. The IT solution team that cannot or will not listen to the business will be a candidate for replacement by an outsourced solution.
So important is good communication between business users and IT teams, that many best practices are aimed at ensuring it. Examples that foster communication include:
- Drawing up of contracts
- Specification and supply of budget, schedule and enabling environment
- Early prototyping
- Usability testing
- User requirements elicitation
- Early acceptance test planning and test criteria definition
- Requirements management
- Review of risk
- Change review boards
- Information walk-throughs
- Verification of information by formal inspections
- Review software construction quality
- Review of progress
- Review of inspection and test
- Proper understanding of issues
- Involvement in acceptance testing
- Operational evaluation
The business user ought to be involved and interested in all of the above areas. Business testers and quality representatives can share some of this load, but abdication of proper interest and involvement by the best business users, if it occurs, will guarantee inadequate product development. This alone will give your competitors the edge over your business.
Figure 1 shows typical steps in a software development lifecycle. No matter how small a software increment is, it requires user requirements, test criteria and planning, and then later, the execution and acceptance of the tests.
Each of these activities falls squarely in the domain of the business. The timely and correct completion of user requirements and criteria for testing these will greatly enhance the chances of success of the relevant project increment. The business user must specify the test criteria. This ensures the outcomes have been properly thought through and that a quick idea, has been matured into written test criteria. It is the setting of the exam, the passing of which will imply success on behalf of the IT solution team.
Outsourcing of the development will not reduce the amount of effort required here. On the contrary, if an external organisation is used for development, more accuracy and definition will normally be required, as later clarification efforts will have more geographical and contractual issues at stake.
Figure 1: Software development and test products at the business to IT solution boundary
The IT solution team space shown in Figure 1 should by no means be avoided by the business. The business and/or business representatives should closely follow and give input to the construction process, quality and progress. This includes cases where the development is outsourced, and it is more critical where requirements are changing because of market forces.
Changing markets do cause requirements to change. Be careful to discern clearly here, as changing requirements can also be the result of sloppy, lame and inadequate thinking by business users and business analysts in the problem space of the market. This lack of care may be malicious, or it may simply be as a result of insufficient training or experience. It may also be exacerbated by a lack of assistance from the IT solution team with early prototyping, joint application design sessions, business analyst support, proven verification test methods or methodological support. It is expensive.
The "too busy" response from the user is encroaching on the domain of reckless. It is true that the best business users are busy, but can we trust our IT solution - that key differentiator, to "too busy", or to junior resources who do not really understand the fundamental business issues at stake? Delegate, re-schedule, recruit help, streamline processes, but do not take short cuts here or else you will end up paying more later. Observe and contemplate your past endeavours to understand this truth.
Figure 2: Business to IT solution team quality interactions
Figure 2 indicates an effective way to "straddle the divide" which exists between business and IT solution delivery. Only the direct test and quality individuals or roles are shown. Business analysts, lead developers, architects, and developers should also have involvement with business users and their representatives. This involvement is typically in scheduled meetings and reviews, but well-chosen, informal demonstrations and conversations will definitely increase the communication bandwidth, morale and the final product quality.
The ultimate responsibility for product quality lies with senior management and the business. The IT solution teams are the only ones who can build this quality. Enable them!
The most valuable person in the whole company can be a business user with a good attitude.
Share