Software products are conspicuously present in every walk of our life. Right from setting an alarm to using Google Maps to reach our destination, software has become the soul and face of mankind. Very often, we see bigwig companies anchoring software products with effortless ease. Uber came up with a cracker of an app to ensure that commuters do not face any visible signs of disenchantment. When Amazon understood the intricacies involved in brick and mortar business, it came up with Amazon.com, the reputed B2C eCommerce marketplace. Today, technocrats and honchos such as Mark Zuckerberg and Elon Musk are engaged in a battle of words as far as their opinions on Artificial Intelligence are concerned. It takes a genius to identify the gaps and voids, and indisputably, technology revolutionizes solutions which aim to bridge the gaps and voids. That being said, one must pay attention to the following 50 things before building a software product:
-
Software Sustainability:
At the very outset, think of building a sustainable software. Building a software which lasts only for a few months or a couple of years is of not much use. Building a software from scratch is not only time consuming but only expensive. It is in the best interest of you and your firm that you build sustainable software for getting spirited returns.
-
Identify Your Stakeholders:
Software product development is not simply about a bunch of guys whacking their heads with laptops and gadgets. Programmers and coders are just a part of a conspicuous umbrella called ‘Stakeholders’. Stakeholders are those people who have a say in your software product. In any software project, you can bank on the following stakeholders:
- Business Analysts
- Business Architects
- Business Developers
- Infrastructure
- UI and UX designers
- Quality Analysts
- Testers
- Production / Server Maintenance team
- Clients
If there are any other stakeholders, identify them well in advance.
-
Establish Expectations:
If you are thinking of some unrealistic expectations such as becoming the next Tesla Motors within the next few weeks, you are undoubtedly living in denial. Unrealistic expectations will bring you, your team and your stakeholders under the weather. Clients often set unrealistic expectations. For instance, a prospective client may give you a deadline of 4 weeks for product development. You are very well aware that you require at-least 4 months.
-
Foster Project Ownership:
The classical debate: Project Ownership vs Functional ownership seldom loses its sheen. Project managers are expected to understand and meet shareholders expectations. Functional ownership is all about understanding, building and configuring the software product without paying any attention to the concerns of business analysts, infrastructure team and UI / UX designers. Project managers are expected to essay the role of responsible evangelists who treat every concern of each and every stakeholder with utmost assiduity.
-
Build Trust:
Every odd day, we see tech honchos and subordinates engaged in spats. Spats escalate and result in incendiary altercations. According to a study by Neilson, nearly 77% of disputes can be attributed to lack of trust. Transparency builds trust. If you are transparent and open in your policies and work ethics, employees join your bandwagon with joust. Remember, trust takes years to build, seconds to break and forever to repair.
-
Motivate Employees:
As a software project manager, it is your responsibility to upkeep and preserves the motivation of employees. More often than not, employees get de-motivated due to the magnitude of the code involved. Sometimes, the sheer enormity of proposed functional modules can spell doom on their motivation levels. To keep them motivated, conduct short meetings every alternate day. Discuss the project progress and document everything.
-
Work in Groups:
Segment the work into various fragments. Divide your workforce into multiple small groups. To each and every small group, assign a fragment / functional module. This fosters a healthy competition amongst the groups. Look for KRAs (Key Result Areas). Set targets and benchmark the performance of groups.
-
Identify the Type of Software:
What is the type of software you intend to build? Is it an operational service? Does it have a pilot? What is your concept of robustness? Do you want to build a proof-of-concept demonstrator? It is important that you have answers to all these questions.
-
Identify the Market:
Before building your software product, identify if there is any market for it. Find answers to the following questions:
- Who are my target audiences?
- What are the market trends?
- What is my target customer buyer persona?
- Do I know the buyer demographics?
-
Acquaint Yourself with Requirements Elicitation Techniques:
It is absolutely edifying to understand all the possible requirements elicitation techniques. Right from conducting various types of interviews such as structured and unstructured interviews, oral and written, group and one-one interviews, other techniques such as surveys, questionnaires, task analysis, domain analysis, brainstorming etc., should be leveraged. For your information, structured interviews are also called closed interviews as every question is pre-decided. In case of unstructured interviews, one question leads to another question. Questions aren’t pre-decided.
-
Get a Blueprint of Your Software Requirements:
Identify your software requirements. Take into consideration the various interfaces, functions, modules and security labels. If you are building a software product for your client, get all your requirements sorted out. In technical parlance, you are required to build an SRS (Software Requirements Specification) document.
-
Categorize Your Requirements:
Technically speaking, classify your software requirements into two categories: Functional and Non-functional. Functional requirements are those requirements which are relevant to the functionality of the software. Examples of functional requirements include administrative functions, compatibility of the product with various devices etc. On the other hand, non-functional requirements include implicit and explicit characteristics expected of the software. Examples of non-functional requirements are interoperability, security, flexibility, recoverability from disasters etc.
-
Emphasize on User Interface Requirements:
User Interface defines and dictates user acceptability levels. User Interface is necessary for every software product. Following considerations fall under the broad umbrella of user interface requirements:
- Content Presentation
- Navigation
- Responsive Layout
- Default Settings
- Feedback Mechanism
This list is by no-means exhaustive. Research a lot more on user interface requirements. Prepare a comprehensive list.
-
Validate Your Requirements:
Knowingly or unknowingly, consciously or unconsciously, ambiguities and anomalies creep into SRS document. It is therefore important to validate and cross-check your solicited functional and non-functional requirements list with your client. And yes, do validate user interface requirements as well.
-
Do a Feasibility Study:
Once you solicit all the requirements, do a feasibility analysis. Prepare a feasibility report. This report should focus on usability, the scope of the software, maintainability, and productivity.
-
Draft a Plan:
Building a software product is nothing short of climbing a mountain. Set realistic expectations when it comes to fixing timelines. The plan should essentially encompass project life-cycle, various phases involved in project life-cycle, estimated budget, etc.
-
Compatibility with Existing IT Systems:
This is something which software development teams should pay superior attention to. If your software product is not compatible with existing IT systems, do not go-ahead. It just results in a pile of mess. Complex software products often require too many installations, too many extensions, and undesirable plug-ins. Complex software products are as ineffective as obsolete software.
-
Sort Out Your Financials:
Do you have enough money to initiate the project? Who are your go-to investors? Identify all your major stakeholders. Do you have money to efficiently deal with contingencies? To expect events would unspool like a pleasant dream is essentially embracing naiveté.
-
Pay Attention to Contemporary Software:
The software which you are planning to build might already exist in the market. Sometimes, the software may not exist in its entirety. Only a few components may be present. You can use those components after purchasing appropriate licenses and save precious time. In this competitive and obsessive world, time is money.
-
Identify the Technology Stack:
The only thing constant today is change. Today’s technology is definitely going to become obsolete tomorrow. That being said, it makes a lot of sense to configure, design and build the software product by using contemporary technology stacks such as MEAN – MongoDB, Express JS, Angular JS and Node.js.
-
Software Size Estimation:
One of the metrics used to estimate the size of the software is KLOC – Kilo Lines of Code. As a matter of fact, lines of code depend on the coding practices. Another practical way of estimating the size of the software is identifying the number of function points. Function points vary as per the user requirements.
-
Effort Estimation:
Effort estimation is all about estimating the number of man-hours required to program the software product. To estimate the number of man-hours required, you are required to first estimate the number of Kilo Lines of Code (KLOC). Experienced project managers are good at estimating the number of man-hours required to fulfill the task at hand.
-
Time Estimation:
Once the size of the software and the number of man-hours is estimated, time in months is estimated. To get a holistic view of the number of months required, WBS is used. WBS stands for Work Breakthrough Structure. The essence of WBS framework lies in breaking the whole task into smaller tasks and subsequently assigning a realistic time period.
-
Cost Estimation:
This is somewhat different from sorting your financials. Project cost estimation has often left both experienced and amateur project managers perplexed. The following costs come under the ambit of project cost estimation:
- Quality of software
- Size of the software
- Hardware
- Training
- Supervision
- Testing
- Software tools
- Software licenses
- Travel
- Food
- Communication
- Skilled Personnel Maintenance
-
Freelancer vs Professionals:
Freelancers are known to lend creativity to software design and development. Professionals are known to accomplish tasks at hand with utmost diligence. Taking a conscious decision of bringing a blend of freelancer and professional workforce onboard will drum up expectations and performance. Use your judgment, and do take financials into consideration before taking a decision. Very often, professionals charge you a fortune while freelancers might exact your resources.
-
Identification of Risks:
Crucial to software product development is risk management. More often than not, in every software product development project, there are a few risks such as the following:
- Experienced and qualifies personnel abruptly leaving the project
- Strategic Management executives may change
- Mismatch of requirements
- Misunderstanding of requirements
- Software size underestimation
- Improper analysis of business competition
- Unprecedented technology changes
- Unforeseen environmental changes
-
Categorization of Risks:
The next big thing is to categorize all the risks based on the possible impact each risk could have on the software development project. More often than not, risks are classified into the following categories:
- High
- Medium
- Low
- Critical
-
Monitor the Risks:
Have an Argus-eye to monitor all the risks. Identify all the possible symptoms. Cautious examination of symptoms and careful assessment of risks will help you take risk mitigation policies.
-
Risk Response Strategies:
Regardless of the magnitude of the risk, the following four risk response strategies can be used:
- Risk can be avoided
- Risk can be ignored and cascaded
- Risk can be mitigated by taking corrective actions
- Risk can be acknowledged
Good project managers avoid risks. Great project managers acknowledge risks, take necessary corrective actions and mitigate risks.
-
Risk Register:
It is important to maintain a detailed document which outlines all the possible strategies, probable risk responses and proper courses of actions to be taken to mitigate risks. If the project manager changes, new project managers can go through the huge deal of information compiled in the risk register and subsequently plan risk mitigation strategies.
-
Test, Test, and Retest:
More often than not, software product development whips up non-performance issues. It is important to unearth all the possible fallacies and frailties well before the software product hits the markets. Do all possible types of testing such as Unit testing, integration testing, White box testing, Black box testing, Alpha testing, Beta testing etc.
Follow the aforementioned 31 things. Be patient and consistent in your efforts. Your software product will be a marvel.
We have an excellent team of software developers, growth hackers and project managers with a decade of experience. We can help you connect with them. If you have any doubts or concerns, feel free to drop a line or two in the comments section. We shall reply in a day or two. Keep watching this space for insights on Agile software development model. Subscribe to our newsletter to know more about trends in software industry. Our best wishes are with you and your software product. Cheers!