Software projects that fail are mostly due to poor communication — failure to determine and communicate the main objectives of the project in quantifiable terms before construction starts.
The CIO magazine reported in a study that more than 50% of IT projects fail.
A Project Management Institute (PMI) survey in 2017 of companies with failed projects, among the top reasons for project failure are the following:
- Inaccurate requirements gathering
- Inadequate vision or goal for the project
- Inadequate/Poor communication
- Poor change management
- Inaccurate cost estimates
- Undefined opportunities and risks
- Inadequate sponsor support
- Inaccurate task time estimate
- Inadequate resource forecasting
All of the above are symptoms of poor communication — starting from the project proponent down to the project execution team.
How many software development projects have we seen that start with unquantifiable requirements yet promise a fixed budget and a target finish
A successful project should have all of the above realized within expectations – we should deliver the requirements, within budget, and on time. It always involves balancing these three:
- Scope – what are the project objectives or business requirements? what do we plan to achieve?
- Cost – project cost and total cost of ownership (TCO)?
- Time – target completion date.
Among these three, the business requirement is the major factor that influences both budget and schedule and yet it is this factor (among the three) that gets the least attention. If we do not define the requirement accurately, we will always miss our budget and our schedule.
Even if we have the best people in our team but if our requirements are not clearly stated before we start construction, our team will be in a state of continuous improvisation – where we refine requirements while the project is already underway. Then what? We will be surprised with “new” things that we sometimes call “changes” that we only realize in the middle of construction or worse during testing. These surprises may require small or big changes. It may require rework or scrapping the design and rebuilding things from scratch. Regardless of the size, these revisions will always delay the project and increase the project cost. We will have a hard time hitting our deadline and controlling our expenses. Maybe we can complete the project after long delays and an exponential increase in cost. Still, it is a project that missed its targets. The problems will also persist during the production life of the system — it will increase the Total Cost of Ownership (TCO) of the system in the long term.
They key then is to improve the accuracy of our business requirements so that we can have a more accurate cost estimate and schedule target.
How To Improve Accuracy of Business Requirements
- Get the project sponsor to define the project charter in quantifiable parameters. Example: “Reduce our turn-around time for loan applications to one hour or less for all applications with complete requirements. This should be live by June 1, 2019.”. Explicitly specify that any feature that does not serve this mission is out of scope. This last statement may sound imposing but it will help your organization maintain focus on the mission. It will reduce scope creep where well-meaning users insert their nice-to-have features and declare them as “very important”.
- Communicate all business requirements in quantifiable terms. Specifications that are quantifiable are verifiable and will not invite any dispute when validation time comes. Any data presented using the characters 0 ~ 9 or logically verifiable will not be misinterpreted. Examples: “Every transaction will be charged a PHP 150 processing fee. This fee should be maintainable by the designated administrator as needed.”, “All system response time should not go beyond 10 seconds.”. These are all quantifiable requirements and since they are known
beforeprogramming starts, it definitely impacts the way we approach construction. You are your client will also have a clear way of measuring what is acceptable or not instead of arguing about it come user acceptance test period. It will save the entire project team valuable time and it will save your company from unexpected expenses.
- Ensure that all team members have access to project documents within seconds of need. This requires a digitized and searchable project repository. Create an inventory of all business requirements in a searchable repository ensuring every requirement can be traced to a specific implementation — like a section of a code or test scripts or test results. This is so it will be easy for all stakeholders to be specific when referring to a business requirement. This can be done using a feature tracking tool like Trello, Redmine, JIRA, or other suitable tools. This same inventory database of features will be used to document test results when the time comes to validate the system. This same database will be used to enhance the system during its entire production life.
Situational Examples on How To Arrive At Quantifiable Requirements
Let’s say you are gathering requirements and your client tells you: “Make sure the system has a fast response time.” What are you going to say? “Of course, we have experienced engineers who know how to optimize applications. Nothing to worry about.” Your client nods, confident in your promise. Are we done? Not so fast. Does the client mean fast in relation to their current system that gives results after an hour? Or do they mean fast like Google search that gives sub-second response time for search results? There is a million-dollar cost difference between the two. We need to ask the client some specific questions. Example questions:
1) How many users do you expect to be using the system at any given time? Example of a precise answer: 150 concurrent users maximum.
2) How many seconds is the response time for you to consider it fast? Example of a quantifiable answer: Under 1 second.
3) Do all your users have access to internet with at least 10mbps speed?
4) Are you willing to spend 1 Million pesos a month to achieve that speed requirement? This invites a specific Yes/No answer. If the answer is ‘Yes’, we proceed. If the answer is ‘No’, we go back to #2 and compromise on the speed vs cost. For example, we can say — “We can give you 10 second response time for a system server that is not going to be more than PHP 100k per month operating expense”.
The answers to these sample questions are quantifiable. We should always drill down to
Impact of Clear Requirements During Client Testing Phase
Very often, inaccurate business requirements show their ugly head after construction and during testing. When the time comes that the business owners validate the work, any misunderstanding with the requirement will start to manifest around this period, leading to rework, more testing and many more cycles of testing and rework, leading to project delay and budget overruns. If we do not spend enough time to come up with clearly defined business requirements before we start construction, it will surely translate to much higher expenses later on in the project.
Let’s revisit our example on response time above. If we did not drill down to numbers, the word “fast” will fail in the eyes of the load tester if they test it against 1000 concurrent users. “Fast” will fail in the eyes of an end-user tester that expects it to give a response in under 1 second. You will not have your sign-off document because the specific parameter for passing the criteria is not written down.
If we have accurate requirements well documented – they’re like the height of the bar set for a high jumper. The jumper, the judge, the audience are all aware of what needs to be passed. You either clear it or you don’t.
Given a clear objective, the project team members will have a clear understanding of what needs to be done. Of course, the skills of the project team matters during project execution time but there is nothing an exceptional team can do if they have a vague idea of what to do. We can hire an elite construction team but it will only matter when they have a clear mission.
Validating Project Completion
When the time comes that client representatives test the system to determine whether the system satisfies the business objective, a clearly defined fail or pass parameters for every use case before construction even starts is critical so that the project team
It’s common to have a quality assurance team within a software project team, but there are practices that need to be changed when involving QA people. The common way software development is done is to perform the quality assurance activity after the product is ready for testing. That is a natural progression, but the problem with involving QA only later in the project phases means they are only there to do quality control (not quality assurance) — which is a reactive activity that measures unclear requirements. The effect will be a test phase full of misunderstanding between the project team and the client simply because the parameters for passing or failing it are not clearly articulated during the planning phase. The key change is to involve QA from the very start – while the requirements are being defined before construction even starts. This way, the QA team can validate the expectations early and can also start building their test cases early.
Yes, gathering precise requirements is hard work but there are many benefits to this early hard work — we come up with more accurate business requirements which translates to a more accurate cost estimate and a more precise completion date. Let’s move the hard work very early in the project planning phase, during requirements gathering, before construction, so that we have a much clearer view of the risks we face. Knowing the risks early allows the project team to make adjustments early in the project phase.
Our project will have a much higher chance of completing
When this is practiced, the Total Cost of Ownership for the business organization is reduced contributing to lower cost of operations and better profitability for the business.
Author: Galileo Valiente
The author has 25+ years of experience working with custom enterprise application development in multinational corporations. With hands-on experience as a software developer and a certified project manager.