The number one improvement to be made on government software projects is to keep the requirement team around that documented the requirements. This provides a number of benefits:
- Saves time
- Saves money
- Provides accountability of requirements
- Improves deliverables
If you work in a non-government business you may wonder at this.
The False Belief
Many government agencies are under a false belief that they need to remove the team that wrote the requirements in order to avoid bias in awarding contracts. One contracted company documents the requirements (The Requirement Company). Another contracted company is awarded the contract (The Development Company). This is done to prevent The Requirement Company from writing the requirements with bias to awarding the contract to a specific company, such as their own.
Avoiding bias in contract awarding can be maintained without removing The Requirement Company who documented the requirements. The benefits to keeping The Requirement Company are many.
It can take a lot of time to document software requirements. There are two groups who spend time on the initial requirements documentation, The Requirement Company and The Business. When The Requirement Company is let go from the project, because the documentation is done, the contract is put out for bid and awarded to The Development Company.
The Development Company, as much as they believe they understand the documentation, will need to obtain validation and clarification on the requirements. Now The Business is again spending time doing what they already took the time to do once, explaining what is needed. This is a waste of time.
It takes time to document requirements and there is an associated cost. However, it is wiser to not spend time doing the same thing twice (Rapid JAD principle – Document Once). The government is now assuming unneeded cost because The Business is explaining the same requirement a second time, this cost is a loss in productivity. This cost is needed when first documenting the requirements, but having to do it a second time is a waste of productivity, thus a waste of money.
Save money by keeping The Requirement Company around who can answer questions posed by The Development Company. This allows The Business to stay productive with their primary focus on the business. This saves time. This saves money.
Provides Accountability of Requirements
Keeping The Requirement Company around means they will be accountable for the requirements. If The Requirement Company is let go from the project, then they are not present to be held accountable for:
- Missing requirements
- Vague requirements
- Poorly documented requirements
I have been on a number of projects where there are questions about the requirements and The Business cannot answer them! They say things such as, “I do not know what this requirement is either.”
The Requirement Company should be made an “active” project development leader. They have the vision for what is needed and should be there leading in development of that vision. The Requirement Company will have a vested interest in seeing The Development Company gets it right. The Requirement Company will be there to discuss, explain, or provide the business justification for any of the requirements. In this way The Requirement Company is accountable for the requirements. This is an “active” project development leader.
I have seen passive project development leaders from The Requirement Company where they are maintained on a project and refuse to answer questions about the requirements! Figuring out the requirements is the job of the Development Company they say. This is an excuse used by The Requirement Company for poorly documented requirements. This is the Requirement Company not wanting to be held accountable for the project requirements.
Keeping The Requirement Company around improves deliverables because they have a vested interested in the success and happiness of The Business. They documented what is needed. They are there actively leading in the development. They want to see a successful software project. A successful project leads to happy customers and future business.
If The Requirement Company is gone and the software is not successful, they can blame The Development Company. They say, “We did our part. The Development Company bid on the project. If it is not correct, it is the fault of The Development Company.” They can say this even if the requirements documentation had missing, vague, and poorly written requirements.
Good business relationships are valued. If The Requirement Company is maintained as an active leader, they need The Business to realize the benefits from the software and associate that success with their company. This will improve the delivered software system.
If you are in a position with a government agency where you are overseeing software development contracts, the number one thing to do that will help with the success of the project is keep The Requirement Company around and playing an active role in leading the software development. This is not in conflict with awarding of development contracts.