|
The Chaos Report is a frequently referenced study that provides statistics on IT implementation failures and successes. You likely don’t need another industry statistic to understand poorly defined requirements result in poor project outcomes. While developing a lecture on requirements management, I found a few examples of project failure. The following categories are not a definitive list, but represent a high-level categorization of sources for requirement management failures.
Poorly Defined Requirements We’ve all heard the phrase “Garbage in, garbage out.” A few years ago, a system implementation project suffered from poorly defined requirements and resulted in a failed project. The business customers thought they were providing good requirements for system development but ended up with garbage and fodder for this story.
The original scope of the project was to develop a simulation tool for a Microsoft Access database application. The business customers wanted to train people using the Web instead of relying on local copies of the Access application. The vendor followed the high-level requirements and developed a Web-based application that resembled the 30+ Access screens. The business customer quickly noticed none of the behind-the-scenes calculations worked and the data didn’t flow between different modules.
The vendor delivered according to the RFP requirements to “translate the enclosed MS-Access database into a Web-based training simulation”. However, since the requirements were not adequately defined, the vendor thought the customer only wanted the data input replicated. They didn’t expect to include any business logic in the solution. After further analysis, the vendor determined the business customer wanted the Access application to be a fully functioning Web-based application.
Since the project was fixed price, the vendor experienced significant cost overruns and requested additional funding to continue with the project. Since the project lacked any requirement management processes and limited project management, it was cancelled. Both parties claimed to work off a common set of business requirements, but since they were poorly defined the result was project failure.
Poorly Communicated and Interpreted Requirements
In our world of globalization and offshore development, language barriers need to be understood and overcome during the requirement development process. Poorly interpreted requirements can result in a poor solution. During a previous financials reporting project, the business requirements included developing reports with a space between the currency symbol and the financial value. The business customer intended for the reports to use the format:
$ 100,000.00
However, the development team interpreted “develop reports with a space between the currency symbol and financial value” as:
$SPACE100,000.00
The requirements were correctly defined; however, the interpretation caused the defect. If the original requirements were provided a sample format, the communication error could have been avoided. The “world may be flat,” but communication interpretation errors can still occur despite the global access to talent and services.
Another example in communication failure wasn’t in the encoding or decoding of the message but in the transmission of the requirement. On one project, the client wanted the company logo included on every report. The client didn’t have an electronic graphic file and simply faxed a current report with the company logo. The offshore vendor scanned the logo from the fax into a graphic format and embedded on the report.
During user acceptance testing, every report displayed the company’s logo, but the logo was skewed 30 degrees. When the client faxed the logo, the fax machine distorted the image slightly. Fortunately, user acceptance testing identified the error; however, the vendor insisted they met the requirement.
Poor or Missing Non-Functional Requirements
Sometimes the requirement management failures don’t stem from poor definition or communication. Sometimes the requirements are not defined at all! Team members spend a considerable amount of time determining the functional requirements and teams can forget about non-functional requirements. In IT, functional requirements specify the functions a system should perform. Non-functional requirements describe the operation of a system rather than specific functions. The following non-functional requirement categories provide examples and sample questions for consideration during requirements development.
Hardware and Software
In the fore mentioned training project example, the project team didn’t provide any non-functional requirements for the actual software and hardware environment. The vendor assumed they could develop the solution on a Microsoft .NET platform and when they went to install the first release at the client’s site, they quickly realized the hosting environment only supported a J2EE platform. During a previous financial system implementation, the client expected the underlying database used open database standards. The software product did not use an open standard and required integration via an API library. Since the project didn’t specify these requirements during the RFP process, they had to change their project approach during implementation.
Usability Requirements
Project teams need to identify usability requirements for a solution. Depending on the functional requirements, the system’s response time may be impacted. A 30-second response time may or not be acceptable for business users depending on the expectations. On the training simulation project, the end user expected the Web-based simulation would appear the same as the PC-based MS-Access application. The Web simulation was developed using standard HTML and the final solution functioned differently then the PC-based solution. End users expected they could click off a field and it would save the data to the database. They did not expect to click the “Save” button to commit the data changes.
Legal Requirements
As project teams develop requirements, they need to consider legal requirements for data privacy, data retention and data access policies. If the solution is being developed for a global user base, different countries have safe harbor requirements for personal data that need to be considered.
Internationalization
Large enterprise applications typically focus on multi-national countries and languages. Teams need to define the language requirements for the solution and consider the impacts to small and large markets across the globe. During a previous company intranet portal implementation, the project team defined four common languages for displaying content. However, the smaller countries did not develop content in the approved languages and additional functionality changes were required.
Network Requirements
Network requirements need to be considered in the design and architecture of the solution. As manufacturing facilities migrate to centralized hosting solutions, network bandwidth, connectivity and response time need to be considered. Plant environments tend to operate autonomously of the central staff organization. However, different corporate applications can be shared among the plants, but the network requirements need to be evaluated.
Security
Application requirements need to consider security standards and approved security models. Project teams can assume the vendor’s security model is acceptable since it is an off-the-shelf package; however, implementation problems occur when the company requires a centralized security model. As organizations adopt Web-based solutions, leveraging a common employee authentication process is an emerging requirement.
Requirement Management Fixes
The solution to preventing requirement management failures isn’t a groundbreaking solution. Often, the simplest solution is found in the fundamentals. The following steps will help ensure requirements are properly reviewed, controlled and managed through out the project lifecycle. 1. Conduct a requirements review for functional and non-functional requirements prior to detailed design and construction. Organizations often suffer from analysis paralysis due to the waterfall cycle of software development. If you don’t like the waterfall approach, use an iterative methodology. Requirements can be identified, refined, reviewed and approved in iterations. As the project progresses, business requirements evolve and need to be reviewed with the business customers, technical architecture teams, IT operations and security teams. 2. Baseline the business requirements. Project managers establish a schedule baseline to mark the original cost and schedule to deliver the agreed scope. Business requirements also need to be baselined to formally recognize the agreed scope in the project. Project teams can use a software packages for requirements management, or they can adopt a simpler approach by printing the requirements documentation and storing it in the project control book. 3. Apply Change Control to Requirements. Changes to a project’s scope, resources and timeline require a change request. These change requests need to be assessed to determine if new business requirements are created or if there is an impact to an existing business requirement. Requirement management software programs like Borland’s Caliber RM support changes to an original set of requirements. 4. Track Requirements Volatility. Project managers like objective metrics to help measure what they are trying to manage. Schedule variance, cost variance and deliverable counts are some objective metrics found in projects. Requirements volatility is another metric that can be reported on a periodic basis based on the number of new requirements or changing requirements. This process requires the business analyst or requirements manager to actively track requirement changes. By reviewing the volatility, the project manager and business analysts are able to assess if the project schedule still supports the evolving requirements. 5. Trace and Test Requirements. A fundamental technique in requirements management is traceability. A business requirement needs to be tracked as it is identified, recorded, developed and tested in a system implementation. A business requirement is typically translated into a use case or a functional description. These functional descriptions and use case definitions can be mapped to the original business requirement and mapped to the actual technical design specification and code package used to support the business requirement.
Finally, the code package can be mapped to specific unit and user acceptance test cases. By creating a requirements traceability matrix, the project manager can ensure all the business requirements are traced along the system development project and the team can quickly identify the code packages and test cases that support the business requirements. Business customers can review the results of user acceptance testing and map the business requirement to the specific test case.
Requirements management failures can happen to any organization. Requirements can be omitted, poorly defined, poorly managed, poorly communicated and misinterpreted. The previous examples are just a few highlights of where projects fail to adequately manage the translation of business requirements into IT solutions. By following the requirement management fixes, teams can apply these few tactical steps to help improve their team’s requirements management processes.
|
