Write the Right Requirements

Last week, the Department of Veterans Affairs terminated its $36 million cloud computing contract with Hewlett-Packard Enterprise Services. The five-year agreement, which was set in November of 2012, would have migrated 600,000 VA employees to Microsoft cloud email and calendar services.

A spokesperson for the agency stated, “VA has decided to terminate the cloud email contract for the convenience of the government,” citing a material change in the agency’s requirements. The cancelation did not arise out through any fault of the contract, but because the agency decided to make a change in its requirements.

What can we learn from this?

While it is unclear exactly why the VA decided to pull the plug, there are a few lessons learned that apply to other agencies and departments. In particular, reading about the VA’s decision reminded me of a few experiences I had as a requirements analyst working on military IT.

Previous project managers have told me that the most important thing about project management is planning. The initial stages in making sense of new mandates, determining needs, defining goals, outlining use cases, and drafting functional requirements are essential to building a solid foundation for progressing through further project milestones.

Changes in requirements often cost a great deal of money. In addition to paying the costs for services already performed, the VA may also have to pay a hefty termination settlement.

Changes in requirements are also frustrating. While I enjoyed the detailed work and reward of requirements analysis, I did not enjoy the occasional disagreements and misinterpretations over requirements verbiage. Changes in requirements are costly on all fronts because stakeholders must then spend time and effort into redefining them, and developers must then have to submit a new level of effort for the changed work.

Define a Solid Requirements Base

Government creates and deals with a great deal of documentation. When utilized and formulated for a purpose, some documents can be constructive tools to drive project planning and define solid requirements.

• Use Case – Tells a story of how users will interact with and use the proposed system to achieve the end goal.
• CONOPS – A concept of operations is a document that describes a proposed system from the perspective of the end user. It includes qualitative and quantitative system characteristics.
• Thorough Cost-Savings Examination – If the aim of a project is to save costs, that calculation should be made as accurately as possible in advance. While cost forecasts are indeed estimates, it should be clear that the project will save the agency money over time.

Build in Room for Adjustment

As projects progress, iterations of requirements may change as prototypes are developed and stakeholders gain a clearer picture of the solution, making modifications along the way. Project leaders need to acknowledge that adjustments may occur and build in back-up plans and ways to accommodate. Tips to facilitate changes include:

• Clear change request process – Implement and communicate a clearly defined process for receiving, examining and integrating change requests to all stakeholders.
• Set deadlines when changes are no longer be accepted.

The project cancellations due to requirements issues point to the importance of establishing a strong foundation in planning. Agencies can begin by ensuring that they have rock-solid use cases and 100% backing by stakeholders. Much easier said than done, but striving towards certainty and consensus can prevent costly changes in requirements later down the road.