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 fund transfer to external entities will be charged a PHP 150 processing fee. This fee should be maintainable by Finance Department in the future “, “All system response time for System XYZ should not go beyond 1 second.” These are all quantifiable requirements and since they are known
before programming 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
Action Items to Improve Software Implementation Success Rates
- Implement Behavior Driven Development (BDD). BDD is a way of defining quantifiable business requirements that are automatically testable during the entire life of the program, from construction to testing to production — automatically. It even functions as living documentation to ensure ease of maintenance, enhancement, and overall communication within the organization. BDD is a way to bridge the communication gap between business and software developers. The medium of communication used in BDD is plain English which is understood both by humans and computers.
- Implement Test-Driven Development (TDD). TDD is a complement to BDD. BDD is used to define and validate the business functionality, while TDD is a tool used by software engineers to define and validate individual components of the software. Practicing TDD within our software engineering teams helps us improve the overall quality of the software by automating the testing process and isolating which components are not working. TDD is machine executed upon trigger or scheduled and repeatable.
- Implement Software Build Automation such as Continuous Integration (CI). Continuous Integration allows your team to automatically collate and package all the components necessary to build a software system. It removes the manual configuration done each time we move/deploy software from development machine then to staging, then to production eventually. CI reduces the errors that frequently occur when deploying software, instead of manual configuration, everything in the pipeline of software development is automated.
- Document Software Engineering Artifacts in order to ensure sustainability and scalability of the system being built. You can forget about this if you don’t plan to use a system very long. But if you intend to use a software to sustain your business, you must ensure there is sufficient documentation for your internal team in order for them to be fully aware of the environment that they’re operating on. What is sufficient documentation? Think about this scenario – what if your “rock star” engineer leaves your organization, will the replacement be able to understand the system quickly in order to support your business? Or will he/she be forced to read the source code? Documentation is not for the end-user, it’s for the sake of business sustainability and better working environment for your staff.
- Ensure Code Quality by enforcing code and documentation reviews in order to check quality of work. Non-compliant findings must be corrected. Unclear documents must be improved continuously. Code reviews must always be done prior to including code to the system build. There are entire books that help ensure code quality such as “Code Complete” by McConnel, “Extreme Programming” by Kent Beck, “The Pragmatic Programmer” by Thomas and Hunt.
- Build a software engineering team that can really work together as a team. This is more of a soft-skill that needs leadership skills and it’s far beyond the scope of this post to assume it can be covered completely here. But for a start – start with eliminating psychological barriers to communication. Make it safe for any member of the team regardless of title/rank to ask questions, share ideas without fear of ridicule or reprimand. Every person has some idea to share and collectively, the business can benefit from having a team who can freely exchange ideas. Do not make them compete with each other. There are many negative behaviors that show up when people are made to “climb ladders”, promotions, bonuses, even recognitions because individual benefits may make them look at others as “competitors.” Instead make them collectively belong to a cause where their cooperation is more valued than competing with each other. You’ll find that the more senior people will be willing to mentor, to help the newbies in your team.
When these are implemented, the organization will benefit though quality, sustainable, and scalable software ownership for the long term.
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.
