Reference no: EM132201582
Read the following and write 2 paragraphs about how "requirements engineering" could address the problem of poor requirements, e.g., as the article notes it is the underlying process that creates poor requirements.
The Requirements Excuse
Studies into the failure of IT projects almost always make reference to poor requirements as a leading source of failure. Requirements are of course a vital part of any project. Without knowing what you’re building how can you build something of value? Although I agree that getting the requirements right is a central pillar of project success, I do have a problem in pinning project failure on poor requirements.
As those who have run IT projects know, establishing requirements can be a tricky business. Users often don’t know exactly what they want, expressing complex ideas can be difficult and balancing the needs and wants of different groups can be a nightmare. These problems are nothing new. The IT industry has been exposed to them since the earliest days of the business. Given that we have been doing IT projects for more than 40 years, it’s time we sat up and started to take ownership of the problems.
Perhaps the thing that stops us accepting those responsibilities is the fact that blaming the users for poor requirements allows IT groups to “externalise” the problem and place the blame for failure on the users. Externalising problems is a part of human nature but it is also a roadblock to genuine improvement. By pointing the finger at someone else we fail to see our own role in the events that unfold around us and that failure is no else’s other than our own.
The other problem with blaming failure on poor requirements is the fact that poor requirements are in themselves a reflection of deeper seated problems. Poor requirements don’t just happen and there can be numerous contributing factors. It could be a failure to engage the right stakeholders, failure to ask the right questions, failure to forge effective working relationships or poor communications skills. By pinning the blame for failure on poor requirements we stop the process of truly understanding where things went wrong. If you can’t see the root cause, you can never fix the root cause and in doing so you doom yourself to make the same mistakes in the future.
Being able to recognise poor requirements and being attuned to the dynamics that can tell you if the technical team and the business representatives are interacting effectively are key skills for those run IT projects. If you lack those skills then you lack the skills needed to run a project effectively. Yes you can blame the users for your own lack of skill, but in doing so you are creating the conditions that will lead to future failures.