Project requirements need to be considered first, not retrofitted later, writes PM Planet columnist George Spafford of Pepperweed Consulting.
A challenge in managing many projects, and certainly IT projects, involves adequately defining business and later, technical, requirements. Without adequately understanding requirements there is a risk that improper decisions will be made.
It is a common scenario for applications to be purchased without first undergoing proper requirements definition only to find out later that they were the wrong choice. Instead of rushing to buy, the business and IT need to work together to understand what is needed and then make the correct decisions.
When groups decide to skip proper planning, including requirements definitions, they are experiencing a “delusion of speed”. In other words, it feels like they are going fast but if decisions are made on incomplete information and additional work and/or purchases are necessary then was there really a savings?
Studies have shown it is far cheaper to factor requirements in up-front. One study found it could be up to five-times cheaper to build requirements in versus trying to retrofit them later. Furthermore, some functionality can not be retrofitted. In other words, there are some requirements that, when overlooked initially, can not be added in later; or certainly not in a cost-effective manner.
Understanding requirements extends beyond development to any form of project. For example, imagine that a project is assembled to assess outsourcing a vital function. If the project team doesn’t make the effort to understand what the function does, what its dependencies are, what groups depend on it, and so on, then the resulting outsourcing could be a disaster.
To counter this, project management groups and their respective organizations need policies and standards in place that require proper project management and requirements definition when certain criteria are identified. These mandates should be identified in the service development lifecycle (SDLC) and the project management methodology as well. The intent is to make sure that requirements definition phase isn’t bypassed.
From a project management perspective, one approach is to insert a review point or “control gate” at the end of requirements definition phase and have the various stakeholders formally sign off that the relevant requirements have been identified and they are satisfied with the work. Only after this approval document is completed can the project then be authorized to proceed.
When collecting requirements, it is important to understand all business requirements. Sometimes a sponsor will only involve his/her department when, in fact, there are multiple dimensions that must be considered that extend beyond the department level. When identifying requirements the following are representative groups that should be consulted:
Security – The requirements should be reviewed to verify that security can support them and also assess if the project is taking security policies and standards into account.
Legal – The legal department should ensure contract terms are appropriate and that any legal obligations of the organization that relate to the system are identified accordingly.
Regulatory Compliance – The requirements need t be checked so that relevant regulations are appropriately considered and included with other business requirements. For example, to validate that protected health information will be sufficiently secured.
Audit – Expected control requirements to manage risk need to be present and also that the application is auditable. Are certain key activities, such as a user signing on to a system logged?
Architecture – Architectural requirements need to be identified. Without architectural standards, an organization risks uncontrolled variation and thus higher costs and other challenges.
In general, if a system will impact other areas of the organization then they should be involved accordingly. The intent is to get needed perspectives and to ensure the system requirements reflect what is needed for the organization as a whole to move towards its goals.
In summary, requirements definition is very important for the selection of a system that meets the needs of the organization. However, for a variety of reasons it is often skipped for the sake of expediency, which is a risky delusion.
Instead, the organization’s policies regarding the purchasing, building or changing of applications should reflect the need for appropriate requirements definition recognizing that it is far more efficient, effective and economical to factor these requirements in at the outset instead of attempting to retrofit them in later. And finally, it is very important to identify and formally involve the relevant stakeholders to ensure that all requirements are known.
George Spafford is a principal consultant with Pepperweed Consulting and a long-time IT professional. He focuses on compliance, security, management and overall process improvement.
IE 7
Firefox 2.0
