Poor requirements?

Starting point for outsourcing: the current situation

An ever-growing number of organizations is exploring the possibilities of IT-development outsourcing and many have decided to take the leap.

Requirements engineering is a key factor in enabling successful outsourcing that most of these organizations have not yet mastered fully. Best practices such as requirements validation, product ownership and backlog grooming are not business as usual.

Omissions in the requirements engineering process cause uncertainty and many hours of discussion within software development projects. The various disciplines within the development lifecycle repair these omissions and vagueness on the fly, aligning them towards a useable final product.

When development fails to align the end result with expectations, acceptance testing prevents failures being deployed to production. Copious redesign and rebuild will, in the end, lead to acceptable software. Later than planned and at a higher cost maybe, but satisfying all the same. As long as these internal correction processes remain, projects can do reasonably well.

Fear of outsourcing

Outsourcing changes the game. Alignment within the development lifecycle will be governed by a formal rule set between the client and the outsourcing partner. The complexity of this arrangement is heightened by physical distance, sub-contracting and conflicts of interests. Outsourcing promises lower costs and higher flexibility but often delivers rigidity and higher cost for contract extras.

Experts within development organizations on the brink of outsourcing acknowledge these risks. They know the current state of affairs and have mastered the art of alignment on-the-fly. How will outsourcing deliver comparable service and products when the quality of input and instruction is poor? For this reason these employees foresee significant rises in project costs and lead-times.

Garbage in is garbage out. Professionals often think of outsourcing as an organizational threat, assuming their development processes are fixed. They have a genuine, heartfelt fear not only for their job, but for the change and subsequent harm to their organization.

Change your mind-set towards outsourcing

Employees will express their fears, which are often misinterpreted as fear of change in general or rabble-rousing in order to preserve their jobs. For this reason, arguments against outsourcing are often put aside by (C-level) management. One of those arguments is the need for decent software development processes, requirements engineering among them, as critical to the implementation of successful outsourcing. The underlying assumption is that the process needs to change before we start outsourcing it.

The images and views of management and professional experts on outsourcing goals are closer than they think, however. Outsourcing offers opportunities. Operational fears are justified under the assumption that nothing will change. In practice, outsourcing provides an impulse to this change as formerly hidden costs will become painfully visible to IT professionals and management alike. The importance of requirements engineering, as the key process on the demand-side of outsourcing, is paramount.

We need to find the common ground between organisational levels to enhance our grip on IT-investments. The role of requirements engineering as a common language in the future demand-supply organisation thus becomes a shared interest amongst senior management, middle management and software development professionals. A common goal to get software development to deliver business value and ensure business continuity: let that be your mind-set.

How to achieve cost-increase: Fuzzy requirements + Outsourcing

If uncertain and vague requirements remain the norm after outsourcing system development, that process will become more rather than less expensive. Vague expectations about project targets and business goals limit the added value of outsourcing contracts. When products cannot be pinned down accurately in terms of acceptance criteria and business value, the contractor can only commit to delivering capacity. The business case for outsourcing, however, is often based on output-based contracting. Allowing this discrepancy between outsourcing strategy and its execution limits the organisation’s potential to deliver on the business case for outsourcing. We keep aligning on the fly, but pay our outsource partner heavily to do so.

The practice of outsourcing contracts shows that suppliers often commit themselves to time and budget restrictions despite vague requirements. Experienced suppliers will raise their commercial offers with significant risk allowances, effectively placing the risk with their client. The supplier spends this risk allowance gradually and co-operatively on the alignment of result and expectations. The limits of co-operation coincide with the limits of this extra budget. As this is evaporating, more and more ‘additional insights’ will be marked as changes and enhancements. The demand organisation will ultimately be fully charged for them as contract extras. The supplier appears to be quite within their right as their generosity must have its limits.

Another means to which suppliers resort to mitigate their commercial risk is to service the client with drawing up a functional baseline to clarify mystifying requirements. More often than not, this baseline will prove a dysfunctional marriage between the client’s expectations and the functionality developed so far. Nevertheless it will be signed by all parties to guarantee the project’s progress. The baseline (not the business requirements) then becomes the formal basis for further impact analysis, development and contract issues. Every functional or even non-functional item stumbled upon in the alignment process will be measured and weighed against this document. Any item not found directly in the document will be considered a new – billable – requirement or change. Both the ‘risk mitigation’ and this ‘scoping tactic’ are suppliers’ means to ensure a commercially viable project.

The rework-penalty: in-house versus outsourced

In the outsourcing practices described above, delivering useable functionality still depends on alignment on-the-fly. The main difference is that internal (and often invisible) budget is exchanged for external spending, exposing the cost of inefficiency and failure. Research indicates that the absence of mature requirements processes during in-house development raises the additional cost of rework to 40 % to 50 % of the initial project budget ^{[Capers Jones, 2000]}. Continuing immaturity with regard to requirements in an outsourced development process not only explicates the height of those costs explicit, but also raises them significantly. Governance within the demand organisation simply needs to change.

The external supplier’s profit margins add to this painful insight in the cost of process-immaturity. Extensive rework results in extensive billing. The cost-effectiveness promised by the outsourcing strategy is not fulfilled. Unsatisfactory KPI’s arouse the CFO to spur the organisation into better performance. As a professional requirements engineer you know a way to reach that better performance. Here is your chance to implement a sound process delivering value to the business.

“We won’t have this problem, we’re going Agile!”

Some organisations claiming this will prove to be correct. Using Agile development life cycles such as SCRUM can prevent an outsourcing partnership from experiencing these problems, provided they do it the proper way. That means activities relating to requirements engineering and demand are performed at a very high maturity level. The voice of the customer needs to be heard on a daily basis and the team needs to be willing and able to take ownership.

One of the hardest subjects in software development is communicating and understanding requirements. In a SCRUM-enabled offshore outsourcing environment the development team needs intense communication with (onshore) client representation. The onshore team remains responsible for elicitation, stakeholder negotiation, identification of non-functional requirements and validation with stakeholders. Often the product owner is called upon to perform these tasks. Short feedback loops make Agile work. The onshore team will probably run into some difficulties communicating the requirements to the offshore team during the first sprints. SCRUM demands performance evaluations by the whole team at the end of every sprint and improvements in order to do the next sprint even better. The goal is to deliver value to the business effectively. SCRUM teams often work out their own practices that reduce misunderstanding as early as possible in the sprint preparation. Backlog grooming for instance is a well-used practice within SCRUM that helps clarifying the real needs before the team starts planning and building the software. These activities are simply new forms of requirements development and validation.

If the demand organisation was not used to proper requirements engineering to begin with, outsourcing combined with agile will force them to improve quickly on this topic. The professional agile team simply does not accept vagueness. In case the agile team shows lack of power to reverse the current unacceptable situation, the organisation will suffer effects similar to those described above. Rework will be called ‘extra sprints to enhance functionality’, but the negative financial impact will remain. The problem of the rework-penalty can only be solved through proper implementation of mature requirements engineering practices within Agile development.

Where is the profit in outsourcing?

Until they change the rules of the game demand organisations will never reach their outsourcing goals of cost benefits and added business value. They will even become less competitive in their market. Supply organisations will be confronted with disappointed partners dominated by frustration and dejection. Their partnerships may well end in dispute and losses for all. To benefit from outsourcing, demand and supply need to improve their IT governance and, within IT governance, the integral and highly influential process of requirements engineering.

Well-executed IT governance leads to clear definitions of responsibilities and mutual investment in the intended business results of projects. Clear and separate responsibilities render the more-or-less ad-hoc alignment mentioned above impossible. This is not to be seen as a threat, however, but as a chance and an impulse for improvement and professionalization of development processes.

Classic research such as Boehm’s ^{[Boehm, 1981]} shows that finding and solving misunderstandings on the fly was never an economically sound strategy. Boehm’s conclusion (the cost of fixing or reworking software is much smaller in the earlier phases of the software lifecycle than in the later phases) is universally accepted. Later research on the subject within Dutch software developing organisations and testing departments ^{[Cannegieter, 2007]} shows that the average return-on-investment of requirements review and validation lies between 5 and 7.

Restrictions in time and pressure on progress often prove irresistible, however. Game rules such as ‘first time right’ and ‘always validate requirements’ are discarded in the heat of battle. The avoidable costs that are incurred are invisible to the organisation: they are “off the books”. Since no-one needs to account for them, management remains unaware or hardly interested until they create an overrun in the planned time or budget. The lack of convincing arguments to invest time and effort in reviews and validation leaves professionals with no other option than to accept the situation and move on.

Working with external suppliers forces demand organisations to break with this habit. The avoidable costs are no longer kept off the books since suppliers charge their clients contract extras for changes every time unclear requirements pop up. The costs of inadequate or ineffective requirements processes become visible, instantly providing convincing arguments to turn this tide. The graph shows the effects of outsourcing on visible project costs.

IT-governance provides insight into the financial results of the outsourcing strategy and the effects that the quality of requirements (and procurement) processes have. Analyses of these effects give insight into the additional charges due to inadequate requirements processes, which provide a solid business case for enhancing them. This mechanism, brought on by outsourcing, creates a starting point for professionalization.

Risk management on the application level provides another path towards improvement of requirements engineering. Risk management focusses on the relative importance of applications to business processes and the impact on business continuity should an application malfunction or fail to meet business needs. Inherently, risk management creates insight into the business effects of ineffective system development and procurement processes. Risk management also focusses on business risks posed by insufficient quality of knowledge transfer, support and documentation. While preventing obvious risks such as vendor lock-in, the insights provided by risk management can also be used to further the case for well-defined and validated requirements. After all these define the quality of documentation and provide the basis for acceptance and payment of the final product.

As long as risk assessments show bad results on the availability and quality of requirements, development of that application can only be outsourced with specific risk mitigation measures. One of these is the development of a set of validated requirements for existing applications that are to be outsourced. Another measure is to acknowledge the risk and calculate significant extra budget and time up front to provide a sound business case for outsourcing specific applications.

Finally, risk management considers requirements management within the software development process. Assessing the use of requirements management activities as being a natural part of change management, project processes, test and acceptance will provide insight into the use of requirements as the basis for development and delivery. These assessments take into account the requirements processes of the supplier as well, revealing hidden (but now manageable) business risks that would otherwise pop up after delivery as incidents in the primary process.

Both the financial insights and insights offered by risk management are two impulses for your organisation to take a closer look at the development processes and improve on them. These insights result from the use of outsourcing. Accurate requirements engineering processes offer a perfect means for reducing rework and mitigating risks.

Outsourcing: two sides of the coin

To many organisations bug fixing has become a way of life, a habit blessed with invisibility of the cost of failure. This state of affairs is not recognized as a problem by IT principals or the business since products are being delivered and business continues relatively uneventfully. If this is the actual situation within your organisation, then outsourcing development will most likely lead to reduced quality and higher costs initially. Recognizing the effects mentioned above and using them to your advantage can make outsourcing the driver for the enhancement of requirements processes. These are two sides of the same coin.

If outsourcing is already decided upon, just pick the side of the coin that suits you best. Internal employees have gained knowledge about the systems and the business they support by trial and error. Combining this expertise with the business risks of outsourcing and the risk of higher costs per application, a sound case can be put forward for the improvement of requirements processes. Only those who have a clear understanding of the importance of applications to business continuity can construct and deliver this message. Outsourcing application development or maintenance provides internal requirements professionals with opportunities. The nature of your work will probably change, but outsourcing can provide a pressure cooker for more mature and professional attitudes towards software development and requirements processes.

Conclusion

The message is clear: use outsourcing as a tool for reduction of waste and improving requirements engineering practices within your organisation. Refrain from fighting the decision about outsourcing but take advantage of it. Outsourcing turns hidden avoidable costs into visible, avoidable pain. There you are, dear requirements professionals: Finally! A genuine burning platform for the significant improvements you have always dreamed of! Offered to you on your doorstep by outsourcing! Poor requirements? Welcome outsourcing!

References

• [1] Boehm, B.W., Software Engineering Economics. Prentice-Hall, 1981
• [2] Jones, Capers, Software assessments, benchmarks and best practices. New York: Adison Wesley, Information Technology Series, 2000.
• [3] Cannegieter, H.J.J., QA en testen, in: Software Testen in Nederland, H. van Loenhoud (red.), Academic Service, 2007