How requirements analysis gets derailed (and how to stay on track)

Posted by Tim Mead | September 05, 2007 11:51

Invariably, I find it most practical to only engage in political and / or social issues when you come across them. Although it can never hurt to have a thumbnail of how a firm works - not to mention a good understanding of its culture - your best defense against 'people-based' errors does not come from laborious analysis of stakeholders' influences, but rather from having a thorough process, while being mindful of the need for flexibility. To be effective, you should be able to draw from a library of techniques to find an overall analysis approach that works for your client firm's culture.

As you progress through requirements analysis, it is easy to become accepting of bias and misdirection, or worse: to simply not to notice them.

If you want your project to be a success, it's important to be vigilant during the inception phase and during every requirements cycle. You must constantly be taking a moments aside to assess your position; to ensure your project isn't about to hit a serious obstruction to timeliness or quality of delivery.

Some of the best indicators that you are about to face a serious obstacle in requirements analysis are:

1. You have sought to gather requirements from a logical source, but have been dissuaded from or even refused feedback.
2. Your logical, concise and relevant analysis is being interpreted in a negative way (eg: perhaps as pedantic or time-wasting)
3. Your requirements came from a press release or marketing advertisement already in public circulation.
4. Your requirements have come from a single source.
5. Your requirements aren't made available to all stakeholders.
6. Verbal requirements are made which are never agreed to in writing (whether the writing is formal or informal)
7. Your immediate superior is directing requirements or development against either the wishes of their superior, company policy or their client.

Each of these indicators reveal potential issues. Even if only one of these issues isn't promptly addressed, it could easily become a major headache in the future, or even cause the project to fail!

Let's briefly look at the best approach for the analyst to take for each situation revealed by the indicators.

1.

If you have sought to gather requirements from a logical source, remember to have justification for your selected source at the ready.

Common excuses you might be given for disallowing you access to valid sources are:

• claims that your attention will make the source believe they control the project
• the source is either biased or incompetent
• the source isn't relevant or representative of all clients
• the person discouraging or refusing access claims to have "the real requirements"

If you can't convince your client / manager that it's in their best interests to include your source, ensure you record their decision to exclude the source and remember to cite the reason for it. Obviously diplomacy is involved in making such documentation visible to stakeholders. As always, decision-making records should be informative, descriptive, yet not have and accusatory tone. It's a matter of discretion how hard you push on any given point regarding how poor the decision being made might be. If you are reasonably certain of them, you should make the potential consequences clear and record them also, but remain receptive to the idea that there could be good reason for the decision, and that ultimately, unless you are a decision maker, your role as an analyst is to consult and give your analysis, not to robotically adhere to your own ideas of process.

2.

If your analysis is logical and reasonable, yet you are being given the impression that you are impeding productivity, it might be because your client doesn't fully appreciate the reason for your line of investigation. If this is not the case, you can expect an up-hill battle doing your job and you should carefully consider your position. If, however, a lack of understanding of your analysis is the cause of your client's seeming dissatisfaction with progress, you can manage this by:

• ensuring all your current analytical concerns are expressible at a moment's notice in simple point form
• keeping question and answer information organized with motivations for the questions
• always maintaining a link between requirements and feasibility - wherever possible, use real cost analysis and or revenue information
• be able to indicate how any given line of investigation links directly to the success or failure of the project: be able to quickly and easily inform your client of exactly what can go wrong if your analysis isn't performed

3.

Learning about your requirements from a press release sound diabolical, yet need not be quite as nasty as it sounds. If you have learnt about a requirement in this way, it can simply be a sign of confidence the firm has in its direction and assessment of the market. In fact, in a way this can be a disclaimer for an analyst: your analysis obviously hasn't contributed to this decision that has already been made, and thus you can still assess feasibility with the disclaimer that you weren't responsible for an analysis that lead to the deadline. However, the feasibility study of the newly discovered requirements then becomes a priority. The potential for project deadline slippage depends on the reasonability of the requirements; both in analysis time and in production time. If the deadline for the marketed feature is deemed to be critical and inflexbile, it is important to ensure that assessments of time for analysis are reasonable and that development schedules are also feasible. Project management and developers will no doubt bare the brunt of delivery estimation, but a thoughtful requirements analyst should seek to estimate new requirements discovered in this way as a matter of priority. Most importantly, you should ascertain the importance of the advertised features to your project's success. By comparing the importance of the features with the time and resources allocated, you can quickly determine the risk of the project. Even if the assessment is reasonable, you have been given a good insight into how careful or responsible your client is. My advise is to never encourage this behaviour, and if at all possible, to discourage it. In some cases it is confidence, but all too often I believe it is foolhardiness or naievty. A commitment to the public (or even a single client) should never be taken lightly, nor made without feasibility assessments. There is usually not a compelling or even vaguely plausible argument for circumventing a quick risk analysis with appropriate staff.

4.

This is similar to the first point, but more extreme: if your requirements came from a single source with no corroboration, you're probably already getting that sinking feeling. Unless you truly have one stakeholder (or one stakeholder group) your source for requirements should not be singular. No matter how informal the consultation, you should always seek diversity in analysis, even if your client or boss demands that you subsequently ignore all other input. Without confrontation, always ask why your sources of input are being limited. In some cases, a product you're working on might indeed be the idea of one person or small group. It might be the case that it is their sole invention and responsibility. But if you are responsible for any product requirements analysis that is done without appropriate stakeholder consultation, people will want to know why. Unless it is on record that you were freed of your obligation to consult all appropriate stakeholders by your client / supervisor, it will be seen as your failing should any concerned party complain that they didn't get their say.

5.

If you have documents that descibe your project requirements clearly and accurately, you've done your job, right? What if all concerned parties can't see these document though? If your requirements information isn't available to each appropriate stakeholder to the degree they are concerned, how can you know if your proposal will lead to an effective outcome? If you are being asked to keep parties in the dark or you aren't allowed to publish information on your analysis, you can be sure that it's to support one party's bias and let them dominate the project. Should this party be your employer, you have the choice to either risk your position by highlighting the bias to all parties, or simply tolerate the attitude and communicate the bare minimum to "lower priority" stakeholders, as per your directions. Should your contract dictate satisfactory disclosure to all parties of discovered requirements, you must ensure that this is performed, however. If you make your requirements available but don't advertise them, you can often (sadly) rely your supervisor's dominant interpretation remain unchallenged by other apathetic stakeholders. Whatever your ethical / diplomatic approach to this ugly affair, you should always protect yourself against the danger of rework. Should you (or rather your boss) be caught out at the last moment for biased analysis, you may be responsible for costly rework. Should this be under contract, the result might be disastrous to your margin. If you are in a full-time position, it may only be your sanity at stake. But as much as possible, convince all parties to be involved, and to settle their differences as part of the analysis process. If you are forced into the ugliness of sneaking through somebody's private agenda, you need to ask yourself if you want to risk being party to analysis "ping-pong", and if you answer yes, be sure you can afford it.

6.

Verbal requirements are often what you will get from stakeholders. There's a certain secretarily expectation on requirements and business analysts. Be sure to document verbal requirements and to provide them to the source ASAP. If there's a disagreement, it should be discovered quickly. Don't let a forgotten or misinterpreted verbal requirement balloon into a fully blown stuff-up. If you send around disclaimers and blame notes in the aftermath, you will get nowhere in analysis, you will lose peoples trust and confidence, and will no longer be effective. If you accurately summarise then provide a timely written 'echo' of people's verbal decisions and requirements, you will be seen as an invaluable and effective facilitator of project development, as no doubt you will be.

7.

Probably the ugliest and most ominous of the warning signs to landing 'in the poo' is being asked to do what your boss wants in spite of what his or her boss wants. In short, you're faced with taking a sides or pleading ignorance to either a superior or a client about decisions your immediate superior has made to ignore or defy their wishes. In these situations, it's entirely possible that your boss will explicitly ask that the contentious decision or interpretation of requirements be left out of documentation so it won't be read and contested. The worst case scenario is that you haven't been in the habit of ensuring your work is visible upstream at all, and your immediate boss decides that you should be doing more than what satisfies your boss's boss. In this case, failure to deliver results means relying on your boss's integrity to cop to their poor decision making if the budget is blown.

In short, you can't expect to solve a company's internal problems unless you're in a position to do so, and finding yourself in this situation is nasty, even for an analyst well respected by both parties. In my opinion is is imperative that you convince your boss to negotiate the disagreement openly. In any case, this is just another reason why you should always insist on recording all requirements decisions, and always communicate them to all appropriate stakeholders.

As a requirements analyst you need to be a diplomat just as often as a technically minded, business savvy consultant. Bear in mind that you should only be as invested in your advice as you can be affected by outcomes, and that minimising your reliance on outcomes other than your accurate analysis is the best way for you to be objective and do the job that is of most benefit to both you and your client. Negotiating any one of these scenarios might be on the cards if you're in the requirements game, but if you find yourself faced with all of these problems in rapid succession, you should carefully consider if the opportunity that you're pursuing is worth the grief.

A final word for the analyst programmer: if you are responsible for the analysis and the development of a project, you have doubled your investment, and thereby increased your liability to make biased or stress induced decisions. Try to mentally balance out your gut reactions that you will most likely have as a programmer to sudden change, and use process and analytical skill to shield you from feature creep and the creation of maintenance pigs, meaning: don't forget to agressively pursue the reduction of project scope after initial project elaboration is complete, and always ensure that new requirements are (wherever possible) introduced iteratively, but not at the cost of core client features and salability / usablity. Wherever possible, avoid falling into the traps above, and always watch out for the brown blobs when you're working across the developing lawn.

Comments

There are no comments on this article.

Disclaimer: These articles represent the opinions of the authors and may not match the official position of Ubik Systems Pty. Ltd. Confirmation should be sought on all matters involving professional advice.