How we manage risks in software development

Every software development engagement comes embedded with inherent risks of people, processes or technologies. Each risk mitigation needs to have a very different approach.

We believe that it is important those be identified and proper planning done for mitigating the same. In our experience, the following are the risks that we have typically identified in most projects:

People Risks

Human capital risks

Human capital related issues (illnesses, unplanned time off, emergencies, attrition etc)
We actively participate in cross training within our employees.
We always ensure that there are no less than two (2) team members working on a specific aspect of the engagement.

Process Risks

Development process risks

Sometimes we find that our client cannot follow waterfall or agile/scrum methodologies due to various reasons.
We have mitigated the risks by switching to the project methodology that the client is more comfortable with

We are well prepared to address potential risks in this project. We have done so with every Customer by setting an appropriate communication channel and frequency in place. Ultimately, we actively strive to have a higher bus factor and remove any single points of failure.

Technology Risks

Technology risks we handle

Changing requirements
Changing UI/UX guidelines
3rd party API integration
Hardware related issues (failures) during development cycles
Operating system related issues (system upgrade incompatibility)
Software related issues (unplanned outages of software used for development)
Facilities related issues (e.g., no phones, network wiring, furniture, office supplies, etc.)
Over the years, we have gathered enough experience in various software, IaaS, PaaS, SaaS tools and if we find that one tool/technology component is not the best fit for a specific engagement or client (for whatever reason), we have the knowhow of making alternate recommendations/arrangements.

Our Assumptions And Your Responsibilities

Our assumptions and your responsibilities

  • You assign a Project Manager as the single point of contact for issue resolution, activity scheduling, information collection and dissemination.
  • You assign a Product Owner as an owner the Product Backlog and any related issues
  • Your project manager must have the authority to make project decisions and represent your team in all matters related to the project. Your project manager will provide a single consolidated response to any review, approval, change, or decision request.
  • Your staff will actively participate in this engagement, and individuals with relevant domain, business, and/or technical expertise will be available as required. These participants are the acknowledged spokespersons for the areas they represent, and our project team requires regular and timely access to them. If participants are unable to attend a scheduled meeting, then your project manager becomes the final authority on all items of discussion.
  • You provide us at least one technical contact with system administration responsibilities (it helps to resolve system admin issues that we may face when we work on your in-house systems). This person should have appropriate levels of access privileges to systems and information necessary to perform this service.
  • You are responsible for, and assume any risk associated with any problems resulting from the content, completeness, accuracy and consistency of any data, materials and information supplied by you.
  • You ensure timely review of and comment on all deliverables provided by us – it helps us to keep the ball rolling
  • After we release the deliverables on each sprint, please accept/reject the same with appropriate comments.
  • Ensure that all testing is done within five (5) days of our releasing the software to you (each sprint)
  • Any change to the scope of work explicitly described in our engagement and any associated additional fees, must be mutually agreed in writing.

Warranties

Software development warranties

We provide a thirty day warranty from final delivery of the product. Of course, we will make commercially reasonable efforts to resolve any critical, high or medium severity defects identified by you in our project deliverables. The good thing about delivering in short sprints is that we (collectively) would uncover and remediate most bugs/defects before delivering the final product. If changes were made to the deliverables outside the warranty work, we hope you understand that it is your responsibility to demonstrate that the defect is present in the original deliverables before the defect will be considered under warranty.

Change Control

Change control and management

We recognize that there will be change to scope throughout this project. It’s bound to happen as product development is about constant feedback and incorporating that feedback into your product for higher chances of user acceptance. We realize that and we take a very easy route of accommodating changes. Let’s say that we have estimated that during a sprint, a certain product requirement or user story would take 3 days to finish. Once we discuss the change you request – we simply estimate how long such a change would take. For discussions sake, let’s assume that your new requirement would take us 3 days to finish. We discuss with you and you can choose to exchange the new requirement with the other requirement that would take a similar amount of time. Smaller changes that don’t really affect our development estimates by more than a few hours can easily be accommodated.

Please do understand that any changes, which impact user stories or product requirements that have already been delivered, will usually require additional rework and will be considered as new requirements/user stories.